PRESIDÈNTZIA PRESIDENZA

PRESIDÈNTZIAPRESIDENZA

Direzione generale della Centrale regionale di committenzaServizio forniture e servizi

Capitolato speciale, descrittivo e prestazionalePagina 1 di 135

Procedura ristretta informatizzata per l’affidamento dei servizi di gestione,manutenzione e reingegnerizzazione dell’architettura del Sistema Informativo

Sanitario Integrato Regionale (SISaR) e acquisizione dell’infrastruttura diintegrazione

SISaR 2.0.

CIG: 7686214073 - CUP: E77H18001780002

Allegato 1.A

Capitolato speciale, descrittivo e prestazionale




1. PREMESSA .............................................................................................................................. 31.1. Il sistema SISaR........................................................................................................................ 41.2. ACRONIMI .............................................................................................................................. 17

2. OGGETTO DELLA PROCEDURA......................................................................................... 192.1. Fasi del progetto e durata ....................................................................................................... 202.2. Precisazioni in merito alla possibilità di sostituzione degli applicativi ..................................... 222.3. Linee guida Usabilità............................................................................................................... 232.4. Metodologie di sviluppo software e gestione di progetto ........................................................ 25

2.4.1 Aspetti metodologici specifici relativi alla protezione dei dati personali........................ 262.5. Open Data e formato dei dati .................................................................................................. 27

2.5.1 Formato dei dati .............................................................................................................. 28

3. AREA 1 – SERVIZI DI GESTIONE E MANUTENZIONE....................................................... 283.1. Servizio A1.1: Manutenzione Preventiva, Adeguativa, Correttiva, Perfettiva......................... 29

3.1.1 Manutenzione preventiva ............................................................................................... 293.1.2 Manutenzione adeguativa e adattativa........................................................................... 303.1.3 Manutenzione correttiva................................................................................................. 343.1.4 Manutenzione perfettiva................................................................................................. 36

3.2. Servizio A1.2: Miglioramento delle performance e dell’usabilità ............................................ 393.3. Servizio A1.3: Manutenzione Evolutiva .................................................................................. 413.4. Servizio A1.4: Servizi Specialistico-Applicativi ....................................................................... 463.5. Servizio A1.5: Gestione degli ambienti applicativi di test e di produzione.............................. 493.6. Servizio A1.6: Gestione sistemistico-applicativa .................................................................... 523.7. Servizio A1.7: Servizio di Help Desk....................................................................................... 563.8. Servizio A1.8: Reperibilità H24 mission critical....................................................................... 58

4. AREA 2 – REALIZZAZIONE NUOVA ARCHITETTURA....................................................... 594.1. Servizio A2.1: Sistema Enterprise Service Bus ...................................................................... 60

4.1.1 Descrizione della infrastruttura richiesta / servizio......................................................... 614.1.2 Caratteristiche specifiche della componente ESB ........................................................... 624.1.3 Caratteristiche specifiche della componente API Gateway ............................................ 644.1.4 Requisiti generici comuni per ESB/API ............................................................................ 654.1.5 Requisiti di sicurezza comuni per ESB/API....................................................................... 66

4.2. Servizio A2.2: Evoluzione e migrazione su nuova infrastruttura e disaccoppiamentofunzionale........................................................................................................................................... 66

4.2.1 Migrazione delle attuali integrazioni sul nuovo ESB/API ................................................ 674.2.2 Disaccoppiamento delle macrocomponenti del SISaR.................................................... 67

5. AREA 3 – SERVIZI DI TRANSIZIONE................................................................................... 755.1. Servizio A3.1: Transizione verso il fornitore/i subentrante/i.................................................... 76

6. AREA 4. SERVIZI TRASVERSALI......................................................................................... 796.1. Servizio A4.1: Program, Project e Service Management ....................................................... 806.2. Servizio A4.2: Formazione e Affiancamento........................................................................... 82

7. PASSAGGIO DI CONSEGNE “IN INGRESSO” E PRESA IN CARICO DALL’ATTUALEGESTORE DEL SISTEMA............................................................................................................. 848. ASPETTI RELATIVI AL GDPR E TRATTAMENTO DEI DATI PERSONALI ....................... 889. ORGANIZZAZIONE DI PROGETTO...................................................................................... 8910. Strumenti di supporto ....................................................................................................... 9411. DELIVERABLES ................................................................................................................. 97




12. MODALITÀ DI ESECUZIONE........................................................................................... 10013. SLA – LIVELLI DI SERVIZIO E OBBLIGHI DELL’AGGIUDICATARIO.......................... 101

13.1. Metodo di calcolo degli SLA.............................................................................................. 10213.2. Manutenzione Correttiva ................................................................................................... 10313.3. Manutenzione Preventiva, Adeguativa, Perfettiva ............................................................ 10413.4. Manutenzione per adeguamenti normativi ordinari ........................................................... 10513.5. Servizi per il miglioramento delle performance e dell’usabilità ......................................... 10613.6. Servizi di Manutenzione Evolutiva..................................................................................... 10613.7. Servizi Specialistico-Applicativi ......................................................................................... 10813.8. Gestione ambiente applicativo di test ............................................................................... 10813.9. Gestione ambiente applicativo di produzione ................................................................... 10913.10. Gestione sistemistico-applicativa ...................................................................................... 11013.11. Help Desk .......................................................................................................................... 11013.12. Reperibilità H24 mission critical ........................................................................................ 11213.13. Realizzazione nuova infrastruttura interoperabilità ........................................................... 11313.14. Evoluzione e migrazione su nuova infrastruttura e disaccoppiamento funzionale ........... 11313.15. Transizione verso il fornitore subentrante ......................................................................... 11413.16. Program/Project/Service Management ............................................................................. 11413.17. Formazione e affiancamento............................................................................................. 11713.18. Livelli di servizio Sicurezza/GDPR .................................................................................... 117

14. PENALI .............................................................................................................................. 11914.1. Penali per mancato rispetto degli SLA .............................................................................. 12014.2. Penali per mancato rispetto degli SLA relativi a cronoprogrammi .................................... 12014.3. Tabella sinottica SLA – Penali........................................................................................... 121

15. PROPRIETÀ DEL SOFTWARE ........................................................................................ 13116. SPESE, OBBLIGHI, ONERI, RISCHI E RESPONSABILITÀ........................................... 13117. VERIFICA DI CONFORMITÀ - COLLAUDO FUNZIONALE E ACCETTAZIONE........... 13318. VARIAZIONI IN CORSO D’OPERA.................................................................................. 134




1. PREMESSA

Il sistema informativo sanitario regionale della Regione Sardegna è costituito da un insieme di sistemi

informativi integrati acquisiti e gestiti dall’Amministrazione regionale a beneficio delle Aziende

Sanitarie e dell’Assessorato dell’Igiene e Sanità e dell’Assistenza Sociale, tra cui si citano, in

particolare, i sistemi SISaR (sistema informativo sanitario integrato regionale), MEDIR (sistema Medici

in Rete e Fascicolo Sanitario Elettronico), ANAGS (Anagrafe Sanitaria), SILUS (Sistema Informativo

Laboratorio Unico d’analisi), SISM (Sistema informativo Salute Mentale), mFP (Sistema Informativo

dipendenze). Il sistema informativo sanitario regionale rappresenta uno strumento essenziale per il

governo clinico ed economico del servizio sanitario regionale nel suo complesso.

L’estensione del grado di copertura delle funzionalità del sistema informativo sanitario integrato

regionale rispetto alla totalità dei processi gestiti dalle Aziende Sanitarie è in costante evoluzione,

essendo necessariamente, in virtù dell’estrema complessità del Servizio Sanitario Regionale, un

percorso da condurre progressivamente in ragione dell’avanzamento delle tecnologie e in funzione




delle esigenze di budget, sostenibilità e change management, nell’arco di programmazioni pluriennali.

Il grado di maturità di tale percorso, considerate anche le priorità strategiche determinate dagli

orientamenti regionali e nazionali in materia sanitaria, consente e impone oggi di focalizzare

l’attenzione sulla gestione dei percorsi clinico assistenziali, sia intra-ospedalieri sia di continuità

ospedale-territorio e di cure primarie.

Allo stato attuale, nelle Aziende Sanitarie della Regione, accanto ai singoli sistemi appartenenti al

perimetro del sistema informativo sanitario integrato regionale, convivono un gran numero di altri

sistemi informativi di natura prevalentemente clinica, aventi generalmente funzioni di carattere

“verticale”, parzialmente integrati con i sistemi regionali. In alcuni ambiti, che non permettono flussi di

lavoro interamente digitali, persiste ancora la gestione di funzioni in modalità cartacea.

Nell’ambito dell’Agenda Digitale della Sardegna, in coerenza con le politiche nazionali in materia, con

riferimento alle azioni di informatizzazione del Servizio Sanitario Regionale, l’articolazione delle

strategie individuate include lo sviluppo di servizi relativi all’e-health, orientati al miglioramento dei

processi sanitari, facendo leva sull’accentuazione del grado di interoperabilità tra i sistemi. Inoltre il

Servizio Sanitario Regionale deve continuare a supportare le riforme intraprese dalla Regione e dallo

Stato nell’ambito di un percorso normativo ed attuativo pluriennale mirato alla modernizzazione ed

all’efficientamento dell’organizzazione secondo criteri di razionalizzazione e valorizzazione delle

competenze specifiche, ed alla riforma delle Cure Primarie in coerenza con la Legge n. 189 del

08.11.2012 che ha stabilito all’art. 1 il riordino dell’assistenza territoriale, dando mandato alle Regioni

per la definizione dell’organizzazione dei servizi territoriali di assistenza primaria, promuovendo

l’integrazione con l’area del sociale, anche con riferimento all’assistenza domiciliare ed ai servizi

ospedalieri.

Ciò che, in ogni caso, emerge fortemente è l’evidenza che qualunque evoluzione del Servizio

Sanitario Regionale non possa prescindere dall’esistenza di un’architettura a rete diffusa, che non può

essere implementata senza il parallelo e coerente sviluppo dell’informatizzazione secondo i medesimi

principi, per consentire l’interrelazione tra professionisti e tra questi ed i nodi della rete integrata dei

servizi sociosanitari del distretto e dei servizi sanitari ospedalieri, così da favorire il massimo livello di

integrazione e condivisione delle informazioni. Per queste ragioni, il tema dell’interoperabilità risulta

pertanto strategia cardine anche del presente appalto, come meglio illustrato nel seguito.

1.1. Il sistema SISaR

Il Sistema Informativo Sanitario Integrato Regionale (SISaR) rappresenta il nucleo centrale del

sistema informativo sanitario regionale. Esso è stato realizzato attraverso una specifica gara d’appalto

pubblicata nel 2006, con avvio dell’esecuzione nel 2008. Dal 2008 al 2019 il sistema SISaR è stato




sottoposto ad una costante manutenzione ed a numerose evoluzioni. Attualmente, il SISaR è un

sistema integrato di sistemi e moduli software gestionali a carattere sia amministrativo che clinico,

omogeneo su tutto il territorio regionale e presso tutte le Aziende Sanitarie, le cui funzionalità

assicurano la copertura della maggioranza dei processi essenziali al funzionamento della sanità

regionale. In particolare, il sistema SISaR è costituito dai seguenti principali moduli che sono

maggiormente dettagliati nei documenti tecnici allegati:

SISTEMI\ModuliAMC

Contabilità GeneraleContabilità AnaliticaControllo di GestioneApprovvigionamenti: Acquisiti e ContrattiLogistica: Magazzini/Farmaci, Richieste Approvvigionamento, Armadietto di RepartoGestione Attrezzature e Manutenzioni

HRTrattamento GiuridicoGestione Dotazione OrganicaGestione Economica e ContributivaGestione Presenze e Assenze (Rilevazione Presenze)Gestione PensioniGestione Concorsi e SelezioniGestione FondiDichiarazioni 770Portale del Dipendente (Intranet del Personale SSR)

PDProtocollo InformaticoAtti AmministrativiGestione Documentale

SIO (Ospedaliero)AnagrafeADT e Liste di AttesaPronto Soccorso + OBI + Monitor Pronto SoccorsoOrder Entry di PrestazioniSale OperatorieTrasfusionaleSRC (ex CRCC) + componente Broker EsamiEMR – Cartella Clinica (offerta migliorativa su ASL 8)Prescrizione e Somministrazione dei Farmaci (offerta migliorativa su ASL 8)Identificazione Certa del Paziente - RFID (offerta migliorativa su ASL 8)

AAP (Territoriale)ConsultorioCSS Cartella Socio-SanitariaPUA-Punto Unico di AccessoADI-Assistenza Domiciliare IntegrataMedicina dello SportMedicina LegaleSPRESAL-Servizio Prevenzione e Sicurezza negli ambienti di vita e di LavoroSISP-Servizio Igiene e Sanità Pubblica




SIAN-Servizio Igiene degli Alimenti e della NutrizioneRSA-Gestione attività residenziali e semi-residenzialiProtesicaPortale Prevenzione: Portale Notifica Preliminare dei Cantieri e Portale Amianto

CUPCUP – SGPE-PrescriptionCUPWEBAmbulatorio – Cartella Clinica Ambulatoriale

DIRStrumento ETL: Talend Open StudioFlussi ETLDatawarehouseStrumento di BI: SpagoBIReport ed Indicatori

EPI (Epidemiologico)CEDAP-Certificato di Assistenza al PartoRENCAM-Registro Nominativo elle Cause di Morte

SIDISistema Integrato Debito Informativo

Accesso al Sistema e CDASistema di accesso SSO, tramite CNS, produzione dei documenti sanitari firmabili digitalmente

IntegrazioniIntegrazioni con Sistemi Terzi Non SISaR (Fascicolo Sanitario Elettronico, SILUS, etc.)Integrazioni intra-SISaRMiddleware di Integrazione: Spagic

L’ambito del presente appalto concerne l’intero parco sistemi sopra descritto.

La descrizione di dettaglio dei sistemi di cui è composto il SISaR è riportata nei documenti allegati al

presente capitolato, elencati nella tabella sottostante. Tali documenti sono articolati secondo il

seguente schema:

- Documenti di descrizione generale dei sistemi: forniscono informazioni generali sui sistemi e

sul grado del loro utilizzo in Regione Sardegna.

- Documenti funzionali, specifiche tecniche e reportistica: forniscono informazioni di maggior

dettaglio sui moduli, sulle funzionalità, sull’architettura e sul dimensionamento.

DOCUMENTI DI DESCRIZIONE GENERALE

Sistema Nome file

Sistema Territoriale edEpidemiologico Allegato 1.B - Descrizione sistema territoriale – AAP

Sistema InformativoOspedaliero Allegato 1.C - Descrizione sistema ospedaliero – SIO

Sistema Amministrativo Allegato 1.D - Descrizione sistema amministrativo - AMC-HR-PROT

CUP e CCA Allegato 1.E - Descrizione sistema CUP-AMB-EPRE




Sistema Direzionale Allegato 1.F - Descrizione sistema direzionale

Sistema Integrato DebitiInformativi Allegato 1.G - Descrizione sistema debito informativo

Infrastruttura HW eSOFTWARE di base Allegato 1.H - Descrizione infrastruttura

MU - MANUALI UTENTE

MODULO Titolo documento Nome FileTER-Territoriale

Medicina delloSport

Allegato 001 – Modulo Medicina delloSport - Manuale Utente All.001_MU_SISAR_TER_MS_V.1.0

Amianto Allegato 002 – Modulo Amianto -Manuale Utente All.002_MU_SISAR_TER_AMI_V.1.0

AssistenzaDomiciliareIntegrata

Allegato 003 – Modulo AssistenzaDomiciliare - Manuale Utente All.003_MU_SISAR_TER_AD_V.1.0

Consultori Allegato 004 – Modulo Consultori -Manuale Utente All.004_MU_SISAR_TER_CON_V.1.0

Cartella Socio-Sanitaria

Allegato 005 – Modulo AAP_PUACartella Socio-Sanitaria - ManualeUtente

All.005_MU_SISAR_TER_CSS_V.1.0

Protesica Allegato 006 – Modulo Protesica -Manuale Utente All.006_MU_SISAR_TER_PRO_V.1.0

MedicinaLegale e INPS

Allegato 007 – Modulo Medicina Legalee INPS - Manuale Utente All.007_MU_SISAR_TER_MLG_V.1.0

Punto Unico diAccesso

Allegato 008 – Modulo AAP_PUA Puntounico di Accesso - Manuale Utente All.008_MU_SISAR_TER_PUA_V.1.0

ResidenzaSanitariaAssistenziale

Allegato 009 – Modulo AAP_PUA RSA -Manuale Utente All.009_MU_SISAR_TER_RSA_V.1.0

Alimenti eNutrizione

Allegato 011 – Modulo SIAN - ManualeUtente All.011 MU_SISAR_TER_SIAN_V.1.0

SPRESAL Allegato 012 – Modulo SPRESAL -Manuale Utente All.012_MU_SISAR_TER_SPRESAL_V1.0

Igiene e SanitàPubblica

Allegato 013 – Modulo SISP - ManualeUtente All.013_MU_SISAR_TER_SISP_V.1.0

NPC WEB -web/cittadini

Allegato 079 – Modulo NPC WEB -Manuale Utente web/cittadini

All.079_MU_SISaR_AAP_PORTALE_NPCWEB_COMM_RL_v.1.0

NPC WEB -ASSL-Spresale DTL

Allegato 080 – Modulo NPC WEB -Manuale Utente ASSL-Spresal e DTL

All.080_MU_SISaR_AAP_PORTALE_NPCWEB_SPRESAL_ITL_v.1.0

Portale delCittadino

Allegato 077 – Modulo Portale delCittadino - Manuale Utente

All.077_MU_SISaR_PORTALE_CITTADINO_v.1.0.doc

EPI - EpidemiologicoRegistroNominativoCause Morte

Allegato 010 – Modulo RENCAM -Manuale Utente

All.010_MU_SISAR_TER_RENCAM_V.1.0

CEDAP Allegato 066 – Modulo CEDAP -Manuale Utente

All.66_MU_SISAR_SIO_CEDAP_V.1.0

SIO – OspedalieroADT Allegato 064 – Modulo ADT - Manuale

UtenteAll.64_MU_SISAR_SIO_ADT_V.1.1

EMR Allegato 067 – Modulo EMR - ManualeUtente

All.67_MU_SISAR_SIO_EMR_V.1.0

Lista D’Attesa Allegato 068 – Modulo Lista D'Attesa -Manuale Utente

All.68_MU_SISAR_SIO_LDA_V.1.0




Order Entry Allegato 069 – Modulo Order Entry -Manuale Utente

All.69_MU_SISAR_SIO_OE_V.1.0

ProntoSoccorso

Allegato 070 – Modulo Pronto Soccorso- Manuale Utente

All.070_MU_SISAR_SIO_PS_V.1.0

SaleOperatorie

Allegato 071 – Modulo Sale Operatorie -Manuale Utente

All.071_MU_SISAR_SIO_SO_V.1.0

SRC Allegato 076 – Modulo SRC - ManualeUtente

All.076_MU_SISAR_SRC_v_1.0

ELIOT_TRASFUSIONALE

Allegato 082 – ModuloELIOT_TRASFUSIONALE - ManualeUtente

All.82_MU_SISAR_ELIOT_TRASFUSIONALE_v_1.0

AMC – Amministrazione e ControlloGestioneAppalti eContratti

Allegato 014 – Modulo AMC GestioneAppalti e Contratti - Manuale Utente

All.014_MU_SISAR_AMC_Acquisti_e_Logistica_Gestione_Appalti_Contratti_v_1.0

AVCP Legge190 ATS

Allegato 015 – Modulo AMC AVCPLegge 190 ATS - Manuale Utente

All.015_MU_SISAR_AMC_AVCP_Legge190_ATS_v_1.0

AutomatismoInterazioneHR-AMC

Allegato 016 – Modulo AMCAutomatismo Interazione HR-AMC -Manuale Utente

All.016_MU_SISAR_AMC_Automatismo_Interazione_AMC_HR_v_1.0

Avvisi dipagamento

Allegato 017 – Modulo AMC Avvisi dipagamento - Manuale Utente

All.017_MU_SISAR_AMC_Avvisi dipagamento_v_1.0

CassaEconomale

Allegato 018 – Modulo AMC CassaEconomale - Manuale Utente

All.018_MU_SISAR_AMC_CassaEconomale_v_1.0

Cespiti Allegato 019 – Modulo AMC_Cespiti -Manuale Utente All.019_MU_SISAR_AMC_Cespiti_v_1.0

Controllo digestione

Allegato 020 – Modulo AMC Controllo digestione - Manuale Utente

All.020_MU_SISAR_AMC_Controllo digestione_v_1.0

AMC_EDF Allegato 021 – Modulo AMC_EDF -Manuale Utente All.021_MU_SISAR_AMC_EDF_v_1.0

Fatturazioneattiva

Allegato 022 – Modulo AMCFatturazione attiva - Manuale Utente

All.022_MU_SISAR_AMC_Fatturazioneattiva_v_1.0

Gestione Alias Allegato 023 – Modulo AMC GestioneAlias - Manuale Utente All.023_MU_SISAR_AMC_Gestione Alias_v_1.0

Gestionearmadietti direparto

Allegato 024 – Modulo AMC Gestionearmadietti di reparto - Manuale Utente

All.024_MU_SISAR_AMC_Gestione Armadietti direparto_v_1.0

Gestione contodeposito

Allegato 025 – Modulo MU AMCGestione conto deposito - ManualeUtente

All.025_MU_SISAR_AMC_Gestione contodeposito_v_1.0

Gestionecontratti

Allegato 026 – Modulo MU AMCGestione contratti - Manuale Utente

All.026_MU_SISAR_AMC_Gestione Contratti_v_1.0

GestionecontratticentralizzatiATS

Allegato 027 – MU AMC Gestionecontratti centralizzati ATS - ManualeUtente

All.027_MU_SISAR_AMC_Gestione contratticentralizzati_ATS_v_1.0

Gestioneinventario

Allegato 028 – MU AMC Gestioneinventario - Manuale Utente

All.028_MU_SISAR_AMC_Gestioneinventario_v_1.0

Gestionemanutenzioniedelettromedicali

Allegato 029 – Modulo AMC Gestionemanutenzioni ed elettromedicali -Manuale Utente

All.029_MU_SISAR_AMC_Gestione manutenzionied elettromedicali_v_1.0

Gestioneordinativi

Allegato 030 – Modulo AMC Gestioneordinativi - Manuale Utente

All.030_MU_SISAR_AMC_Gestioneordinativi_v_1.0

GestioneparametriADMINISTRATOR

Allegato 031 – Modulo AMC Gestioneparametri ADMINISTRATOR - ManualeUtente

All.031_MU_SISAR_AMC_Gestione parametriADMINISTRATOR_v_1.0

Gestione ordini Allegato 032 – Modulo AMC Gestioneordini - Manuale Utente All.032_MU_SISAR_AMC_Gestione_ordini_v_1.0




ImpostazioniLogin

Allegato 033 – Modulo AMCImpostazioni Login - Manuale Utente

All.033_MU_SISAR_AMC_ImpostazioniLogin_v_1.0

LiquidazioneDocumentiWorkflow

Allegato 034 – Modulo AMCLiquidazione Documenti Workflow -Manuale Utente

All.034_MU_SISAR_AMC_Liquidazionedocumenti_Workflow_v_1.0

Logisticamovimenti dimagazzino

Allegato 035 – Modulo AMC Logisticamovimenti di magazzino - ManualeUtente

All.035_MU_SISAR_AMC_Logistica_Movimenti dimagazzino_v_1.0

Movimenticontabili

Allegato 036 – Modulo AMC Movimenticontabili-- - Manuale Utente

All.036_MU_SISAR_AMC_Movimenticontabili_v_1.0

Operazioni fineesercizio

Allegato 037 – Modulo AMC Operazionifine esercizio - Manuale Utente

All.037_MU_SISAR_AMC_Operazioni fineesercizio_v_1.0

Gestioneprogetti

Allegato 038 – Modulo AMC Gestioneprogetti - Manuale Utente All.038_MU_SISAR_AMC_Progetti_v_1.0

Report multi-utilità

Allegato 039 – Modulo AMC Reportmulti-utilità - Manuale Utente

All.039_MU_SISAR_AMC_Report MultiUtilità_v_1.0

Richiesteapprovvigionamento Centrodi consegna

Allegato 040 – Modulo AMC Richiesteapprovvigionamento Centro di consegna- Manuale Utente

All.040_MU_SISAR_AMC_Richieste diapprovvigionamento centro di consegna_v_1.0

Sistemaautorizzativo

Allegato 041 – Modulo AMC Sistemaautorizzativo - Manuale Utente

All.041_MU_SISAR_AMC_SistemaAutorizzativo_v_1.0

Storicizzazioneavvisi dipagamento

Allegato 042 – Modulo AMCStoricizzazione avvisi di pagamento -Manuale Utente

All.042_MU_SISAR_AMC_Storicizzazione avvisi dipagamento_v_1.0

WorkflowAnagraficafarmaci

Allegato 043 – Modulo AMC WorkflowAnagrafica farmaci - Manuale Utente

All.043_MU_SISAR_AMC_Workflow_Anagraficafarmaci_v_1.0

WorkflowAnagraficasoggetti

Allegato 044 – Modulo AMC WorkflowAnagrafica soggetti - Manuale Utente

All.044_MU_SISAR_AMC_Workflow_Anagraficasoggetti_v_1.0

HR – Risorse UmaneHR Denunce Allegato 056 – Modulo HR Denunce -

Manuale UtenteAll.056_MU_SISAR_HRDE_Denunce_V.1.0

HR Giuridico Allegato 057 – Modulo HR Giuridico -Manuale Utente

All.057_MU_SISAR_HRGR_Giuridico_V.1.0

HRCentralizzato eGiuridico

Allegato 058 – Modulo HR Centralizzatoe Giuridico - Manuale Utente

All.058_MU_SISAR_HRCE_Centralizzato_Giuridico_v1

HR Concorsi eSelezioni

Allegato 059 – Modulo HR Concorsi eSelezioni - Manuale Utente

All.059_MU_SISAR_HRCN_Concorsi_e_Selezioni_V.1.0

HREXEsportazioneDati

Allegato 060 – Modulo HREXEsportazione Dati - Manuale Utente

All.060_MU_SISAR_HREX_Esportazione_Dati_V.1.0

HR Pensioni Allegato 061 – Modulo HR Pensioni -Manuale Utente

All.061_MU_SISAR_HRPE_Pensioni_TFR_V.1.0

HRPWGestioneEconomica delPersonale

Allegato 062 – Modulo HRPW GestioneEconomica del Personale - ManualeUtente

All.062_MU_SISAR_HRPW_Gestione_Economica_del_Personale_V.1.0

HR RiPreSa Allegato 063 – Modulo HR RiPreSa -Manuale Utente

All.063_MU_SISAR_HRRP_Rilevazione_Presenze_V.1.0

PortaleDipendente

Allegato 078 – Modulo PortaleDipendente - Manuale Utente

All.078_MU_SISaR_PORTALE_DEL_DIPENDENTE_v.1.0

PD – Protocollo, Atti e DocumentaleAttiAmministrativi

Allegato 072 – Modulo Atti Amministrativi- Manuale Utente

All.072_MU_SISAR_PD_Atti_Amministrativi_v_1.0

ProtocolloInformatico

Allegato 073 – Modulo ProtocolloInformatico - Manuale Utente

All.073_MU_SISAR_PD_Protocollo_Informatico_v_1.0

Documentale Allegato 074 – Modulo Documentale All.074_MU_SISAR_PD_Documentale_v_1.0




Auriga Auriga - Manuale UtenteCUP – Gestore Risorse CUP

RipartizioneProventi

Allegato 045 – Modulo RipartizioneProventi - Manuale Utente All.045_MU_SISAR_CUP-RIPRO_V.1.0

CUPWEB -Front-Office

Allegato 046 – Modulo CUPWEB - Front-Office - Manuale Utente

All.046_MU_SISAR_CUPWEB_FRONT-OFFICE_V.1.0

Cassa 730 Allegato 047 – Modulo Cassa 730 -Manuale Utente All.047_MU_SISAR_CASSA730_V.1.0

CASSA-HCMFO

Allegato 048 – Modulo CASSA-HCMFO- Manuale Utente All.048_MU_SISAR_CASSA-HCMFO_V.1.0

CUPWEB -LiberaProfessione

Allegato 049 – Modulo CUPWEB -Libera Professione - Manuale Utente

All.049_MU_SISAR_CUP_LIBERAPROFESSIONE_V1.0

CUP-Backoffice

Allegato 050 – Modulo CUP-Backoffice -Manuale Utente All.050_MU_SISAR_CUP-BACKOFFICE_V.1.0

CUP-ListeD’Attesa

Allegato 051 – Modulo CUP-LDA -Manuale Utente All.051_MU_SISAR_CUPLDA_V.1.0

CUPWEBconfigurazioneutenze e uffici

Allegato 052 – CUPWEB configurazioneutenze e uffici - Manuale Utente

All.052_MU_SISAR_CUPWEB_Configurazione_UtenzeUffici_v_1.0

E-Prescription(Key User)

Allegato 053 – Modulo E-Prescription(Key User) - Manuale Utente All.053_MU_SISAR_EPRESCRIPTION_KEYUSER

E-Prescription Allegato 054 – Modulo E-Prescription -Manuale Utente All.054_MU_SISAR_E-PRESCRIPTION_V.1.0

CASSA V2.0 Allegato 055 – Modulo CASSA V2.0 -Manuale Utente All.055_MU_SISAR_CASSA2.0_V.1.0

Ambulatorio(CartellaClinicaAmbulatoriale)

Allegato 065 – Modulo Ambulatorio -Manuale Utente

All.65_MU_SISAR_SIO_AMB_V.1.0

DIR – DirezionaleDWSISAR -Sistemadirezionale

Allegato 075 – Modulo DWSISAR -Sistema direzionale SISaR - ManualeUtente

All.075_MU_SISaR_DWSISAR - Sistemadirezionale SiSaR_v_1.0

SIDI - Sistema Integrato del Debito InformativoSIDI Allegato 081 – Modulo SIDI - Manuale

UtenteAll.081_MU_SISAR_SIDI_Sistema_Integrato_Debito_Informativo_RAS_v_2.0

Portale documentazione di progetto

Portaledocumentazione di progetto

Allegato 199 – Intranet di progettoSISaR - Portale documentazioneManuale Utente All.199_MU_Intranet_Progetto_v_2.2

MT - MANUALI TECNICI

MODULO Titolo Documento Nome FileTER – Territoriale

Portale Amianto Allegato 124 – Modulo Portale Amianto- Manuale Tecnico

All.124_MT_SISAR_AMIAN_V.1.0

PROTESICA Allegato 125 – Modulo PROTESICA -Manuale Tecnico

All.125_MT_SISAR_PRO_V.1.2

SIAN Allegato 126 – Modulo SIAN30 -Manuale Tecnico

All.126_MT_SISAR_SIAN30_V.1.0

SISP Allegato 127 – Modulo SISP - ManualeTecnico

All.127_MT_SISAR_SISP_V.1.0

SPRESAL Allegato 128 – Modulo SPRESAL - All.128_MT_SISAR_SPRESAL_1.1




Manuale TecnicoADI Allegato 129 – Modulo ASSISTENZA

DOMICILIARE - Manuale TecnicoAll.129_MT_SISAR_TER_AD_V.1.1

CONSULTORI Allegato 130 – Modulo CONSULTORI- Manuale Tecnico

All.130_MT_SISAR_TER_CON_V.1.2

CSS CartellaSocio-Sanitaria

Allegato 131 – Modulo AAP - CSSCartella Socio-Sanitaria - ManualeTecnico

All.131_MT_SISAR_TER_CSS_V.1.1

Medicina Legale Allegato 132 – Modulo MedicinaLegale - Manuale Tecnico

All.132_MT_SISAR_TER_MLE_V.1.2

PUA Allegato 133 – Modulo PUA - ManualeTecnico

All.133_MT_SISAR_TER_PUA_V.1.1

RSA Allegato 134 – Modulo AAP - PUARSA - Manuale Tecnico

All.134_MT_SISAR_TER_RSA_V.1.1

Portale NotificaPreliminareCantieri

Allegato 114 – Portale NotificaPreliminare Cantieri - Manuale Tecnico

All.114_MT_SISaR_PORTALE_NPC_v.1.0


Allegato 115 – Portale del Cittadino -Manuale Tecnico

All.115_MT_SISaR_PORTALE_CITTADINO_v.1.0

EPI – EpidemiologicoCEDAP Allegato 102 – Modulo Certificato di

Assistenza al Parto - Manuale TecnicoAll.102_MT_SISAR_CEDAP_V.1.1

RENCAM Allegato 103 – Modulo applicativoRENCAM - Manuale Tecnico

All.103_MT_SISAR_TER_RENCAM_V.1.1

SIO – OspedalieroADT - Listad’attesa eGestione ricoveri

Allegato 119 – Modulo ADT - Listad’attesa e Gestione ricoveri - ManualeTecnico

All.119_MT_SISAR_ADT-LDA_V.1.1

EMR Allegato 120 – Modulo Cartella Clinica- Manuale Tecnico

All.120_MT_SISAR_EMR_V.1.1

Order Entry Allegato 121 – Modulo SIO OEP -Manuale Tecnico

All.121_MT_SISAR_OEP_1.1

Pronto Soccorso Allegato 122 – Modulo SIO ProntoSoccorso - Manuale Tecnico

All.122_MT_SISAR_PSWEB_V.1.2

Sale Operatorie Allegato 123 – Modulo SIO - SaleOperatorie - Manuale Tecnico

All.123_MT_SISAR_SOWEB_1.1

TrasfusionaleELIOT

Allegato 099 - Modulo applicativoCTELIOT - Manuale Tecnico

All.099_MT_SISAR_ELIOT_TRASFUSIONALE_v_1.0

Eliot SRC -Configuratore

Allegato 100 – Modulo applicativo EliotSRC - Configuratore - ManualeTecnico

All.100_MT_SISAR_SRC_SISTEMA_REGIONALE_ORCHESTRAZIONE_ESAMI_v_1.0

Tabellegeneralizzateper l’applicativoELIOT

Allegato101 - Modulo applicativo EliotSoftware di gestione tabelle

generalizzate per l’applicativo ELIOT -Versione 7.1.0 - Manuale Tecnico

All.101_MT_SISAR_Tabgen_Eliot_v_1.0

AMC – Amministrazione e ControlloBUDGET Allegato 083 – Modulo AMCBD -

BUDGET - Manuale Tecnico All.083_MT_SISAR_AMCBD_BUDGET_v_1.0

CENTRALIZZATO

Allegato 084 – Modulo AMCCE -CENTRALIZZATO - Manuale Tecnico

All.084_MT_SISAR_AMCCE_CENTRALIZZATO_v_1.0

CONTABILITA Allegato 085 – Modulo AMCCO -CONTABILITA AMC - ManualeTecnico

All.085_MT_SISAR_AMCCO_CONTABILITA_v_1.0

CESPITI Allegato 086 – Modulo AMCCS -CESPITI AMC - Manuale Tecnico All.086_MT_SISAR_AMCCS_CESPITI_v_1.0

CONTROLLO DIGESTIONE

Allegato 087 – Modulo AMCGE -CONTROLLO DI GESTIONE AMC -Manuale Tecnico

All.087_MT_SISAR_AMCGE_CONTROLLO_DI_GESTIONE_v_1.0

LOGISTICA Allegato 088 – Modulo AMCMA -LOGISTICA AMC - Manuale Tecnico All.088_MT_SISAR_AMCMA_LOGISTICA_v_1.0




ANAGRAFICHECENTRALIZZATE

Allegato 089 – Modulo XMPI –ANAGRAFICHE CENTRALIZZATEManuale Tecnico

All.089_MT_SISAR_XMPI_ANAGRAFICHE_CENTRALIZZATE_v_1.0

ACQUISTI Allegato 090 – Modulo AMCAQ -ACQUISTI - Manuale Tecnico All.090_MT_SISAR_AMCAQ_ACQUISTI_v_2.0

HR – Risorse UmaneCandidati Allegato 104 – Modulo HR Candidati -

Manuale TecnicoAll.104_MT_SISAR_HR_Candidati_v_1.0

Concorsi eselezioni

Allegato 105 – Modulo HR Concorsi eselezioni - Manuale Tecnico

All.105_MT_SISAR_HR_Concorsi e selezioni_v.1.0

HR Centralizzatoe Giuridico

Allegato 106 – Modulo HRCentralizzato e Giuridico - ManualeTecnico

All.106_MT_SISAR_HRCE_HRGR_v_1.0

Gestionegiuridica delpersonale.Modulo Concorsie Selezioni

Allegato 107 – Gestione giuridica delpersonale. Modulo Concorsi eSelezioni - Manuale Tecnico

All.107_MT_SISAR_HRCN_SISAR_v_1.0

Denunce Allegato 108 – Modulo denunce -Manuale Tecnico

All.108_MT_SISAR_HRDE_v_1.0

HREXEsportazioneDati

Allegato 109 – Modulo HREXEsportazione Dati - Manuale Tecnico

All.109_MT_SISAR_HREX_v_1.0

Giuridico eCapitale Umano- Sistema diformazione

Allegato 110 – Modulo Giuridico eCapitale Umano - Sistema diformazione - Manuale Tecnico

All.110_MT_SISAR_HRGR_FORMAZIONE_v_1.0

Pianta organica Allegato 111 – Modulo Pianta organica- Manuale Tecnico

All.111_MT_SISAR_HRGR_PIANTA_ORGANICA_v_1.0

Gestione Fondi Allegato 112 – Modulo Gestione Fondi- Manuale Tecnico

All.112_MT_SISAR_HRPW_FONDI_v_1.0

Stipendi -GestioneIntegrazione

Allegato 113 – Modulo HR Stipendi -Gestione Integrazione - ManualeTecnico

All.113_MT_SISAR_HRST_v_1.0

Portale delDipendente

Allegato 116 – Portale del Dipendente- Manuale Tecnico

All.116_MT_SISaR_PORTALE_DEL_DIPENDENTE_v.1.0

PD – Protocollo, Atti e DocumentaleDocumentaleAuriga

Allegato 091 – Modulo DocumentaleAuriga - Manuale Tecnico All.091_MT_SISAR_PD_Documentale_v_1.0


Allegato 092 – Modulo ProtocolloInformatico - Manuale Tecnico

All.092_MT_SISAR_PD_Protocollo_Informatico_v_1.0

AttiAmministrativi

Allegato 093 – Modulo AttiAmministrativi - Manuale Tecnico All.093_MT_SISAR_PD_Atti_Amministrativi_v_1.0

CUP – Gestore Risorse CUPCUPWEB-CassaTicket

Allegato 094 – MODULO CUPWEB-Cassa - Manuale Tecnico All.094_MT_SISAR_CASSA_V.1.2

CUPWEB -FRONT-OFFICE

Allegato 095 – MODULO CUPWEB -FRONT-OFFICE - Manuale Tecnico All.095_MT_SISAR_FRONT-OFFICE_V.1.0

CUPWEB -LIBERAPROFESSIONE

Allegato 096 – MODULO CUPWEB -LIBERA PROFESSIONE ManualeTecnico

All.096_MT_SISAR_LIPRO_V1.1

SIO –PRODUCER

Allegato 097 – MODULO SIO –PRODUCER - Manuale Tecnico All.097_MT_SISAR_PRODUCER_1.1

Cartella ClinicaAmbulatoriale

Allegato 098 – MODULO Gestionedell'Attività Ambulatoriale - ManualeTecnico

All.098_MT_SISAR_AMB_V.1.2

DIR – DirezionaleDWSISAR -Sistemadirezionale

Allegato 135 - Modulo applicativoDWSISAR - Sistema direzionaleSiSaR - Manuale Tecnico

All.135_MT_SISaR_DWSISAR - Sistemadirezionale SiSaR_v_1.0




SIDI - Sistema Integrato del Debito Informativo

SIDI Allegato 117 – Sistema IntegratoDebito Formativo - Manuale Tecnico

All.117_MT_SISAR_SIDI_SISTEMA_INTEGRATO_DEBITO_INFORMATIVO

SIDI -Configurazioni

Allegato 118 – Modulo SIDI -Configurazioni - Manuale Tecnico All.118_SIDI Configurazioni

AF - ANALISI FUNZIONALE

MODULO Titolo Documento Nome FileTER - Territoriale

Portale Amianto Allegato 137 – Modulo PORT_AMIAN(Portale Amianto) - Analisi Funzionale All.137_SISAR_ FUNZIONALE_AMIAN_v_1.0

SIAN Allegato 138 – Modulo SIAN30 -Analisi Funzionale All.138_SISAR_FUNZIONALE_SIAN30_v_1.0

ADI Allegato 139 – Modulo ASSISTENZADOMICILIARE - Analisi Funzionale All.139_SISAR_ FUNZIONALE_AD_v_1.0

NPC WEB Allegato 140 – Modulo NPC WEB -Analisi Funzionale All.140_SISAR_ FUNZIONALE_NPCWeb_v_1.0

PROTESICA Allegato 141 – Modulo PROTESICA -Analisi Funzionale All.141_SISAR_ FUNZIONALE_PROTE_v_1.0

PUA Allegato 142 – Modulo PUA - AnalisiFunzionale All.142_SISAR_ FUNZIONALE_PUA_v_1.0

RSA Allegato 144 – Modulo RSA(RESIDENZE SANITARIEASSISTENZIALI) - Analisi Funzionale

All.144_SISAR_ FUNZIONALE_RSA_v_1.0

SISP Allegato 145 – Modulo SISP - AnalisiFunzionale All.145_SISAR_ FUNZIONALE_SISP_v_1.0

SPRESAL Allegato 146 – ModuloTERRITORIALE - SPRESAL - AnalisiFunzionale

All.146_SISAR_ FUNZIONALE_SPRESAL_v_1.0

CONSULTORI Allegato 147 – Modulo CONSULTORI- Analisi Funzionale

All.147_SISAR_FUNZIONALE_CONSULTORI_v_3.0

Cartella Socio-Sanitaria

Allegato 148 – Modulo CSS -CARTELLA SOCIO SANITARIA -Analisi Funzionale

All.148_SISAR_FUNZIONALE_CSS_v_2.0

MEDICINADELLO SPORT

Allegato 149 – Modulo MEDICINADELLO SPORT - Analisi Funzionale

All.149_SISAR_FUNZIONALE_MEDICINADELLOSPORT_v_1.0

Medicina Legale Allegato 150 – Modulo MLE (MedicinaLegale) - Analisi Funzionale All.150_SISAR_FUNZIONALE_MLE_v_2.0

EPI – EpidemiologicoRENCAM Allegato 143 – Modulo RENCAM -

Analisi FunzionaleAll.143_SISAR_ FUNZIONALE_RENCAM_v_1.0

CEDAP Allegato 171 – MODULO Certificato diAssistenza al Parto - AnalisiFunzionale

All.171_SISAR_ FUNZIONALE_CEDAP_v_1.0

SIO – OspedalieroEMR Allegato 193 – Modulo Cartella Clinica

- Analisi FunzionaleAll.193_AF_SISAR_EMR_v.1.0

Order Entry Allegato 194 – Modulo SIO-OEP -Analisi Funzionale

All.194_AF_SISAR_OEP_v.1.0

PRONTOSOCCORSO

Allegato 195 – Modulo SIO - PRONTOSOCCORSO - Analisi Funzionale

All.195_AF_SISAR_PSWEB_v.2.1

SALEOPERATORIE

Allegato 196 – Modulo SIO – SALEOPERATORIE - Analisi Funzionale

All.196_AF_SISAR_SOWEB_v.1.0

ADT - Listad'attesa eGestione ricoveri

Allegato 197 – Modulo ADT - Listad'attesa e Gestione ricoveri - AnalisiFunzionale

All.197_AF_SISAR_ADT-LDA_v.1.0




ELIOT Allegato 151 – Modulo ELIOT - AnalisiFunzionale

All.151_SISAR_FUNZIONALE_ELIOT_v_1.0

SRC Allegato 152 – Modulo ELIOT SRC -Analisi Funzionale

All.152_SISAR_FUNZIONALE_SRC_v_1.0

AMC – Amministrazione e ControlloCONTROLLO DIGESTIONE

Allegato 153 – Modulo AMC -CONTROLLO DI GESTIONE - AnalisiFunzionale

All.153_SISAR_ FUNZIONALE_CO.GE_v_2.0

ACQUISTI Allegato 154 – Modulo ACQUISTI -Analisi Funzionale All.154_SISAR_FUNZIONALE_ ACQUISTI_v_2.1

BUDGET Allegato 155 – Modulo AMCBD -BUDGET - Analisi Funzionale All.155_SISAR_FUNZIONALE_BUDGET_v_2.1

CENTRALIZZATO AMC

Allegato 156 – Modulo AMCCE -CENTRALIZZATO AMC - AnalisiFunzionale

All.156_SISAR_FUNZIONALE_CENTRALIZZATO_v_1.0

CESPITI Allegato 157 – Modulo CESPITI -Analisi Funzionale All.157_SISAR_FUNZIONALE_CESPITI_v_2.1

CONTABILITÀ Allegato 158 – Modulo AMCCO -CONTABILITÀ - Analisi Funzionale

All.158_SISAR_FUNZIONALE_CONTABILITA_v_1.0

LOGISTICA Allegato 159 – Modulo LOGISTICA -Analisi Funzionale All.159_SISAR_FUNZIONALE_LOGISTICA_v_2.1

HR – Risorse UmaneRIPRESA –Rilevazionepresenze

Allegato 172 – Modulo HR - RIPRESA- Analisi Funzionale

All.172_SISAR_ FUNZIONALE_HR_RIPRESA_v_1.0

CONTABILITÀGUARDIAMEDICA

Allegato 173 – Modulo HR -PERSWEB – CONTABILITÀGUARDIA MEDICA - AnalisiFunzionale

All.173_SISAR_FUNZIONALE_HR_PERSWEB_CONTAB_GUARD_MED_v_1.0

ContabilitàPersonaleDipendente

Allegato 174 – Modulo HR -PERSEWEB Contabilità PersonaleDipendente - Analisi Funzionale

All.174_SISAR_FUNZIONALE_HR_PERSWEB_CONTAB_PERS_DIP_v_1.0

GESTIONEGIURIDICAPERSONALE

Allegato 175 – Modulo HR -PERSWEB - GESTIONE GIURIDICAPERSONALE - Analisi Funzionale

All.175_SISAR_FUNZIONALE_HR_PERSWEB_GEST_GIURID_PERS_DIP_v_1.0

Portale delDipendente

Allegato 176 – MODULO Portale delDipendente - Analisi Funzionale

All.176_SISAR_FUNZIONALE_Portale_Dipendente_v_1.0

Concorsi Allegato 177 – Modulo HR - Concorsi -Analisi Funzionale All.177_SISAR_FUNZIONALE_CONCORSI_v_2.0

DENUNCE Allegato 178 – Modulo HR -DENUNCE - Analisi Funzionale

All.178_SISAR_FUNZIONALE_HR_DENUNCE_v_1.0

GIURIDICO Allegato 179 – Modulo HR -GIURIDICO - Analisi Funzionale

All.179_SISAR_FUNZIONALE_HR_GIURIDICO_v_1.0

CONTABILITÀCOLLABORATORI COORDINATI

Allegato 180 – Modulo PERSWEB -CONTABILITÀ COLLABORATORICOORDINATI Analisi Funzionale

All.180_SISAR_FUNZIONALE_HR_PERSWEB_COLL_COORD_v_1.0

MEDICINA DEISERVIZI

Allegato 181 – Modulo HR -PERSWEB - MEDICINA DEI SERVIZI- Analisi Funzionale

All.181_SISAR_FUNZIONALE_HR_PERSWEB_CONTAB_MED_SERV_v_1.0

SPECIALISTIAMBULATORIALI

Allegato 182 – HR - PERSWEBCONTABILITÀ SPECIALISTIAMBULATORIALI - Analisi Funzionale

All.182_SISAR_FUNZIONALE_HR_PERSWEB_CONTAB_SPEC_AMB_v_1.0

STIPENDI Allegato 183 – Modulo HR - STIPENDI- Analisi Funzionale

All.183_SISAR_FUNZIONALE_HR_STIPENDI_v_1.0

HR -CENTRALIZZATO

Allegato 184 – HR - CENTRALIZZATO- Analisi Funzionale

All.184_SISAR_FUNZIONALE_HRCENTRALIZZATO_v_1.0

PENSIONI Allegato 185 – MODULO HR -PENSIONI - Analisi Funzionale

All.185_SISAR_FUNZIONALE_HRPENSIONI_v_1.0

CUP – Gestore Risorse CUP




CUPWEB-CASSA Ticket

Allegato 161 – Modulo CUPWEB-CASSA - Analisi Funzionale

All.161_SISAR_ FUNZIONALE_CASSA_v_1.0

Cupweb FO 730 Allegato 162 – Modulo Cupweb FO730 - Analisi Funzionale

All.162_SISAR_ FUNZIONALE_CASSA730_v_1.0

CUPWEB-LISTED'ATTESA

Allegato 163 – Modulo CUPWEB-LISTE D'ATTESA - Analisi Funzionale

All.163_SISAR_ FUNZIONALE_CUPLDA_v_1.0

CUPWEB-HCM-FO

Allegato 164 – Modulo CUPWEB-HCM-FO - Analisi Funzionale

All.164_SISAR_ FUNZIONALE_HCM730_v_1.0

LiberaProfessione

Allegato 165 – Modulo LiberaProfessione - Analisi Funzionale

All.165_SISAR_ FUNZIONALE_LIBERAPROFESSIONE_v_1.0


Allegato 166 – Modulo Portale delCittadino - Analisi Funzionale

All.166_SISAR_FUNZIONALE_Portale_del_cittadino_v_1.0

RipartizioneProventi

Allegato 167 – Modulo RipartizioneProventi - Analisi Funzionale

All.167_SISAR_ FUNZIONALE_RIPRO_v_1.0

CUPWEB-MO-BackOffice

Allegato 168 – Modulo CUPWEB-MO-BackOffice - Analisi Funzionale

All.168_SISAR_FUNZIONALE_BACK-OFFICE_v_1.0

CUP - FRONT-OFFICE

Allegato 169 – Modulo CUP - FRONT-OFFICE - Analisi Funzionale

All.169_SISAR_FUNZIONALE_FRONT-OFFICE_v_1.0

AMBULATORIO(Cartella ClinicaAmbulatoriale)

Allegato 170 – Modulo AMBULATORI -Analisi Funzionale

All.170_SISAR_ FUNZIONALE_AMB_v_2.0

PD – Protocollo, Atti e DocumentaleATTIAMMINISTRATIVI

Allegato 187 – MODULO ATTIAMMINISTRATIVI - Analisi Funzionale All.187_SISAR_FUNZIONALE_ATTI_v_1.0

DOCUMENTALE - AURIGA

Allegato 188 – MODULODOCUMENTALE - AURIGA - AnalisiFunzionale

All.188_SISAR_FUNZIONALE_DOCUMENTALE_v_1.0


Allegato 189 – Modulo ProtocolloInformatico - Analisi Funzionale

All.189_SISAR_FUNZIONALE_PROTOCOLLO_v_1.0

DIR – DirezionaleDWSISAR -SistemadirezionaleSiSaR

Allegato 160 – MODULO DWSISAR -Sistema direzionale SiSaR - AnalisiFunzionale

All.160_SISAR_FUNZIONALE_DWH_v_1.1

SIDI – Sistema Integrato Debito InformativoSIDI Allegato 136 – Modulo SIDI - Analisi

FunzionaleAll.136_AF_SISAR_SIDI_v.2.0

IntegrazioniIntegrazioniSISAR

Allegato 186 – Modulo IntegrazioniSISAR - Analisi Funzionale

All.186_SISAR_FUNZIONALE_INTEGRAZIONI_v_1.1

TrasversaliJBFFRAMEWORK

Allegato 190 – Modulo JBFFRAMEWORK - Analisi Funzionale

All.190_SISAR_FUNZIONALE_JBF_FRAMEWORK_v_1.0

JBF Allegato 191 – Modulo JBF – JBFAnalisi Funzionale

All.191_SISAR_FUNZIONALE_JBF_v_1.0

XMPI Anagraficentralizzate

Allegato 192 – Modulo XMPI Anagraficentralizzate - Analisi Funzionale

All.192_SISAR_ FUNZIONALE_XMPI_v_1.0

ABF Installer Allegato 198 – ABF Installer 20.12.00Manuale Installazione

All.198_MI_ABF_INSTALLER_v_20.12.00.pdf

Lo schema di deployment del sistema SISaR vede la presenza di installazioni centralizzate,

localizzate presso il Centro Servizi Regionale (CSR) della Regione Sardegna, e di installazioni

dipartimentali, localizzate presso i data center delle Aziende Sanitarie.




In particolare, si illustra di seguito il quadro di dettaglio:

SISTEMI/Moduli Installazione

AMC Centralizzato

HR Centralizzato

Protocollo Informatico Centralizzato

Atti Amministrativi Centralizzato

Gestione Documentale Centralizzato

SIO (Ospedaliero) [trasfusionale ELIOT incluso] Dipartimentale

Monitor Pronto Soccorso Centralizzato

SRC + Broker Esami Centralizzato

Anagrafe (XMPI) Centralizzata e Dipartimentale

AAP (Territoriale: CSS, PUA, ADI, RSA, , CONSULTORIO,PROTESICA; SPRESAL, SIAN, MEDICINA LEGALE)

Dipartimentale

Portale Prevenzione (NPC WEB e Portale Amianto) Centralizzato

CUP – SGP Centralizzato

E-Prescription Centralizzato

CUPWEB Centralizzato

Cartella Clinica Ambulatoriale Dipartimentale

Cartella Clinica Ambulatoriale GM Centralizzato

DIR Centralizzato

CEDAP Dipartimentale

RENCAM Centralizzato

Sistema debito informativo (SIDI) Centralizzato

Accesso al Sistema Dipartimentale\Centralizzato

Sistema di accesso SSO, tramite CNS, produzione dei documentisanitari firmabili digitalmente

Dipartimentale\Centralizzato

Integrazioni con Sistemi Terzi Non SISaR (Fascicolo SanitarioElettronico, SILUS, etc.)

Dipartimentale: FSE, SILUS, RIS, AP,INPS, etc.Centralizzato: ANAGS

Middleware di Integrazione: Spagic Dipartimentale\Centralizzato

Per la predisposizione del modello 770 il sistema utilizza un software esterno (TeamSystems), la cui

fornitura è a carico del fornitore SISaR. Anche tale funzionalità è inclusa nell’ambito del presente

appalto.

A seguito dell’istituzione dell’azienda sanitaria unica regionale ATS, negli anni 2017 e 2018 le istanze

SISaR centralizzate delle ex ASL, ora unificate nell’ATS, sono state riconfigurate in una istanza unica.

Pertanto, a livello di sistemi centralizzati AMC, HR, Protocollo Atti e Delibere, Gestione documentale, il

numero di istanze è pari a 5 (ATS, AREUS, AOUCA, AOUSS, AO Brotzu). Tale configurazione potrà




naturalmente variare a seguito di successive riforme nell’organizzazione del Servizio Sanitario

Regionale.

Per quanto concerne gli aspetti infrastrutturali e architetturali, attualmente i sistemi dipartimentali sono

11, corrispondenti alle 8 ASSL (ATS) e alle 3 AO.

Il sistema poggia su un’infrastruttura cloud regionale, denominata H-CLOUD, gestita da un fornitore

terzo con apposito contratto stipulato dalla Direzione Generale degli Affari Generali e della Società

dell’Informazione. La gestione dell’infrastruttura H-CLOUD non è pertanto oggetto del presente

appalto. La piattaforma del sistema H-Cloud vede la presenza di:

n° 1 Data Center Regionale (DC01-CRESSAN) adibito all’erogazione dei servizi sanitari

centralizzati ed avente funzionalità di governo di tutta l’infrastruttura.

n° 10 Data Center (2 Secondari e 8 Periferici) ubicati presso le ASSL/AO/AOU della Sardegna

ed adibiti all’erogazione dei servizi sanitari decentrati ed in parte a funzionalità di Disaster

Recovery (DR) dell’architettura SISaR.

All’interno di tale piattaforma l’architettura di computing vede la presenza di:

Fabric Compute, rappresentati da cluster Hyper-v su tutti i Data Center, i quali costituiscono

l’infrastruttura di virtualizzazione atta a sostenere il carico di lavoro delle macchine virtuali

(VM).

Fabric Management, collocato presso il DC01-CRESSAN (CSR), il quale realizza la

centralizzazione e l'automatizzazione delle funzioni di gestione complesse di tutti i Fabric

Compute distribuiti sugli 11 nodi.

L’infrastruttura hardware della ASSL di Sassari e della AOU di Sassari è, allo stato attuale, comune.

A titolo informativo, si rappresenta che, nell’ambito del contratto di gestione e manutenzione del

SISaR attualmente in essere nelle more dell’affidamento della presente procedura, si prevede di

effettuare un set di attività essenziali per l’adeguamento di base del sistema in coerenza con il GDPR.

Esternamente a tale contratto, con altra procedura, è stato inoltre programmato un intervento di

adeguamento dell’infrastruttura di database ai fini del GDPR.

1.2. ACRONIMI

Acronimo Descrizione

ALM Application Lifecycle Management

AA.SS. Aziende SanitarieADI Assistenza Domiciliare IntegrataAMC Sistema Amministrativo ContabileANAGS Anagrafe Sanitaria (Assistibili)




ANFFASS Associazione Nazionale di Famiglie con Persone con DisabilitàIntellettiva e/o Relazionale

AO Azienda OspedalieraAOU Azienda Ospedaliera UniversitariaAPI Application Programming Interface

AREUS Azienda Regionale dell'Emergenza e Urgenza della SardegnaASL Azienda Sanitaria LocaleASSL Area Socio Sanitaria LocaleATS Azienda per la Tutela della SaluteBMI Body Mass IndexBPMN Business Process Model and NotationCCA Cartella Clinica AmbulatorialeCDI Centri Diurni IntegratiCDI Cure Domiciliari Integrate (vedere ADI)CML Commissione Medico Locale (INPS)CMS Commissione Medico Superiore (INPS)CR Change RequestCRESSAN Centro regionale servizi sanitari (area del CSR dedicata alla sanità)CSR Centro Servizi RegionaleCUP Centro Unico di PrenotazioneDBA Database AdministratorDB DatabaseDEC Direzione dell’esecuzione del contrattoDL Direzione lavoriDNS Domain name systemDPO Data Protection OfficerEA Enterprise ArchitectureEMR Electronic Medical RecordENS Ente Nazionale SordiESB Enterprise Service BusETL Extract, Transform, LoadFAD Formazione a distanzaFSE Fascicolo Sanitario ElettronicoFTE Full Time EquivalentGCC Gruppo di coordinamento CUPGDPR General Data Protection RegulationGLU Gruppo di Lavoro per l'Usabilità - Funzione PubblicaH-Cloud Infrastruttura cloud regionale dedicata alla sanitàHL7 Health level 7HR Human ResourcesHW HardwareINPS Istituto Nazionale Previdenza Sociale

Medir Medici in rete (sistema informativo che realizza l’infrastrutturatecnologica del Fascicolo Sanitario Elettronico)

MMG Medico di Medicina GeneraleMNA Mini Nutritional AssessmentOE Order EntryOSA Operatore Settore AlimentarePA Pubblica AmministrazionePLS Pediatra di Libera Scelta

PL/SQL Procedural Language/Structured Query Language (linguaggio diprogrammazione per database Oracle)

PRCIF Piano regionale di controllo ufficiale sulle matrici alimentari, sulcommercio e sull’impiego dei prodotti fitosanitari

PRGLA Programma per la riduzione delle Liste d’attesa




PS-EDS Patient Summary-Emergency Data SetPRIC Piano regionale dei controlli ufficialiPS Pronto SoccorsoRAS Regione Autonoma della SardegnaRDP Remote Desktop ProtocolRSA Residenze sanitarie assistenzialiRTI Raggruppamento temporaneo di impreseRTR Rete Telematica RegionaleSA Stazione AppaltanteSAL Stato Avanzamento LavoriSIA Sistema Informativo AmministrativoSIAD Sistema Informativo Nazionale Assistenza DomiciliareSIAN Servizio Igiene degli Alimenti e della NutrizioneSIDI Sistema Integrato Debito InformativoSIO Sistema Informativo OspedalieroSISP Sistema Informativo Igiene e Sanità PubblicaSLA Service Level Agreement – Livelli di servizioSOA Service Oriented ArchitectureSPRESAL Servizio Prevenzione e Sicurezza negli Ambienti di Vita e di LavoroSRC Struttura Regionale di CoordinamentoSSN Servizio Sanitario NazionaleSSR Servizio Sanitario RegionaleSUS System Usability ScaleSW SoftwareTOJ Training on the jobTSO Team di Supporto OperativoTT Trouble TicketingUCI Unione Italiana dei Ciechi e degli IpovedentiUML Unified Modeling LanguageUVI Unità Valutazione InternaUX User ExperienceVAT Verbale AttivitàVPN Virtual Private Network – rete privata virtualeXML eXtensible Markup LanguageXSD XML Schema definition

2. OGGETTO DELLA PROCEDURA

Oggetto della procedura è l’affidamento dei servizi di gestione, manutenzione e reingegnerizzazione

dell’architettura del SISaR e l’acquisizione dell’infrastruttura di integrazione, come meglio descritto nei

capitoli seguenti.

Tutto il codice sorgente del software e tutta la documentazione tecnica, funzionale e la manualistica di

cui è composto il SISaR sono e resteranno di proprietà della Regione Autonoma della Sardegna.

Tutta la documentazione ed i sorgenti software sono disponibili per essere valutati dai concorrenti alla

presente procedura con l’obiettivo di poter proporre una offerta avendo a disposizione le informazioni

necessarie.




Tutti questi oggetti saranno consegnati all’aggiudicatario della presente gara per la presa in carico del

sistema. L’aggiudicatario potrà e dovrà modificare il software e la documentazione, che, aggiornata,

resterà comunque integralmente di proprietà della Regione Autonoma della Sardegna.

Si deve inoltre tenere conto che il sistema SISaR, per ovvie ragioni, è in continua manutenzione

normativa ed evolutiva e, pertanto, i sorgenti software e la documentazione tecnica che saranno

consegnati all’aggiudicatario ai fini della presa in carico potranno essere differenti (presumibilmente in

misura estremamente ridotta) rispetto alle versioni allo stato dell’arte attualmente disponibili per i

concorrenti della presente gara.

Alla conclusione del contratto oggetto del presente appalto, i documenti tecnici e funzionali,

unitamente al codice sorgente, dovranno essere riconsegnati attentamente aggiornati allo stato

dell’arte finale, in modo che siano disponibili per i concorrenti della/e prossima/e procedura/e per la

gestione e manutenzione del SISaR.

Le prestazioni oggetto del presente appalto riguardano tutto il parco applicativi SISaR come descritto

in premessa. Si precisa inoltre che non sono oggetto della presente procedura i servizi di Call Center

per il CUP.

Il concorrente dovrà descrivere come intende affrontare complessivamente quanto richiesto dalla

presente procedura dettagliando l’organizzazione, il team di progetto, le procedure e i processi che

applicherà, per ogni servizio, prestazione e fornitura richiesta, come meglio precisato nei capitoli

seguenti e nello schema di offerta tecnica. È richiesto che il concorrente illustri precisamente come

intende assicurare i livelli di servizio richiesti\offerti e gli obiettivi prefissati dal presente capitolato.

2.1. Fasi del progetto e durata

L’esecuzione del contratto sarà suddivisa in due fasi temporali consecutive:

1. Fase 1 - Presa in carico del sistema (durata 3 mesi). Questa fase preparatoria è finalizzata

a consentire all’aggiudicatario di predisporsi all’erogazione delle prestazioni e acquisire le

competenze operative per la presa in carico effettiva del sistema SISaR. In questa fase non è

pertanto prevista alcuna produzione di servizi da parte dell’aggiudicatario e

conseguentemente la stessa non presenta oneri per l’Amministrazione Aggiudicatrice.

Durante questo periodo, infatti, continuerà, in parallelo al nuovo contratto, ad essere vigente

l’attuale contratto di gestione e manutenzione; il precedente gestore erogherà la formazione e

il supporto on the job all’aggiudicatario, secondo le modalità precisate nel capitolo 7, e

continuerà ad erogare i servizi di gestione e manutenzione del sistema nell’ambito del

precedente contratto. L’aggiudicatario della presente procedura avrà l’obbligo di assicurare la




presa in carico dell’intero sistema a partire dal primo giorno successivo al termine di questa

Fase.

2. Fase 2 – Erogazione dei servizi (durata 24 mesi, dal mese 4 al mese 27): in questa fase è in

capo all’aggiudicatario della presente procedura l’erogazione di tutti i servizi oggetto del

contratto.

Relativamente alle attività della Fase 2, è prevista l’opzione di cui all'art. art. 63, comma 5, D.Lgs. n.

50/2016, per la ripetizione, totale o parziale, alla conclusione dei 24 mesi della Fase 2, di servizi

analoghi a quelli già aggiudicati, per un massimo di ulteriori 24 mesi.

È altresì prevista l’opzione di proroga tecnica dell’appalto fino a un termine massimo stimabile in 12

mesi, al fine di assicurare la continuità dei servizi indispensabili in pendenza di una nuova gara e per il

tempo strettamente necessario alla conclusione della stessa, ex art. 106 c. 11 D.Lgs. n. 50/2016.

AREA 1 Gestione e Manutenzione Durata del servizio (mesi)

A1.1 Manutenzione Preventiva, Adeguativa, Correttiva, Perfettiva 24 (da mese 4 a mese 27)

A1.2 Miglioramento delle performance e dell’usabilità 24 (da mese 4 a mese 27)

A1.3 Manutenzione Evolutiva 24 (da mese 4 a mese 27)

A1.4 Servizi Specialistico-Applicativi 24 (da mese 4 a mese 27)

A1.5 Gestione degli Ambienti Applicativi di Test e di Produzione 24 (da mese 4 a mese 27)

A1.6 Gestione Sistemistico-Applicativa 24 (da mese 4 a mese 27)

A1.7 Servizio di Help Desk 24 (da mese 4 a mese 27)

A1.8 Servizio di Reperibilità H24 Mission-Critical 24 (da mese 4 a mese 27)

AREA 2 Realizzazione nuova architettura

A2.1 Sistema Enterprise Service Bus 24 (da mese 4 a mese 27)

A2.2 Evoluzione e migrazione su nuova infrastruttura e disaccoppiamentofunzionale 24 (da mese 4 a mese 27)

AREA 3 Transizione

A3.1 Transizione verso il fornitore subentrante 3 (ultimi 3 mesi del contratto)

AREA 4 Servizi Trasversali

A4.1 Service e Project Management 24 (da mese 4 a mese 27)

A4.2 Change Management, Formazione e Affiancamento 24 (da mese 4 a mese 27)

Tabella dei Servizi richiesti e durata contrattuale

I servizi di transizione dell’Area 3 saranno attivati solo negli ultimi 3 mesi del contratto, considerando

anche eventuali rinnovi come sopra specificato, e solo se il fornitore (o i fornitori) subentrante a

seguito di nuova gara sarà diverso in tutta la composizione (se RTI o Azienda singola). In tale lasso di

tempo l’aggiudicatario, oltre a erogare i servizi di gestione, manutenzione e reingegnerizzazione,

erogherà i servizi atti a garantire il passaggio di consegne al nuovo fornitore (o ai fornitori).




2.2. Precisazioni in merito alla possibilità di sostituzione degli applicativi

La sostituzione parziale o totale degli applicativi esistenti con nuovi applicativi non è preclusa, ma non

costituisce oggetto di offerta né di valutazione nell’ambito della presente procedura. Tale opzione

potrà essere proposta, in fase di esecuzione del contratto, all’esame dell’Amministrazione

Aggiudicatrice, che potrà discrezionalmente approvarla o respingerla in funzione delle proprie

valutazioni. In ogni caso l’eventuale proposta non sarà ricevibile se non soddisferà almeno entrambe

le seguenti condizioni:

assenza totale di oneri diretti e indiretti in capo all’Amministrazione Aggiudicatrice;

assenza totale di impatti sulla funzionalità e operatività dei sistemi e sulla continuità delle

attività del Servizio Sanitario Regionale su di essi insistenti.

Tutti gli oneri connessi e derivanti da tale opzione di sostituzione degli applicativi esistenti saranno

integralmente in capo all’aggiudicatario, che dovrà farsi carico di tutti i costi diretti e indiretti relativi alle

attività tecniche ed organizzative necessarie, inclusi quelli di formazione, affiancamento e change

management e quelli che si dovessero originare lato sistemi terzi per realizzare le modifiche atte a

garantire la continuità delle integrazioni esistenti con il SISaR. In particolare, nel caso delle

integrazioni con fornitori terzi, l’aggiudicatario che intenderà sostituire gli applicativi SISaR preesistenti

dovrà quindi accordarsi anche in termini economici e contrattuali con tali fornitori e sostenere tutti gli

eventuali oneri di adeguamento richiesti dai fornitori terzi. La proposta di sostituzione dovrà prevedere,

a carico del proponente, anche una serie di azioni, di entità motivatamente congrua, inerenti alla

formazione, all’affiancamento e ad ogni altro servizio di accompagnamento, di consulenza, di supporto

organizzativo, che si dovesse ritenere necessario per attuare la stessa. Al nuovo software si

applicheranno tutte le disposizioni in materia di proprietà valide per il sistema esistente; pertanto, non

potranno essere proposti software proprietari, in quanto qualsiasi applicativo eventualmente sostituito

diventerà di proprietà della Regione Sardegna, secondo le disposizioni del presente appalto, e

l’aggiudicatario dovrà consegnarne tutto il codice sorgente e la relativa documentazione, che potranno

essere successivamente condivisi con l’aggiudicatario di altra gara alla conclusione del contratto

relativo alla presente procedura e essere messi a disposizione di altre Regioni o ASL con cui la

Regione Sardegna dovesse effettuare un accordo per il riuso del software ai sensi del Codice per

l’Amministrazione Digitale. L’aggiudicatario dovrà formulare la proposta di sostituzione mediante

presentazione di apposito progetto, da sottoporre all’approvazione discrezionale dell’Amministrazione

Aggiudicatrice. Si sottolinea che l’oggetto della presente procedura è l’erogazione dei servizi richiesti

sul sistema attuale, e pertanto l’aggiudicatario è tenuto in ogni caso ad erogare i servizi oggetto del

presente appalto sul sistema ricevuto in consegna, anche nel caso in cui l’Amministrazione

Aggiudicatrice non approvi l’eventuale progetto di sostituzione proposto in fase di esecuzione.




2.3. Linee guida Usabilità

Nel presente appalto è richiesto che si applichino, nella realizzazione e reingegnerizzazione delle

componenti di interfaccia utente, i principi allo stato dell’arte in tema di progettazione orientata

all’utente, usabilità e user experience.

L'aggiudicatario è tenuto ad erogare i servizi del presente appalto nel rispetto delle Linee Guida AGID

in materia di design per i servizi digitali della PA e di design per i siti web della PA, pubblicate sul

portale dell’AGID stessa. In tale ottica, il concorrente deve specificare la metodologia che intende

adottare e il processo operativo che intende seguire per la valutazione e l’implementazione

dell’usabilità (ISO 9241-210:2010), sia nelle fasi di progettazione, analisi e design, sia in fase

esecutiva, attraverso l’utilizzo di un approccio Human-Centered Design. Tutte le attività di

manutenzione evolutiva, inclusa quella normativa, che prevedano modifiche o integrazioni

all’interfaccia utente dovranno essere accompagnate, prima dell’avvio delle implementazioni, da

adeguata progettualità, debitamente documentata, specificamente orientata alla User Experience

(UX), svolta da un esperto tecnico qualificato nella User Experience.

Tale processo, così come indicato dalle Linee Guida “Appalti web e Human-Centred Design”1

realizzate dal GLU (Gruppo di Lavoro per l’Usabilità) del Dipartimento della Funzione Pubblica, deve

prevedere almeno le seguenti attività:

1. Definizione di personas e scenari d’uso, da condividere con il team di sviluppo (es. designer,

sviluppatore, copywriter), al fine di esplicitare le tipologie di utenti e le loro modalità

d’interazione con il servizio, l’applicativo o il sito web. Devono essere consegnati i materiali

prodotti spiegando il processo di sviluppo utilizzato (es. interviste, focus group).

2. Monitoraggio della User Experience (es. facilità d’uso, fiducia, soddisfazione, gradevolezza

estetica), attraverso un questionario on-line, del servizio, applicativo o sito pre-esistente e di

quanto realizzato nell’ambito del presente appalto.

3. Svolgimento di almeno due test di usabilità di tipo formativo, con un minimo di 5 utenti e 8

task per ciascun test, da effettuarsi durante il processo di sviluppo su prototipi, wireframe o

versioni non definitive del servizio, applicativo o sito, al fine d’identificare le principali criticità e

provvedere alla loro correzione prima del rilascio. Prima di svolgere il secondo test, le criticità

emerse nel primo dovranno essere state risolte. Le tipologie di partecipanti da coinvolgere e i

compiti di navigazione da usare durante il test devono essere proposti e approvati da un

referente dell’utenza all’uopo nominato e dalla DEC. I partecipanti coinvolti nel secondo test

1 Disponibile all’indirizzo: < http://www.funzionepubblica.gov.it/glu#Il%20Protocollo >




dovranno essere diversi da quelli coinvolti nel primo. I risultati devono essere documentati

tramite un report che deve includere:

numero dei partecipanti e loro caratteristiche anagrafiche;

compiti di navigazione utilizzati;

tasso di successo;

lista dei problemi rilevati (con possibili soluzioni) e loro priorità;

metriche soggettive (es. SUS, Umux-lite).

4. Verifica delle alberature di navigazione e relative nomenclature attraverso card-sorting o

reverse card-sorting.

5. Svolgimento di un test di usabilità di tipo sommativo (minimo 15 utenti) per la verifica del

servizio, applicativo o sito online o di un prototipo funzionante, in prossimità del rilascio. Le

tipologie di partecipanti e i compiti di navigazione da usare durante il test devono essere

proposti e approvati da un referente dell’utenza all’uopo nominato e dalla DEC. Il test deve

essere documentato tramite un report e deve includere metriche di performance (cfr. ISO/TR

16982:2002) oggettive (es. tasso di raggiungimento dell’obiettivo, numero di errori) e

dell’esperienza d’uso soggettiva (es. piacevolezza, coinvolgimento, motivazione). I risultati dei

test di usabilità devono essere forniti seguendo il format definito dalla ISO/IEC 25062:2006 e

devono comprendere anche un elenco di problemi rilevati e da risolvere in revisioni future.

Lo svolgimento delle suddette attività è obbligatorio e vincolante per considerare l’esecuzione del

lavoro completa, ma non vi sono clausole vessatorie rispetto al livello di usabilità, oggettivo e

soggettivo, misurato.

L’utilizzo del Protocollo eGLU LG 2018.1, integrato nelle Linee guida di design per i servizi web della

PA, è considerato lo standard di qualità minimo, a cui l’aggiudicatario dovrà attenersi, per quanto

riguarda le modalità di preparazione, esecuzione ed analisi delle attività richieste al punto “3”.

Per la valutazione della User Experience di cui al punto “2”, si suggerisce l’utilizzo del questionario

validato Us.E. 2.0 solo per quanto riguarda le seguenti dimensioni connesse all’usabilità:

maneggevolezza (i.e. semplicità d’uso); soddisfazione (i.e. utilità percepita); attrattiva (i.e. look and

feel).

Per chiarimenti relativi alla terminologia utilizzata ci si può riferire al glossario delle Linee Guida

“Appalti web e Human-Centred Design” e alle sezioni “Terms and definitions” delle norme tecniche

che seguono.

Per lo svolgimento delle attività descritte fare riferimento alla seguente normativa tecnica:

ISO 9241-11 " Ergonomics of human-system interaction - Guidance on usability"




UNI EN ISO 9241-210 - Ergonomia dell'interazione uomo-sistema - Parte 210: Processi di

progettazione orientata all'utente per sistemi interattivi

ISO/TR 16982 - Usability methods supporting human-centred design

ISO/IEC 25062 - Common Industry Format (CIF) for usability test reports

2.4. Metodologie di sviluppo software e gestione di progetto

L’aggiudicatario dovrà erogare i servizi oggetto del contratto facendo ricorso principalmente a

metodologie agili, con riferimento sia al vero e proprio sviluppo software che alle tecniche di gestione

del progetto nel suo complesso, assicurando il raggiungimento degli obiettivi mediante cicli di sviluppo

iterativi e incrementali delle attività richieste, sulla base di un allineamento e di una verifica costante

con la committenza e con gli utenti rispetto all’ordine di priorità degli obiettivi e delle funzionalità da

rilasciare, ai risultati di ogni ciclo ed alle procedure stesse di sviluppo software e gestione di progetto.

Ogni iterazione dovrà avere l’obiettivo di trasformare un insieme di requisiti selezionati in deliverable di

progetto e/o funzionalità del prodotto consegnabili e potenzialmente rilasciabili in produzione,

concludendosi con la presentazione all’utenza di quanto prodotto al fine di ricevere un feedback sul

soddisfacimento delle attese e di ricevere indicazioni per la messa in produzione di quanto realizzato

nell’iterazione corrente e per la definizione, sulla base di criteri di priorità e valore, dell’incremento di

prodotto/servizio/funzionalità da sviluppare nell’attuazione dell’iterazione successiva.

In considerazione della complessità e fluidità del contesto operativo, organizzativo, tecnico e

istituzionale su cui opera il contratto, le metodologie di sviluppo software e gestione di progetto

adottate dovranno in ogni caso essere in grado di accogliere agevolmente cambiamenti del contesto e

dei requisiti nel corso dei cicli di lavoro e di sviluppo. Le metodologie proposte dovranno essere

flessibili ed adattabili anche rispetto alla dimensione della componente software da realizzare, che

potrebbe variare da qualche unità a diverse centinaia di FTE. Particolare attenzione dovrà essere

rivolta alla qualità del software sviluppato, anche attraverso test accurati e automatici, tecniche di

integrazione continua, code inspection, audit di qualità e applicazione di standard di secure coding. È

inoltre richiesta un’elevata capacità di parallelizzazione delle attività.

In linea generale, i documenti che dovranno essere prodotti e aggiornati nell’ambito di qualunque

metodologia specifica che verrà proposta, sono almeno i seguenti:

Piano/i di sviluppo che preveda/no una o più iterazioni incrementali

Analisi dei processi di business

Analisi dei requisiti cliente

Specifica dei requisiti software

Specifica architetturale delle soluzioni software

User Experience Design




Manuali utente e Amministratore

Piani dei test

Report dei test

Gli elaborati di analisi e progettazione dovranno essere corredati da diagrammi UML (use case

diagram, activity diagram, sequence diagram, class diagram, deployment diagram, state diagram, ...)

e BPMN.

Nelle sessioni di verifica, a cura della Direzione dell’Esecuzione del Contratto, previo piano di test

predisposto dall’Aggiudicatario, ma comunque modificabile dall’Amministrazione aggiudicatrice, il

software dovrà risultare esente da malfunzionamenti.

2.4.1 Aspetti metodologici specifici relativi alla protezione dei dati personali

Nella progettazione ed erogazione dei servizi oggetto dell’appalto, è richiesta un’elevata competenza

e attenzione in relazione al rispetto del General Data Protection Regulation – GDPR, in particolare per

quanto riguarda i principi di Privacy by Design e Privacy by Default.

A tale proposito, il concorrente dovrà illustrare con quali strumenti e metodologie intende perseguire a

livello strutturale e organizzativo i seguenti principi cardine:

prevenire non correggere: i rischi devono essere valutati in fase di analisi e progettazione,

determinando probabilità, impatti e contromisure, e la modalità realizzativa deve essere

adeguatamente predisposta per prevenire il loro verificarsi;

privacy come impostazione di default (ad esempio, non deve essere obbligatorio compilare un

campo di un form il cui conferimento di dati è facoltativo, etc.);

privacy incorporata nel progetto “by design” (ad esempio, l'utilizzo di tecniche di

pseudonimizzazione o minimizzazione dei dati, etc.);

massima funzionalità, in maniera da rispettare tutte le esigenze (rifiutando le false dicotomie

quali più privacy = meno sicurezza);

sicurezza durante tutto il ciclo del prodotto o servizio;

visibilità e trasparenza del trattamento: tutte le fasi operative devono essere trasparenti in

modo che sia verificabile la tutela dei dati;

centralità dell'utente (rispetto dei diritti, tempestive e chiare risposte alle sue richieste di

accesso, etc.).

Il sistema di tutela dei dati personali deve porre l'utente al centro, in tal modo obbligando i soggetti

titolari e responsabili ad una tutela effettiva da un punto sostanziale, non solo formale; non è

sufficiente che la progettazione dei sistemi sia formalmente conforme alla norma se poi l'utente non è

realmente tutelato nei fatti. Come noto, il principio di privacy by default (protezione per impostazione




predefinita) prevede, in particolare, che per impostazione predefinita si dovrebbero trattare solo i dati

personali nella misura minima necessaria e sufficiente per le finalità previste e per il periodo

strettamente necessario a tali fini. Occorre, quindi, progettare le modalità di trattamento dei dati

garantendo la non eccessività dei dati raccolti.

2.5. Open Data e formato dei dati

La grande quantità di dati e informazioni trattati e registrati nel SISaR costituisce un patrimonio

informativo che può essere valorizzato, analizzato e riusato, con rispettive e specifiche cautele e

limitazioni, secondo quanto previsto dalla normativa, da parte di privati, cittadini o enti pubblici. Alcuni

dati sono soggetti a vincoli precisi, quali la sicurezza nazionale o la tutela della privacy, altri invece

possono essere diffusi. Come noto, gli Open Data (o “Dati Aperti”) sono quelle tipologie di dati

liberamente accessibili e privi di restrizioni che possono essere analizzati e riusati da privati e cittadini,

a livello nazionale ed europeo.

Pertanto, secondo quanto previsto nel progetto OpenRAS, in ottemperanza alle DGR 4/2 del 5/2/2014

e 57/17 del 25/11/2015, l’aggiudicatario, nel rispetto delle Linee guida regionali sugli Open Data della

Regione Sardegna, dovrà prevedere opportune implementazioni relative agli aspetti tecnico-

organizzativi (piano editoriale, metadatazione, ETL, connettori) da applicarsi al riuso e interscambio

dei dati aperti attraverso il portale regionale Open Data. I requisiti che dovranno essere soddisfatti

sono i seguenti (si veda l’Allegato alla Delib.G.R. n. 57/17 del 25.11.2015 - Linee guida Open Data per

la Regione Sardegna):

il sistema deve esporre i dati in formato “aperto”, con l’implementazione di appositi

meccanismi atti a garantire l’inserimento di dataset completi da parte degli operatori;

i dataset devono essere corredati di metadati (da concordare in fase di esecuzione del

contratto);

i dataset più significativi devono essere tra loro correlati al fine di realizzare dataset strutturati

(Linked Open Data);

deve essere possibile pubblicare automaticamente i dataset sul portale regionale Open Data;

i dataset devono essere opportunamente storicizzati, al fine di effettuare confronti tra serie

create in momenti temporali diversi;

devono essere realizzati opportuni meccanismi per la disponibilità dei dati secondo modalità

standard che consentano l’accesso da parte di applicazioni terze;

i dataset devono essere corredati di apposita documentazione descrittiva relativa alle modalità

di generazione e al loro utilizzo;

ciascun dataset prodotto sarà di proprietà della Regione Autonoma della Sardegna \ SSR.




Il concorrente, nell’offerta tecnica, dovrà proporre un piano di possibili scenari di apertura e riutilizzo

dei dati aperti raccolti e contenuti all'interno del SISaR, descrivendo un piano editoriale, i principali

aspetti tecnici quali metadatazione, ETL, connettori, nonché dettagliando il dimensionamento e la

composizione dei profili del team coinvolto e dimostrandone la coerenza e congruità rispetto alle

modalità di erogazione proposte per il servizio.

2.5.1 Formato dei dati

Ai sensi della normativa in materia di amministrazione digitale (D.Lgs. 82/2005) e trasparenza (D.Lgs.

97/2016), il sistema dovrà consentire l’esportazione di dati in formato di tipo aperto, e cioè un formato

di dati reso pubblico, documentato esaustivamente e neutro rispetto agli strumenti tecnologici

necessari per la fruizione dei dati stessi. In particolare, sono richiesti almeno il formato CSV per le

informazioni con struttura tabellare e il formato PDF per la rappresentazione di documenti contenenti

testo e immagini.

L’ambito di applicazione del presente articolo è relativo agli Open Data, a tutta la reportistica estraibile

dai moduli SISaR, incluso il sistema Direzionale, ed ai report/estrazioni ad hoc espressamente

richiesti dall’Amministrazione.

3. AREA 1 – SERVIZI DI GESTIONE E MANUTENZIONE

Oggetto delle attività di quest’area è la gestione e manutenzione del sistema SISaR, in continuità

operativa. I servizi dovranno ricomprendere tutte le azioni necessarie per assicurare che il sistema sia

sempre efficiente, usabile, disponibile, affidabile, performante, tecnologicamente e funzionalmente

aggiornato, allineato con la normativa vigente.

Gli aggiornamenti e le modifiche del software e i rilasci di nuove versioni del sistema, siano essi

appartenenti alla componente centrale o a quella dipartimentale ospedaliera e territoriale, che

andranno a innovare, consolidare o estendere i sistemi preesistenti, dovranno essere considerati

come facenti parte dell’oggetto delle attività previste in quest’area, costituendo ogni release una nuova

baseline di riferimento da gestire e manutenere.

Ove non diversamente specificato, i servizi dovranno essere di norma erogati nei giorni lavorativi dal

lunedì al venerdì almeno nelle fasce orarie 08:00 – 18:00. Previo adeguato preavviso e senza oneri

aggiuntivi rispetto alle modalità ordinarie, l’Aggiudicatario dovrà assicurare la disponibilità dei servizi

anche in giorni e orari al di fuori dei suddetti nel caso di interventi straordinari e specifici che, a

giudizio della DEC per ragioni di urgenza o tutela della continuità operativa del servizio sanitario

regionale, necessitino di tale modalità peculiare di attuazione.




Come scritto nel capitolo 2.3, anche nell’erogazione dei servizi di manutenzione che prevedono

implementazione di software, è richiesto che, per la componente di interfaccia utente, si applichino la

Progettazione orientata all’utente e i principi e le tecniche di usabilità e User Experience. È richiesto

che il servizio di gestione e manutenzione sia sottoposto ad audit interno ed esterno dall’Ente

certificatore dell’Azienda concorrente (o dell’Azienda concorrente mandataria se trattasi di RTI). Gli

esiti dell’audit dovranno essere prontamente condivisi con l’Amministrazione Aggiudicatrice.

Qualsiasi nuovo sviluppo dovrà rispettare le prescrizioni del GDPR, con particolare riferimento alla

Privacy by Design e Privacy by Default. Nel caso in cui su un nuovo componente si rilevi un problema

relativo a questo aspetto, esso verrà considerato un errore da correggere nell’ambito del servizio di

manutenzione correttiva. In relazione alle tematiche GDPR, si coglie l’occasione per ricordare che

l’Assessorato, in conformità con la delibera della Giunta Regionale Delibera della Giunta Regionale

del 19 febbraio 2019, n. 8/76 - Azione 2.2.2 – Progetto per la reingegnerizzazione dell’infrastruttura di

database per il servizio sanitario regionale, ha programmato (esternamente alla presente procedura)

l’acquisizione degli strumenti utili per gli adempimenti GDPR a livello di infrastruttura di database.

L’Amministrazione Aggiudicatrice, per il tramite della società in house SardegnaIT, metterà a

disposizione le opportune VPN necessarie a raggiungere i sistemi SISaR presso i rispettivi siti di

installazione. Tali VPN dovranno essere richieste ed autorizzate secondo le modalità definite da

SardegnaIT.

3.1. Servizio A1.1: Manutenzione Preventiva, Adeguativa, Correttiva, Perfettiva

3.1.1 Manutenzione preventiva

Il servizio di manutenzione preventiva è volto a modificare il software per controllare e contenere i

rischi di criticità e malfunzionamenti, rendere più semplici le correzioni, gli adattamenti e le migliorie, e

ridurre la probabilità di guasto e di degradazione del funzionamento del sistema e dei singoli moduli. Il

servizio consiste in revisioni interne strutturali del prodotto e azioni di software reengineering,

finalizzate a migliorarne la manutenibilità. Deve essere garantito continuativamente per tutta la durata

del progetto ed eseguito ad intervalli predeterminati. Rientrano in questa categoria il rilascio di

eventuali nuove versioni o reingegnerizzazioni dei sistemi e dei moduli, secondo quanto previsto da

piani di rilascio aggiornati trimestralmente, ovvero a seguito della scoperta di elementi del sistema che

possano dar luogo a potenziali situazioni di guasto e malfunzionamento e che pertanto debbano

essere preventivamente corretti.

Secondo le scadenze indicate nel cap. 12, l’Aggiudicatario dovrà consegnare e aggiornare un piano

della manutenzione preventiva, da sottoporre all’approvazione della DEC.

Tutti gli interventi di manutenzione preventiva devono essere gestiti secondo il seguente processo:




- Evidenza dell’attivazione di una manutenzione con registrazione sul sistema di TT.

- Analisi e descrizione dell’oggetto della manutenzione.

- Avvio del processo di manutenzione ed esecuzione come da processo di sviluppo software

(rif. cap. 2.4).

- Tracciamento di tutti i dati relativi alla risoluzione sul sistema Jira.

La manutenzione preventiva deve tener conto della frequenza di segnalazioni di malfunzionamenti

ricorrenti per singoli moduli o componenti, anomalie software o segnalazioni di rallentamenti o blocchi.

Sulla base di questi indicatori, ma anche attraverso tecniche di code inspection, si dovranno prevenire

malfunzionamenti e migliorare le performance dei componenti/sistemi.

Nell’offerta tecnica il concorrente dovrà descrivere le metodologie che intende utilizzare e le modalità

di erogazione del servizio. Il concorrente dovrà descrivere inoltre l’organizzazione del servizio,

dettagliando il dimensionamento e la composizione dei profili del team coinvolto e dimostrandone la

coerenza e congruità rispetto alle modalità di erogazione proposte per il servizio. Dovrà infine

giustificare come riuscirà a garantire gli SLA richiesti e dichiarare eventuali SLA migliorativi (cfr.

capitolo 13).

L’importo contrattuale per i servizi sopra descritti verrà riconosciuto con valore a corpo unitario ed

erogato a canone.

3.1.2 Manutenzione adeguativa e adattativa

Il servizio di manutenzione adeguativa e adattativa è volto ad assicurare tutti quegli adattamenti

secondari e ordinari necessari per mantenere il sistema e i prodotti allineati e adattati a cambiamenti

nel contesto sia tecnologico (p.e. adeguamenti conseguenti a sostituzione di hardware e software di

base, etc.) che organizzativo e funzionale (p.e. modifiche limitate alle funzionalità e alle

configurazioni/parametrizzazioni conseguenti a nuove esigenze, revisioni di processo, riforme e

variazioni nella normativa).

Il servizio comprende le attività volte ad assicurare la costante aderenza delle procedure e dei

programmi alla evoluzione tecnologica e del contesto organizzativo e funzionale, nel periodo di

riferimento contrattuale. Il servizio è altresì volto a garantire il funzionamento degli applicativi SISaR

sulle nuove versioni del software di base delle postazioni utente e dei server, in termini di versione dei

sistemi operativi e dei browser Internet. Pertanto, non potrà, ad esempio, essere considerato

ammissibile che l’utilizzo di applicativi SISaR possa essere vincolato all’utilizzo di specifici software di

base (quali sistema operativo e browser Internet), per i quali non sia più garantita l’assistenza, la

manutenzione correttiva e il rilascio di patch di sicurezza da parte dei rispettivi produttori.




Ricadono nella tipologia delle manutenzioni adeguative gli interventi che richiedono un impegno di

carattere circoscritto ed in ogni caso un impatto non strutturale, ossia che, benché possano

comportare modifiche alle logiche applicative e alla base dati del software, non ne implichino lo

stravolgimento o l’implementazione/fornitura ex-novo di nuove componenti applicative o moduli

funzionali.

Come caso particolare del precedente, il servizio di manutenzione ordinaria per adeguamenti

normativi ha lo scopo di assicurare il costante aggiornamento delle funzionalità del software

applicativo rispetto a variazioni normative con impatto ridotto o moderato sulla struttura del sistema,

derivanti da atti ufficiali di livello comunitario, nazionale e regionale, che comportino interventi di

modifica del software medesimo rientranti nei limiti di cui al precedente capoverso. Il servizio si

applica agli interventi che comportano la modifica o revisione di elementi funzionali già esistenti di un

modulo applicativo, affinché questo risulti aderente alla nuova normativa. Gli adeguamenti normativi di

livello regionale, vale a dire derivanti da leggi regionali, da disposizioni emanate con atti ufficiali

dell’Amministrazione Regionale o da Delibere della Giunta Regionale, dovranno essere

espressamente approvati dall’Assessorato dell’Igiene e Sanità e dell’Assistenza Sociale oppure dalla

DEC. È gradita la proattività da parte dell’aggiudicatario che, presidiando in autonomia le novazioni

normative e avvalendosi della propria conoscenza delle funzionalità implementate dal sistema, potrà

intercettare rapidamente le novità ricadenti nell’ambito del servizio, aventi possibile necessità di

recepimento sul sistema, e segnalare all’Amministrazione Aggiudicatrice la necessità o l’opportunità di

implementazione, fermo restando che l’attivazione della specifica manutenzione potrà avvenire solo a

fronte di esplicita disposizione dell’Amministrazione stessa.

Per le evoluzioni normative ordinarie, l’Aggiudicatario, ferma restando la previa disponibilità delle

informazioni utili alla presa in carico della singola richiesta e dei referenti regionali con cui effettuare gli

approfondimenti necessari, dovrà effettuare l’analisi della richiesta e dei relativi requisiti e predisporre

e consegnare all’Amministrazione Aggiudicatrice e alla DEC un documento di progettazione

contenente:

● l’analisi della richiesta;

● l’individuazione dei requisiti;

● i dettagli tecnici della proposta di evoluzione;

● la proposta di cronoprogramma per l’esecuzione.

L’esecuzione delle evoluzioni normative dovrà seguire le disposizioni metodologiche di cui al cap. 2.4.

La Direzione dell’Esecuzione comunicherà l’approvazione della progettualità ovvero richiederà

eventuali chiarimenti o revisioni. A partire dalla comunicazione di approvazione prenderà avvio il




cronoprogramma proposto ed il conteggio dei relativi livelli di servizio. L’aggiudicatario dovrà utilizzare

metodologie adeguate al fine di fornire una stima della complessità, del tempo necessario e dei costi

per l’implementazione, in modo da rappresentare alla DEC e all’Amministrazione un quadro tecnico,

cronologico ed economico credibile ed affidabile, che l’aggiudicatario è tenuto a rispettare.

Tutti gli interventi di manutenzione dovranno essere progettati e realizzati secondo le linee guida per

l’usabilità.

L’aggiudicatario dovrà garantire al minimo, per cambio normativa\legge:

- Registrazione dell’esigenza sul sistema di tracciamento sul sistema di TT (la richiesta

potrebbe essere registrata anche dalla DEC o dall’Amministrazione Aggiudicatrice).

- Documento di analisi.

- Applicazione delle linee guida usabilità.

- Valutazione economica.

- Aggiornamento della documentazione tecnica di analisi e progettazione e dei relativi elaborati

UML, BPMN, etc

- Pianificazione attività (aggiornamento del piano complessivo delle evoluzioni)

- Eventuale aggiornamento del piano di lavoro

- Produzione piano dei Test, unit testing, integration testing, system testing, regression testing

- Tracciamento dei test effettuati

- Test in ambiente di test SISaR, regression testing

- Rilascio della patch in produzione previa pianificazione concordata con la DEC se questa

attività produce disservizi

- Verifiche di funzionamento in ambiente di produzione

- Registrazione dei documenti attestanti l’attività sul portale documentazione

Per quanto riguarda la manutenzione adattativa ed adeguativa, tutti gli interventi dovranno in ogni

caso prevedere:

- Presa in carico delle esigenze di manutenzione adattativa o adeguativa con registrazione sul

sistema di TT

- Analisi della esigenza

- Avvio del processo come da sviluppo software (rif. Cap. 2.4)

- Tracciamento di tutti i dati relativi all’intervento sul sistema Jira

- All’interno del sistema di ALM Jira, dovrà essere espressamente indicato il tempo entro cui

sarà reso disponibile il piano delle attività necessarie.




Entro le scadenze indicate al cap. 12, l’Aggiudicatario dovrà consegnare e aggiornare un piano della

manutenzione adeguativa e adattativa con paragrafo distinto dedicato alla manutenzione ordinaria per

adeguamenti normativi, da sottoporre all’approvazione della DEC.

In fase di pianificazione dei rilasci dovrà sempre essere effettuata un’analisi dei rischi, finalizzata a

prevenire criticità e malfunzionamenti derivanti dalla messa in produzione degli aggiornamenti del

software. Particolare attenzione dovrà essere rivolta ad evitare l’introduzione di nuovi errori derivanti

dall’intervento effettuato. Quindi dovranno essere somministrati, come previsto nel processo di

sviluppo software, i test di integrazione e di no-regression. Il concorrente è tenuto a dichiarare

esplicitamente come intende trattare tale tematica.

L’aggiudicatario, nell’ambito della manutenzione adeguativa e adattativa, dovrà dunque, al minimo:

• Registrare necessità per manutenzione adeguativa o adattativa sul sistema di tracciamento

• Predisporre i piani di manutenzione

• Analizzare l’impatto della introduzione di nuove versioni di software di base o HW

• Applicare le linee guida usabilità

• Produrre il piano delle attività di modifica

• Produrre documentazione di analisi, UML, Piano di test

• Sviluppare le modifiche

• Effettuare unit testing, integration testing, system testing, regression testing

• Tracciare i test effettuati

• Effettuare code inspection, tracciare risultati code inspection

• Test in ambiente di test SISaR, regression testing

• Rilascio della patch\versione in produzione previa pianificazione concordata con la DEC se

questa attività produce disservizi

• Effettuare verifiche di funzionamento in ambiente di produzione

• Registrare i documenti attestanti l’attività sul portale documentazione

È richiesto che l’aggiudicatario preveda almeno due audit annuali sul servizio, uno dei quali dovrà

essere effettuato dall’auditor dell’Ente certificatore della società.






capitolo 13).




Sulla base degli interventi registrati nell’anno 2017 e nel 2018, si può stimare un numero medio di

interventi annuali relativi alla manutenzione per adeguamenti normativi non superiore a 70. In

particolare, nel 2018, gli interventi sono stati 31. Naturalmente, tale stima ha valenza puramente

indicativa, in quanto il verificarsi di modifiche normative in corso d’opera, al momento non prevedibili,

potrebbe determinare scostamenti significativi dalla suddetta media.


erogato a canone.

3.1.3 Manutenzione correttiva

Il servizio di manutenzione correttiva è volto ad eliminare i difetti, i malfunzionamenti e le

inadeguatezze del prodotto/programma rispetto ai requisiti funzionali, ove espressamente indicati, o al

comportamento atteso dal contesto operativo specifico.

L’attività consiste nella verifica del funzionamento del sistema e nella risoluzione delle anomalie

segnalate attraverso i servizi di assistenza e supporto all’utente. L’attività si conclude con il rilascio di

una patch correttiva urgente di rapida pubblicazione, che il personale tecnico dell’aggiudicatario,

attraverso escalation ed ingaggio dei rispettivi team di erogazione dei servizi di sviluppo software e di

gestione degli ambienti di produzione SISaR, applicherà previa fase di testing nell’ambiente di test

SISaR. Nei casi in cui l’operatività dell’Utente sia degradata dal malfunzionamento del software,

l’aggiudicatario potrà adottare temporaneamente soluzioni di work-around, fino a quando la patch che

risolve definitivamente il problema non sarà stata installata in produzione.

L’intervento correttivo assume le caratteristiche di urgenza qualora il difetto o l’inadeguatezza da

correggere siano di natura bloccante per l’operatività degli utenti interessati.

Riassumendo, oggetto del servizio è attuare l’intervento più idoneo a ripristinare nel più breve tempo

possibile, e nel rispetto dei livelli di servizio definiti, il regolare utilizzo del prodotto/programma oggetto

del malfunzionamento, anche mediante l’adozione temporanea di work-around.

Qualora, per la risoluzione della criticità, si rendessero necessarie operazioni di modifica del software

e/o delle architetture, le soluzioni dovranno essere sottoposte a test, mediante escalation verso i team

dell’aggiudicatario preposti alla erogazione dei servizi di gestione degli ambienti di test/produzione

SISaR e potranno essere installate in produzione previo esito positivo del collaudo in ambiente di test

SISaR. Le soluzioni non dovranno generare impatti negativi o malfunzionamenti su altre aree, sistemi,

moduli o funzionalità non coinvolte dal problema originario (è richiesto che venga eseguito sempre il

no regression test). L’aggiudicatario dovrà specificare i rischi associati a ogni intervento e le misure di

contenimento degli stessi che saranno adottate. Si dovrà dare evidenza, con documenti specifici, dei




test effettuati. L’installazione delle patch dovrà essere svolta nelle fasce orarie che garantiscano il

minor impatto possibile agli utenti, compatibilmente con la gravità dell’anomalia da risolvere.

La richiesta di intervento può essere inoltrata dal personale dell’Assessorato e di SardegnaIT e dagli

utenti delle Aziende Sanitarie, tramite il sistema di trouble ticketing (si veda il cap. 10) o tramite invio di

una mail ad una casella di posta definita e opportunamente comunicata. La procedura di risoluzione

deve essere documentata per iscritto dall’aggiudicatario e deve comunque avvenire nel rispetto degli

SLA di cui al cap. 13.

Tutto il ciclo di vita dell’anomalia, dalla segnalazione alla risoluzione, dovrà essere tracciato, registrato

e reso monitorabile attraverso lo strumento di Trouble Ticketing (si veda il cap. 10), che, in particolare,

dovrà consentire la tracciabilità sia dei tempi complessivi che vanno dalla segnalazione al rilascio in

produzione dell’intervento correttivo, sia anche delle sospensioni dei termini in attesa di riscontro alle

richieste di chiarimenti/integrazioni effettuate verso l’utente. L’aggiudicatario è tenuto a garantire che,

all’interno del sistema di Trouble Ticketing, contestualmente alla presa in carico, sia specificata la data

entro cui sarà effettuato il rilascio dell’intervento correttivo. L’aggiudicatario dovrà utilizzare

metodologie adeguate al fine di fornire una stima della complessità, del tempo necessario e dei costi

per l’implementazione, in modo da rappresentare alla DEC e all’Amministrazione un quadro tecnico,

cronologico ed economico credibile ed affidabile, che l’aggiudicatario dovrà rispettare.

Dovrà essere chiaramente condivisa la catalogazione di tutti i sistemi, con i relativi recapiti tecnici da

contattare e gli indirizzi di e-mail del servizio di manutenzione, e dovrà essere pubblicato a beneficio di

tutti gli utenti un manuale che illustri chiaramente le procedure di segnalazione. Come caso

particolare, dovrà essere chiaramente specificato come segnalare gli errori per le componenti di

integrazione fra i componenti del SISaR e fra il SISaR e i sistemi esterni.

L’aggiudicatario nell’ambito della manutenzione correttiva dovrà al minimo:

• Registrare sul sistema di supporto le segnalazioni di errore inoltrate via mail o per telefono

• Prendere in carico della segnalazione di errore

• Effettuare l’analisi, individuazione e correzione errore; applicare eventualmente un work

around con intervento in produzione al fine di minimizzare il disservizio agli utenti

• Gestire i processi secondo le disposizioni di cui al Cap. 2.4

• Effettuare Unit testing, integration testing, system testing, regression testing


• Effettuare Test in ambiente di test SISaR

• Rilascio della patch in produzione previa pianificazione concordata con la DEC se questa







È richiesto che l’aggiudicatario preveda almeno due audit annuali sul servizio, uno dei quali dovrà

essere effettuato dall’auditor dell’Ente certificatore della società.






capitolo 13).

Al fine di dimensionare l’impatto degli interventi di detta tipologia, si specifica che dal sistema di TT

risulta che il numero di ticket aperti e gestiti nel 2018 per segnalazioni di manutenzione correttiva è

stato pari a circa 175 per tutti i componenti del SISaR.


erogato a canone.

3.1.4 Manutenzione perfettiva

Il servizio di manutenzione perfettiva ha lo scopo di assicurare il costante miglioramento della qualità

del software applicativo SISaR, relativamente alla necessità o opportunità di modifiche, nuove

funzionalità e nuove release software, emergenti dalle segnalazioni degli utenti, della direzione di

esecuzione del contratto e dell’Amministrazione Aggiudicatrice o provenienti da iniziative proattive

dell’aggiudicatario stesso. Questo servizio include il miglioramento e l’estensione delle funzionalità già

esistenti, anche con iniziative non richieste direttamente dall’Amministrazione Aggiudicatrice, ma

comunque implementate dall’Aggiudicatario in quanto previste dai propri piani di rilascio, che

dovranno essere comunicati all’Amministrazione Aggiudicatrice con cadenza almeno trimestrale. Il

perfezionamento del software dovrà inoltre riguardare, nell’ambito del presente servizio, il

miglioramento della robustezza e della sicurezza delle applicazioni. Il servizio in oggetto include altresì

gli interventi di aggiornamento del software applicativo tramite refactoring, ottimizzazione e

razionalizzazione. La pianificazione degli interventi dovrà scaturire da una valutazione delle priorità,

determinate sulla base di criteri di urgenza e valore, condivisi con la DEC e con l’Amministrazione.

Secondo le scadenze indicate nel cap. 12, l’Aggiudicatario dovrà consegnare e aggiornare un piano

della manutenzione perfettiva, da sottoporre all’approvazione della DEC.

L’aggiudicatario, nell’ambito della manutenzione perfettiva, dovrà dunque al minimo:

• Registrare la richiesta\necessità per manutenzione perfettiva sul sistema di tracciamento TT




• Comunicare alla DEC l’esito della valutazione della richiesta nell’ambito della manutenzione

perfettiva

• Predisporre i piani di manutenzione

• Analizzare l’impatto dell’introduzione di nuove versioni di software di base o di modifiche

hardware

• Applicare le linee guida usabilità

• Produrre il piano delle attività di modifica

• Produrre documentazione di analisi, UML, Piano di test

• Sviluppare le modifiche

• Effettuare unit testing, integration testing, system testing, regression testing



• Test in ambiente di test SISaR

• Comunicare alla DEC la disponibilità di una nuova versione/release del software

• Rilasciare la patch\versione in produzione previa pianificazione concordata con la DEC se

questa attività produce disservizi

• Rilasciare l’aggiornamento della documentazione (manualistica utente, diagrammi UML,

documentazione tecnica, etc.) associata alla soluzione applicativa testata


• Registrare i documenti attestanti l’attività sul portale della documentazione di progetto







Per far fronte all’esigenza dell’utenza di disporre di uno strumento semplice e di facile utilizzo per la

produzione in autonomia di reportistica, nell’ambito di questo servizio, il concorrente dovrà proporre e

rilasciare, entro 2 mesi dall’avvio della fase 2, un nuovo strumento di reportistica o una versione

aggiornata ed evoluta di quello attualmente disponibile (JBF), che permetta all’utente finale di produrre

autonomamente i report e le statistiche di cui ha necessità in maniera user friendly. Per evitare che le

elaborazioni relative alla produzione della reportistica rallentino il sistema, lo strumento dovrà attingere

i dati dal sistema di mirror all’uopo reso disponibile sull’infrastruttura hardware H-Cloud della Regione.

Per rendere fruibile e trasparente l’utilizzo e per consentire una chiara rappresentazione delle diverse

entità e delle relazioni intercorrenti, i dati devono essere descritti in un livello intermedio di metadati




(Universi). I metadati devono essere a loro volta archiviati, insieme alle regole per la reportistica, nel

sistema di mirror. Lo strumento dovrà essere preferibilmente open source e le licenze d’uso dovranno

essere incluse nell’offerta e dovranno essere illimitate nel tempo e nel numero. È comunque

caratteristica imprescindibile l’immediatezza, l’intuitività e la facilità d’uso mediante apposita interfaccia

user friendly, in modo da consentire l’utilizzo autonomo dello strumento anche da parte di utenti non

dotati di competenze ICT specifiche.

È ricompreso nel servizio l’aggiornamento della manualistica utente, di tutta la documentazione

funzionale e tecnica, dei diagrammi UML e di tutto quanto reso disponibile ai concorrenti durante le

fasi di gara. Tale documentazione dovrà essere sempre aggiornata ed allineata con lo stato dell’arte

del software di cui è composto il SISaR.

Il concorrente dovrà rappresentare in offerta una prima proposta indicativa di programma di

manutenzioni perfettive da erogarsi nel periodo di durata del contratto per ciascun modulo di cui è

composto il SISaR.

Nell’ambito della manutenzione perfettiva dovranno essere in particolare proposti interventi di

ottimizzazione e miglioramento dell’integrazione tra i sistemi CUP e CCA. Dato atto delle segnalazioni

pervenute negli ultimi anni al servizio di trouble ticketing SISaR in relazione a tale ambito, si ritiene

necessario prevedere un innalzamento del livello di efficienza dei processi di passaggio delle

informazioni dal sistema CUP alla CCA e viceversa. Dovrà essere posta particolare attenzione alla

migrazione dei pazienti prenotati, aspetto importante sia dal punto di vista informativo, in relazione per

esempio alla generazione a consuntivo dei flussi di rendicontazione dell’attività di specialistica

ambulatoriale, sia dal punto di vista operativo, avendo il processo impatti diretti sulle attività di

accettazione e gestione del paziente in ambulatorio. Si reputa necessario migliorare il grado di

affidabilità dell’interfacciamento e valutare la realizzazione di meccanismi immediati per l’allineamento

CUP e CCA con sistemi user-friendly di monitoraggio, in particolare relativi ai messaggi di cambio di

stato da CCA a CUP, necessari per la rendicontazione dell’attività dell’ambulatorio e dei

pazienti/appuntamenti dal CUP alla CCA indispensabili per garantire l’attività dell’ambulatorio. Si

richiede, pertanto, di proporre in merito adeguate soluzioni tecnologiche di manutenzione perfettiva.

Tra le soluzioni si richiede di valutare anche l’eventuale accentramento del modulo CCA per la

gestione delle prestazioni per esterni, garantendo al contempo l’allineamento con le informazioni

registrate sulle componenti dipartimentali (es. registrazione anamnesi sui sistemi EMR). Si rammenta

che tutte le soluzioni proposte non dovranno alterare gli attuali equilibri organizzativi e di governo (es.

privacy, perimetro visibilità dati, accessibilità distinta, etc.).









capitolo 13).

Al fine di dimensionare l’impatto degli interventi di detta tipologia, si comunica che il numero di

interventi di manutenzione perfettiva nel 2017 è stato pari a 297 e nel 2018 è stato pari a 96.

3.2. Servizio A1.2: Miglioramento delle performance e dell’usabilità

Il servizio di miglioramento delle performance include gli interventi di aggiornamento del software

applicativo rispetto ad esigenze di miglioramento di prestazioni e performance delle applicazioni, che

ne lascino tuttavia inalterate le funzionalità. Gli interventi potranno emergere sia da una analisi

dell’architettura dei componenti\sistemi, che evidenzi necessità di interventi, sia dall’analisi di

segnalazioni di rallentamenti o blocchi di componenti da parte di utenti, da risultati di code inspection,

dalla valutazione dell’efficienza degli indici delle tabelle del DB, che l’aggiudicatario provvederà ad

effettuare secondo piani stabiliti, da nuove metodologie o aggiornamenti del software di base. La

pianificazione degli interventi dovrà scaturire da una valutazione delle priorità, determinate sulla base

di criteri di urgenza e valore condivisi con la DEC e con l’Amministrazione.

Il servizio di miglioramento dell’usabilità del livello di presentazione all’utente del sistema ricevuto in

gestione, oltre ad arricchire i singoli moduli di funzionalità aggiuntive o aggiornate utili per agevolare e

semplificare l’operatività degli utenti, dovrà prevedere un efficace miglioramento dell’interfaccia utente,

mirato ad un effettivo upgrade dell’usabilità di tutti i moduli del sistema (user experience design, user

interface design) e, ove utile e possibile, il passaggio delle interfacce utente ad una configurazione

responsive ovvero HTML 5 (Progettazione orientata all’utente, usabilità e User Experience). Anche in

tale ambito, la pianificazione degli interventi dovrà scaturire da una valutazione delle priorità,

determinate sulla base di criteri di urgenza e valore condivisi con la DEC e con l’Amministrazione.

Il software web-based dovrà essere compatibile con tutti i principali browser. Dovranno essere

applicate nello svolgimento di tale attività le “Linee guida di design per i servizi web della PA”. Il

concorrente dovrà specificare il profilo e l’esperienza del team di progetto del servizio di evoluzione

della UX.










L’aggiudicatario dovrà effettuare, in fase di presa in carico e poi per tutto il corso dell’esecuzione del

contratto, analisi e valutazioni del livello di performance e usabilità del sistema ricevuto in gestione, al

fine di individuare le aree su cui intervenire, secondo un ordine di priorità valutato in base al grado di

criticità. A tale proposito, si sottolinea fin d’ora l’esigenza che per il modulo EMR, attualmente in uso

presso il reparto di Medicina Interna del P.O. Santissima Trinità di Cagliari, siano implementate e

rilasciate interfacce di presentazione secondo gli standard della user experience design, in particolare

di quelle per la somministrazione della terapia medicinale a letto del paziente, specializzate per l’uso

di dispositivi portabili quali tablet o palmari. Simili criticità sono altresì già note per i sistemi dell’area

assistenza territoriale/prevenzione come SIAN, Spresal, e per gli altri sistemi dell’area territoriale.

All’interno del sistema di ALM Jira / Sistema di TT, dovrà essere espressamente indicato il tempo

entro cui sarà reso disponibile il piano delle attività necessarie.

L’importo contrattuale per tutto l’insieme dei servizi sopra descritti verrà riconosciuto con valore a

corpo unitario ed erogato sotto forma di canone mensile.

Entro le scadenze previste al cap. 12, l’aggiudicatario dovrà presentare e aggiornare un piano per il

miglioramento delle performance e della user experience, soggetto all’approvazione

dell’Amministrazione, in cui rappresenterà le azioni e gli interventi, cronoprogrammi e milestones, che

intende attuare per conseguire gli obiettivi di cui sopra.

Nell’offerta tecnica, il concorrente dovrà descrivere le metodologie che si intendono utilizzare e le

modalità di erogazione del servizio. In particolare, il concorrente dovrà descrivere l’approccio

metodologico che adotterà nel predisporre ed attuare il piano di progetto definitivo dedicato sia al

miglioramento delle performance che dell’usabilità. Il concorrente dovrà descrivere inoltre

l’organizzazione del servizio, dettagliando il dimensionamento e la composizione dei profili del team

coinvolto e dimostrandone la coerenza e congruità rispetto alle modalità di erogazione proposte per il

servizio. Il concorrente dovrà, in particolare, specificare il profilo e l’esperienza del/i user experience

designer facenti parte del team di progetto del servizio. Dovrà infine giustificare come riuscirà a

garantire gli SLA richiesti e dichiarare eventuali SLA migliorativi rispetto a quanto riportato nel

proseguo del documento (cfr. capitolo 13).

L’aggiudicatario, nell’ambito del servizio di miglioramento performance e user experience, dovrà al

minimo:

• Effettuare l’analisi delle interfacce del sistema SISaR facendo riferimento alle linee guida

usabilità




• Pianificare la re-ingegnerizzazione delle interfacce ove se ne individui la necessità applicando

le linee guida usabilità

• Effettuare Unit testing, integration testing, system testing, regression testing


• Effettuare Test in ambiente di test SISaR


• Rilasciare la patch in produzione previa pianificazione concordata con la DEC se questa




I deliverable previsti per ciascun intervento sono:

- Documento d’analisi

- Piano di sviluppo con descrizione delle iterazioni, cronoprogramma

- Software sviluppato

- Piano dei test\No regression test\Test Integrazione\Risultato dei test

- Rilascio

- Documentazione tecnica a corredo del software: design del software (UML), user experience

design, manualistica utente, piano dei test, report dei test effettuati

In ogni caso, gli interventi dovranno essere registrati sul sistema Jira in modo che possano essere

identificati e distinti da tutti gli altri interventi di manutenzione.


erogato a canone.

3.3. Servizio A1.3: Manutenzione Evolutiva

Il servizio di manutenzione evolutiva ha lo scopo di assicurare l’innovazione funzionale del software

applicativo rispetto alle nuove esigenze provenienti dall’Assessorato, dalle Aziende e dalla Direzione

dell’Esecuzione / SardegnaIT che comportino interventi di modifica straordinaria del software

medesimo.

In generale, gli interventi di modifica ed evoluzione del software applicativo SISaR che ricadono in tale

classe di servizio hanno l’obiettivo di rispondere sia ad esigenze di evoluzione o innovazione

funzionale dell’Amministrazione Regionale, sia ad adeguamenti normativi aventi carattere

straordinario, ovvero che abbiano impatto non trascurabile nella logica applicativa e della base dati del

software pre-esistente, o che richiedano l’implementazione di nuove estensioni applicative o la

revisione estesa della configurazione dell’impianto applicativo. Pertanto, nel servizio sono incluse




altresì le evoluzioni normative straordinarie, correlate e conseguenti ad innovazioni strutturali

introdotte da atti deliberativi, legislativi, regolamentari o normativi in genere, da implementarsi nel

periodo di validità del servizio, che richiedano un impegno di carattere non circoscritto, ovvero di

impatto esteso e strutturale.

Entro le scadenze previste al cap. 12, l’aggiudicatario dovrà presentare e aggiornare un piano della

manutenzione evolutiva, contenente, oltre alle informazioni sulle modalità di attuazione (metodologie,

team dedicato, etc.), il quadro sinottico delle Change Request censite, con relativo stato,

cronoprogramma e risorse impegnate, nonché l’indicazione complessiva dello stato di consumo di

budget e giornate.

Il servizio comprende tutte le attività necessarie ad analizzare, progettare e realizzare nuove

componenti applicative, nuovi blocchi funzionali o personalizzazioni radicali delle soluzioni esistenti,

realizzate sulla base dei requisiti condivisi con l’Amministrazione aggiudicatrice.

Nel seguito, gli oggetti di tale servizio saranno definiti Change Request (CR).

L’Aggiudicatario dovrà erogare il servizio mediante metodologie agili, secondo i principi di cui al cap.

2.4, assicurando il raggiungimento degli obiettivi mediante cicli di sviluppo iterativi e incrementali delle

evoluzioni richieste (CR), sulla base di un allineamento e di una verifica costante con la committenza

e con gli utenti rispetto all’ordine di priorità delle funzionalità da rilasciare, ai risultati di ogni ciclo ed

alle procedure stesse di sviluppo. Ogni iterazione di sviluppo dovrà avere l’obiettivo di trasformare un

insieme di requisiti selezionati in funzionalità del prodotto consegnabili e potenzialmente rilasciabili,

concludendosi con la presentazione all’utenza di tali funzionalità al fine di ricevere un feedback sul

soddisfacimento delle attese e di ricevere indicazioni per l’incremento oggetto dell’iterazione

successiva.

Le versioni incrementali delle CR progressivamente implementate dovranno essere rese disponibili ad

ogni iterazione in ambiente di sviluppo oppure in ambiente di test; in ogni caso dovrà essere possibile

effettuare la sessione di verifica presso la sede lavorativa di un Key User.

Le metodologie di sviluppo adottate dovranno essere in grado di accogliere agevolmente cambiamenti

dei requisiti durante i cicli di sviluppo.

Gli unici soggetti titolati a formalizzare Change Request verso l’Aggiudicatario sono la Direzione

dell’Esecuzione del Contratto e il Responsabile Unico del Procedimento. L’Aggiudicatario non potrà

dunque attivare prestazioni contrattuali sulla base di richieste dirette da parte dell’utenza, a qualsiasi

livello organizzativo essa afferisca. L’utente, sia della Regione che dell’Azienda Sanitaria o afferente

ad altra struttura, è infatti tenuto a comunicare le proprie esigenze alle strutture responsabili in materia

ICT nell’ambito della propria organizzazione, che ne approfondiranno la consistenza, l’effettivo




interesse da parte dell’organizzazione, l’opportunità e la coerenza. In caso di valutazione positiva

dell’esigenza manifestata, sarà il responsabile ICT dell’organizzazione di appartenenza a comunicare

alla DEC l’esigenza. A seguito delle ulteriori verifiche di competenza della DEC sulla compatibilità,

coerenza e capienza rispetto al contratto, sarà quest’ultima ad “aprire” formalmente la Change

Request verso l’Aggiudicatario. Qualora l’Aggiudicatario ricevesse richieste direttamente dall’utenza o

in generale da soggetti diversi dal RUP e dalla DEC, è tenuto a fornire l’informazione sulla corretta

procedura da seguire come sopra descritto ed a reindirizzare gentilmente l’utente verso le strutture

responsabili dell’ICT nell’ambito della propria organizzazione di appartenenza, nonché a riportare

tempestivamente l’evento alla DEC con una sintetica descrizione dell’esigenza ed indicando il

soggetto richiedente.

Una volta aperta la Change Request, l’Aggiudicatario si attiverà verso i referenti tecnici della DEC per

l’area di interesse e verso quelli “di dominio” indicati dalla Regione per definire un primo documento di

analisi funzionale. Approvato questo documento da parte della DEC, l’aggiudicatario produrrà un

documento di progetto in cui sarà specificata una prima versione dell’elenco delle funzionalità con

priorità secondo l’importanza loro attribuita dall’utente, un piano di massima temporizzato con

indicazione dei cicli di sviluppo che si suppone necessari, delle date di avvio e della durata di ogni

ciclo, e una stima del consumo di GG/persona per profilo professionale e conseguentemente di

budget. L’aggiudicatario dovrà utilizzare metodologie adeguate al fine di fornire una stima della

complessità, del tempo necessario e dei costi per l’implementazione della Change Request, in modo

da rappresentare alla DEC e all’Amministrazione un quadro tecnico, cronologico ed economico certo

ed affidabile, che l’aggiudicatario sarà tenuto a rispettare.

A seguito dell’approvazione della progettualità di cui sopra da parte della DEC, a partire dalla data

concordata per l’avvio dell’esecuzione, scatterà il piano di sviluppo con i relativi livelli di servizio. La

DEC, il RUP, l’utenza e l’Aggiudicatario stesso a fronte dei risultati della verifica su quanto rilasciato

nella singola iterazione, potranno proporre in corso d’opera variazioni alla CR, che potranno essere

adottate solo previa condivisione del verbale di verifica in cui sarà specificata la\e modifiche e relativa

approvazione della DEC. Le tempistiche di presa in carico e consegna dei deliverable sono regolati

dai livelli di servizio definiti nel seguito. In ogni caso il processo di sviluppo dovrà essere in grado di

accogliere agevolmente cambiamenti in corso d’opera.

I deliverable previsti per ciascuna CR sono i seguenti:

- Documento d’analisi

- Piano di sviluppo con descrizione delle iterazioni, cronoprogramma e quantificazione

economica

- Software sviluppato




- Piano dei test\No regression test\Test di integrazione\Risultato dei test

- Rilascio

- Documentazione tecnica a corredo del software: design del software (UML), user experience

design, manualistica utente, piano dei test, report dei test effettuati







Per quanto attiene alle attività di test e di messa in produzione sugli ambienti infrastrutturali

dell’Amministrazione Aggiudicatrice delle nuove componenti applicative che vengono rilasciate

nell’ambito del presente servizio, si rimanda ai servizi descritti nel cap. 3.5.

Sono altresì ricomprese nel presente servizio le attività propedeutiche all’analisi e progettazione

tecnica dei requisiti da soddisfare mediante gli interventi evolutivi e di modifica della configurazione

dell’impianto applicativo SISaR, quali sono le attività di supporto al cambiamento / change

management, revisione dei processi (business process reengineering) e delle regole di sistema utili a

definire le linee guida per l’attuazione dei nuovi assetti organizzativi nell’ambito del sistema

informativo SISaR. Tale tipologia di attività vede l’impiego di Esperti Applicativi di dominio / Consulenti

di Organizzazione, che, ai fini della analisi/progettazione tecnica delle funzionalità oggetto di

evoluzione, intervengono a supporto dell’Assessorato nella definizione di regole di sistema, ivi inclusi

nuovi nomenclatori e sistemi di codifica, proposizione di modelli e processi operativi da attuare

nell’ambito del software applicativo SISaR, revisione dei debiti informativi, etc..

In considerazione della prospettiva di subentro di un nuovo fornitore alla conclusione del contratto,

tutti i rilasci di impatto significativo relativi alla manutenzione evolutiva dovranno essere eseguiti non

oltre una data limite che l’Amministrazione Aggiudicatrice provvederà a comunicare entro nove mesi

dalla data di conclusione prevista del contratto.

Per la comunicazione, il monitoraggio ed il controllo delle attività caratterizzanti il presente servizio

dovrà essere adottato lo strumento ALM (Application Lifecycle Management) Atlassian Jira /

strumento di TT (si veda cap. 10).

A partire dalla comunicazione di approvazione della valutazione economica scatterà il

cronoprogramma proposto ed il conteggio dei relativi livelli di servizio.





di erogazione del servizio. Il concorrente dovrà descrivere l’organizzazione del servizio, dettagliando il

dimensionamento e la composizione dei profili del team coinvolto e dimostrandone la coerenza e

congruità rispetto alle modalità di erogazione proposte per il servizio. Dovrà inoltre giustificare come

riuscirà a garantire gli SLA richiesti e dichiarare eventuali SLA migliorativi (cfr. capitolo 13).

Le attività da svolgersi nell’ambito del presente servizio dovranno essere caratterizzate da un alto

grado di parallelizzazione, con particolare riferimento alla capacità dell’Aggiudicatario di gestire e

portare avanti contemporaneamente un numero significativo di Change Request diverse. Il

concorrente dovrà, pertanto, a tal fine, descrivere nell’offerta tecnica come intende organizzare il

servizio di manutenzione evolutiva con riferimento alla capacità di parallelizzazione, specificando in

particolare il numero massimo di giornate persona che potranno essere erogate in una stessa giornata

lavorativa per ciascun profilo professionale richiesto per questo servizio, per il periodo di durata del

contratto.

I profili che è previsto al minimo debbano essere utilizzati per questo servizio sono:

FP1 Analista programmatore

FP2 Specialista di prodotto

FP3 Project Manager

FP4 Architetto IT\Progettista Software

FP4 User Experience designer

FP5 Sistemista \ DBA Senior

FP6 Consulente Organizzativo di Prodotto/Dominio

Considerata la natura flessibile e il contenuto non stimabile a priori delle attività ricadenti nel presente

servizio e degli obiettivi che questo intende perseguire, esso è da intendersi integralmente “a

consumo”, ovvero remunerato a misura sulla base dell’effort approvato dall’Amministrazione

Aggiudicatrice\Direzione Esecuzione del Contratto su proposta dell’aggiudicatario, in base alle tariffe

per figura professionale offerte per le giornate erogate, fino al raggiungimento del budget massimo

(fisso) disponibile per il servizio medesimo.

La rendicontazione dovrà avvenire con SAL specifici in cui potranno essere portate a valore le CR

autorizzate da RUP\DEC, implementate e verificate dalla DEC con apposita sessione di lavoro

congiunta; la fatturazione potrà essere effettuata una volta che la DEC avrà emesso il certificato di

verifica di conformità controfirmato dal Program Manager dell’aggiudicatario e che il RUP avrà

approvato lo stesso ed autorizzato esplicitamente la fatturazione.

L’aggiudicatario dovrà garantire al minimo, su evento di richiesta della DEC (CR):




• Registrazione dell’esigenza sul sistema di tracciamento (la richiesta potrebbe essere

registrata anche dall’Amministrazione).

• Documento di analisi.

• Applicazione le linee guida usabilità.

• Valutazione economica.

• Produzione e/o aggiornamento della documentazione tecnica di analisi e progettazione e degli

elaborati UML, BPMN, etc

• Pianificazione attività (aggiornamento del piano complessivo delle evoluzioni)

• Eventuale aggiornamento del piano di lavoro per singola Change Request

• Produzione piano dei Test, unit testing, integration testing, system testing, regression testing

• Tracciamento dei test effettuati

• Test in ambiente di test SISaR

• Rilascio della patch in produzione previa pianificazione concordata con la DEC se questa


• Verifiche di funzionamento in ambiente di produzione

• Registrazione dei documenti attestanti l’attività sul portale documentazione

Lo strumento adottato per la comunicazione, il monitoraggio ed il controllo delle attività caratterizzanti

il presente servizio è l’ALM (Application Lifecycle Management) Atlassian Jira.

3.4. Servizio A1.4: Servizi Specialistico-Applicativi

La presente classe di servizio consta nella erogazione di attività utili ad analizzare ed attuare i

cambiamenti all’impianto del software applicativo SISaR, in termini di configurazione e

parametrizzazione, sulla base delle esigenze rilevate nel funzionamento in esercizio del medesimo da

parte dell’utenza afferente alle Aziende Sanitarie e Ospedaliere regionali, dell’Assessorato dell’Igiene

e Sanità della RAS, della Direzione dell’Esecuzione / SardegnaIT e del personale tecnico

dell’Aggiudicatario medesimo. Il servizio è tipicamente erogabile da remoto presso le sedi

dell’Aggiudicatario.

In particolare, ricadono in tale linea i seguenti servizi:

• Demand Management, consistente nell’analisi ed individuazione delle possibili evoluzioni e

cambiamenti - a carattere non estesamente progettuale - da attuare sull’impianto applicativo

SISaR, in termini di rispettiva parametrizzazione / configurazione.

• Application Support Advanced, consistente nella erogazione di attività di Supporto

Specialistico – Applicativo Remoto per l’attuazione in modalità remota di interventi ordinari di

configurazione e parametrizzazione del software applicativo SISaR, che non abbiano

carattere estesamente progettuale, ovvero non siano di elevata complessità.




Le suddette attività rivestono carattere continuativo e costante per tutta la durata del servizio.

In riferimento alla sub-classe di servizio di Demand Management, questa è garantita mediante

l’impiego di un team di Esperti Applicativi con competenze di dominio e tecnico-applicative sulle aree

funzionali SISaR, che, insieme al Service Manager, affiancano la Direzione Generale della Sanità

della Regione Autonoma della Sardegna e la Direzione dell’Esecuzione / SardegnaIT nel:

• analizzare i requisiti utente e le esigenze specifiche che di volta in volta emergono dai diversi

attori aziendali e regionali del sistema SISaR e definire le soluzioni tecnico-applicative che

meglio rispondono alle medesime;

• individuare proattivamente nuove soluzioni tecniche e cambiamenti al software applicativo,

che anticipino future esigenze degli utenti del sistema informativo SISaR;

• definire linee guida e procedure operative di utilizzo ottimale dei sistemi applicativi SISaR da

parte delle Aziende Sanitarie, p.e. per adempiere ai debiti informativi regionali e ministeriali.

In riferimento alla sub-classe di servizio di Application Support Advanced ovvero supporto specialistico

- applicativo remoto, questa intende soddisfare le esigenze di supporto per attività di

parametrizzazione/configurazione che possono provenire dagli utenti finali, queste ultime segnalate

per mezzo dei Key User aziendali (individuati per ciascuna area applicativa), dei Responsabili dei

Sistemi Informativi aziendali, dei Referenti della Direzione Generale della Sanità della Regione

Autonoma della Sardegna, o anche per mezzo del Service Desk (Help Desk) dell’Aggiudicatario,

qualora quest’ultimo nella gestione di una richiesta di assistenza rilevi la necessità di porre in essere

azioni che ricadano per loro natura nella presente classe di servizio.

L’erogazione del servizio in esame avviene previo contatto telefonico, oppure tramite invio di e-mail a

specifico indirizzo di posta elettronica, con indicazione, nella richiesta di supporto, dell’area applicativa

e modulo software interessato, descrizione di dettaglio dell’attività richiesta corredata da

dati/informazioni utili alla esecuzione della medesima, riferimenti del richiedente e di altri soggetti,

funzionali ad una eventuale analisi / approfondimento; la presa in carico della richiesta da parte dello

Specialista di Prodotto dell’applicazione interessata è determinata da una notifica via mail o mediante

contatto telefonico (re-call) del richiedente il supporto, da cui decorre il tempo di effettiva erogazione

del supporto richiesto.

Nello specifico, le attività di parametrizzazione/configurazione del software applicativo che ricadono in

tale sub-classe di servizio sono tutte quelle, erogabili da remoto, che richiedono un intervento di bassa

complessità. La definizione della soglia di bassa complessità è lasciata all’offerta del concorrente, da

definirsi in termini di effort massimo di N ore/persona di specialista di prodotto da svolgersi e

completarsi in un arco temporale T, a partire da un minimo di almeno 4 ore/persona nell’arco di una

giornata lavorativa. Tali soglie N e T sono oggetto di offerta da parte del concorrente e forniranno




anche un’indicazione sulla capacità di parallelizzazione delle attività (n. ore/persona per giorno), che

costituisce un requisito fondamentale per il presente servizio.

La replica dello stesso intervento su aziende\ASSL diverse dovrà essere considerata come una nuova

richiesta di intervento.

A titolo meramente esemplificativo e non esaustivo, si riporta di seguito un elenco di attività ricadenti

nella sub-classe di servizio presa in esame:

• correzione a livello di database di dati imputati erroneamente dall’utente;

• inserimento ed abilitazione di un nuovo utente;

• inserimento/modifica di un profilo utente;

• associazione/abilitazione di una nuova funzionalità ad un profilo utente;

• modifica/aggiornamento anagrafiche, anche mediante script di caricamento massivo su DB

(es. caricamento codici SIOPE, etc.) già esistenti;

• modifica/aggiornamento nomenclatori anagrafici; a titolo esemplificativo ma non esaustivo si

citano per il sistema HR i nomenclatori di voci di trattenuta, voci di competenza,

assoggettamento voci, voci in deduzione, tipi di assoggettamento, qualifiche, profili

professionali, posizioni funzionali, discipline, eventi di carriera, causali di assenza, causali di

presenza, profili indennità, profili ferie, profili orari, calendari, stati di attività, reperibilità, e per

il sistema AMC i nomenclatori delle causali di prima nota, causali di magazzino, causali di

cassa economale, tipi di documento, etc.;

• modifica controlli applicativi o regole di gestione parametrizzabili;

• modifica della configurazione dei servizi di integrazione esposti lato sistemi SISaR e relative

transcodifiche;

• modifica della configurazione dei workflow esistenti;

• modifica report personalizzati preesistenti (ovvero sviluppati ad hoc specificatamente per la

Regione Autonoma della Sardegna);

• modifica / aggiornamento riclassificatori preesistenti; a titolo esemplificativo ma non esaustivo

si citano i riclassificatori di inquadramento del sistema HR e i riclassificatori di strutture

sanitarie utilizzati nell’ambito del sistema AMC.

Nei casi in cui le esigenze segnalate non fossero risolvibili attraverso una opportuna

parametrizzazione/configurazione della soluzione applicativa nell’ambito del presente servizio, ovvero

l’effort necessario allo scopo ecceda la soglia massima prevista per singolo intervento di

parametrizzazione, la specifica richiesta oggetto di segnalazione sarà chiusa per essere trasferita sul

servizio a consumo di manutenzione evolutiva. L’aggiudicatario in tal caso dovrà produrre tutti gli




elementi giustificativi alla DEC e all’Amministrazione Aggiudicatrice le quali valuteranno la congruità

delle motivazioni rappresentate dall’aggiudicatario.

In riferimento agli interventi che ricadono nella sub-classe di servizio di Application Support Advanced,

ovvero hanno natura di supporto specialistico-applicativo remoto, l’Aggiudicatario garantirà che

all’interno del sistema di ALM Jira / sistema di TT, contestualmente alla conferma della rispettiva

presa in carico, sia espressamente indicato il tempo entro cui sarà effettuata l’attività di

parametrizzazione/configurazione della soluzione applicativa, l’oggetto della richiesta, data e ora della

richiesta, data e ora di chiusura della richiesta, specialista del fornitore che ha gestito la richiesta,

sistema e modulo oggetto della richiesta, utente che ha effettuato la richiesta. L’aggiudicatario dovrà

utilizzare metodologie adeguate al fine di fornire una stima della complessità, dei costi e del tempo

necessario per l’implementazione, in modo da rappresentare alla DEC e all’Amministrazione un

quadro tecnico, cronologico ed economico certo ed affidabile, che l’aggiudicatario sarà tenuto a

rispettare.

A titolo informativo, si rappresenta che il numero di interventi gestiti riguardanti il servizio di Application

Support Advanced nel 2017 è stato pari a circa 5250, mentre nel 2018 è stato di circa 6140.







riuscirà a garantire gli SLA richiesti e dichiarare eventuali SLA migliorativi (cfr. capitolo 13). Il

concorrente dovrà specificare esplicitamente le soglie di durata dell’intervento e di effort massimo

perché gli interventi rientrino nella categoria di Application Support Advanced. Al fine di valutare la

capacità di parallelizzazione, è richiesto infine di dichiarare il numero massimo di ore/uomo erogabili in

una stessa giornata. Tutti i valori di cui sopra costituiranno oggetto di valutazione dell’offerta tecnica.

3.5. Servizio A1.5: Gestione degli ambienti applicativi di test e di produzione

Il servizio di gestione dell’ambiente di test si pone l’obiettivo di mantenere aggiornato l’ambiente di

test SISaR dislocato presso il CSR rispetto alle nuove major release e release intermedie (patch/add)

del software applicativo SISaR. Nello specifico il servizio comprende le attività di installazione e

configurazione di base in ambiente di test CSR delle nuove release del software applicativo, nonché le

attività di verifica del corretto funzionamento del medesimo unitamente alle rispettive customizzazioni,

prima della messa in produzione.




Le attività di configurazione di base si sostanziano nella abilitazione/attivazione delle nuove

funzionalità affinché possano essere fruibili da interfaccia utente in ambiente di test, escludendo ad

ogni modo la rispettiva parametrizzazione/profilazione nell’ambito di qualsivoglia processo operativo.

Le attività di verifica, per quanto attiene le major release e le release intermedie che contengono

nuove funzionalità (esclusi quindi gli interventi correttivi), constano nella esecuzione almeno delle

seguenti tipologie di test:

● test di installazione, consistente nel verificare la effettiva possibilità di installazione

dell'applicativo nell'ambiente cui è destinato (target), secondo le istruzioni fornite dalla

rispettiva documentazione tecnica. Il package da installare deve essere consegnato anche

alla DEC / SardegnaIT che provvederà alla installazione dello stesso in un suo ambiente

dedicato;

● test di funzionalità, consistente nel verificare che le nuove funzionalità rilasciate nell’ambito

delle release software oggetto di installazione presentino un comportamento aderente alle

specifiche funzionali del prodotto; tale tipologia di test viene generalmente condotta mediante

l’individuazione e l’esecuzione di casi di test/casi d’uso, che permettono di verificare la

copertura funzionale del software applicativo, rispetto a quanto indicato nella relativa

documentazione tecnica; tali test devono obbligatoriamente prevedere anche i test di

integrazione nel caso in cui le modifiche, anche solo potenzialmente, interessino

l’interfacciamento con altri moduli/sistemi SISaR o sistemi esterni;

● test di carico (Stress and Volume/Load Test), consistente nella esecuzione contemporanea di

un numero rilevante di transazioni in un determinato periodo di tempo, al fine di verificare il

picco di lavoro che il sistema applicativo interessato è in grado di sostenere, senza degradare

le prestazioni nell’ambiente applicativo messo a disposizione; ove possibile e in maniera

concordata con la Direzione dell’Esecuzione del Contratto i test di carico potranno essere

effettuati anche in ambiente di produzione;

● test di non regressione, aventi l’obiettivo di verificare che le modifiche eseguite in una nuova

release software non introducano malfunzionamenti su altre funzionalità non modificate della

medesima release.

L’Aggiudicatario è tenuto:

● a tracciare il dettaglio dei test effettuati e dei relativi risultati e condividerlo come deliverable

nei Rapporto di erogazione servizi e SAL;

● a garantire la tracciabilità del servizio e il rispetto degli SLA attraverso registrazione sul

sistema Jira \ Sistema di TT;




● a mettere a disposizione della DEC le utenze per l’accesso all’ambiente di test per poter

verificare il funzionamento di tutto il sistema in test per tutto il periodo di vigenza del contratto.

L’Amministrazione Aggiudicatrice, tramite SardegnaIT, metterà a disposizione le opportune VPN

necessarie a raggiungere i sistemi SISaR presso i rispettivi siti di installazione. Tali VPN dovranno

essere richieste ed autorizzate secondo le modalità definite da SardegnaIT.

Il servizio di gestione dell’ambiente di produzione ha l’obiettivo di garantire l’installazione e la

configurazione di base in ambiente di produzione delle nuove release e patch del software applicativo

SISaR, nonché l’aggiornamento della rispettiva manualistica. Le attività di configurazione di base si

sostanziano nella abilitazione/attivazione delle nuove funzionalità, affinché possano essere fruibili da

interfaccia utente, escludendo la rispettiva parametrizzazione/profilazione nell’ambito di qualsivoglia

processo operativo. Non fanno parte del servizio le attività ordinarie di gestione operativa del software

applicativo in produzione, quali ad esempio la creazione di nuovi utenti, la creazione di nuovi profili

utente, l’associazione/abilitazione delle nuove funzionalità a profili utente, l’inserimento/modifica delle

anagrafiche, ecc., che rimangono in capo all’utenza abilitata.

È richiesto che, ove possibile (l’aggiudicatario sarà tenuto a giustificare dove ciò non è possibile), si

utilizzino meccanismi di aggiornamento dell’applicativo in modalità hot-deploy, in modo da ridurre il

disservizio, consentendo di continuare ad utilizzare l’applicativo, bloccando momentaneamente solo le

funzionalità impattate dalle modifiche e mostrando una maschera di cortesia che inviti l'utente a ri-

loggarsi a seguito della modifica stessa. In ogni caso l’installazione delle patch e delle nuove release

dovrà comunque essere effettuata in una fascia oraria tale da arrecare l’impatto minimo sulla

operatività degli utenti. Salvo diverse indicazioni opportunamente concordate con la Direzione

dell’Esecuzione, l’aggiornamento dei sistemi dovrà essere effettuato dopo le 19:00 e in modo tale da

creare il minimo impatto possibile sulla continuità del servizio.

Dovranno essere programmate con un largo anticipo le attività che producono disservizi durante il

normale svolgimento dell’attività operativa degli utenti e l’attività dovrà sempre essere

preventivamente comunicata alla DEC, all’Amministrazione e alle Aziende Sanitarie. In particolare:

- interventi determinanti disservizi di durata prevista inferiore ad un’ora dovranno essere

programmati e comunicati almeno con una settimana di anticipo;

- interventi determinanti disservizi di durata prevista superiore a un’ora e fino alle quattro ore su

qualunque sistema dovranno essere programmati e comunicati con almeno due settimane di

anticipo;

- interventi determinanti disservizi di durata prevista superiore alle 4 ore dovranno essere

programmati e comunicati con almeno 20 giorni di anticipo e sottoposti all’approvazione

preventiva della DEC.




Sarà possibile derogare a questi vincoli solo in casi eccezionali e previa esplicita autorizzazione della

Direzione dell’Esecuzione del Contratto. L’Aggiudicatario dovrà rendersi disponibile a modifiche delle

calendarizzazioni in conseguenza delle esigenze operative degli utenti.

Il servizio include dei test di funzionalità in produzione al fine di verificare che il comportamento dei

sistemi sia quello desiderato e non si siano inavvertitamente introdotti dei malfunzionamenti.

Nell’ambito del servizio deve essere inoltre assicurato un ambiente replica DB di tutti i sistemi

centralizzati e dipartimentali su infrastruttura centralizzata messa a disposizione dall’Amministrazione

Aggiudicatrice, che sarà a disposizione delle Aziende Sanitarie secondo le rispettive titolarità dei dati,

al fine di poter effettuare le elaborazioni desiderate senza peggiorare le performance complessive del

sistema in produzione. L’allineamento del DB replica dovrà essere almeno giornaliero e

l’aggiudicatario dovrà assicurarsi che l’allineamento abbia avuto esito positivo anche in termini di

completezza.

L’Amministrazione Aggiudicatrice metterà a disposizione le opportune VPN necessarie a raggiungere i

sistemi SISaR presso i rispettivi siti di installazione. Tali VPN dovranno essere richieste ed autorizzate

secondo le modalità definite da SardegnaIT ovvero dalle Aziende Sanitarie nel caso in cui le VPN

siano messe a disposizione dalle stesse.

L’Aggiudicatario è tenuto:

● a tracciare il dettaglio dei test effettuati ed i relativi risultati e condividerli come deliverable nei

Rapporto di erogazione servizi e SAL;

● a garantire la tracciabilità del servizio e il rispetto degli SLA attraverso registrazione sul

sistema Jira \ Sistema di TT.








3.6. Servizio A1.6: Gestione sistemistico-applicativa

Il servizio consiste in generale nella conduzione delle attività sistemistiche atte a garantire la continuità

operativa delle applicazioni SISaR sugli ambienti infrastrutturali su cui sono in esecuzione,

provvedendo al monitoraggio delle componenti software di base ed ambiente da queste direttamente




utilizzate, alla modifica della configurazione di tali componenti, ovvero a reindirizzare al soggetto terzo

manutentore della infrastruttura tecnologica (hardware e software di base/ambiente) le segnalazioni di

malfunzionamento dei rispettivi elementi hardware e software di base/ambiente.

Con maggiore dettaglio, l’aggiudicatario dovrà erogare il supporto sistemistico-applicativo sulle

applicazioni SISaR utile a verificare che i rispettivi ambienti di esecuzione, in termini di software di

ambiente da questi direttamente utilizzati (RDP, Application Server, software di bilanciamento,

RDBMS), garantiscano continuità di funzionamento ai sistemi applicativi medesimi e rispettino le

condizioni necessarie alla rispettiva esecuzione, e, laddove necessario, in corrispondenza di rilevate

situazioni di malfunzionamento ovvero degrado delle prestazioni, innescare un processo di escalation

verso il soggetto gestore / manutentore della infrastruttura tecnologica su cui sono in esecuzione le

applicazioni SISaR affinché questo effettui i rispettivi interventi risolutivi, nonché supportare

l’esecuzione delle modifiche alla configurazione degli elementi software infrastrutturali (RDP,

Application Server, Software di Bilanciamento, RDBMS, etc …) direttamente utilizzati dalle

applicazioni SISaR, e in generale collaborare proattivamente alla risoluzione delle problematiche

fornendo supporto per quanto di competenza.

Nello specifico, le attività ricadenti nell’ambito del presente servizio sono:

amministrazione e gestione degli ambienti software RDP Microsoft / Application Server di

esecuzione, in test e produzione, delle applicazioni SISaR; gli interventi sul sistema operativo

utilizzato dal SISaR sono di competenza dell’aggiudicatario della presente gara così come

l’installazione degli aggiornamenti necessari;

monitoraggio e tuning sistemistico delle applicazioni SISaR, ovvero degli ambienti software

RDP Microsoft / Application Server di esecuzione, in test e produzione, dei sistemi applicativi

SISaR;

gestione, di concerto con il soggetto gestore / manutentore della infrastruttura tecnologica su

cui sono in esecuzione le applicazioni SISaR, delle politiche di sicurezza del network di

accesso e collegamento interno di tale infrastruttura server, ovvero delle possibili successive

modifiche / change delle rispettive policy, che il soggetto gestore / manutentore

dell’infrastruttura dovrà applicare ed assicurare nel tempo, con segnalazione a quest’ultimo di

possibili anomalie in termini di vulnerabilità, non conformità alle policy definite e

malfunzionamenti che il soggetto gestore / manutentore dell’infrastruttura dovrà risolvere.

L’aggiudicatario della presente procedura sarà responsabile delle policy di sicurezza di tutto

ciò che riguarda il SISaR;

gestione, di concerto con il soggetto gestore / manutentore dell’infrastruttura , del

mantenimento allo stato dell’arte delle procedure di backup e disaster recovery dei sistemi




SISaR, che il soggetto gestore / manutentore dovrà attuare ed assicurare nel tempo, con

indicazione delle possibili successive modifiche / change che potranno intervenire su tali

procedure e segnalazione di possibili anomalie su queste ultime, che il soggetto gestore /

manutentore dell’infrastruttura dovrà prendere in carico e risolvere; l’aggiudicatario dovrà

mantenere l’aderenza alle direttive GDPR per quanto di propria competenza;

gestione del sistema di bilanciamento applicativo;

supporto al mantenimento delle policy di gestione del dominio SISaR, compreso Active

Directory e DNS per il sito centrale – CRESSAN – ed i siti dipartimentali di installazione delle

applicazioni SISaR, che il soggetto gestore / manutentore dell’infrastruttura tecnologica dovrà

attuare e manutenere nel tempo, con indicazione delle possibili successive modifiche /

change che potranno intervenire sulla configurazione di tali elementi e segnalazione di

possibili anomalie su questi ultimi, che il soggetto gestore / manutentore dovrà prendere in

carico e risolvere;

gestione, di concerto con il soggetto gestore / manutentore della infrastruttura, del ripristino

dei sistemi applicativi SISaR a fronte di situazioni di fault della infrastruttura tecnologica, con

eventuale recovery dell’ambiente applicativo e dati SISaR;

supporto al soggetto gestore / manutentore della infrastruttura nella verifica del corretto

funzionamento a valle di aggiornamenti del software di base/ambiente su cui sono in

esecuzione i sistemi applicativi SISaR; in particolare, in coincidenza di disponibilità di

aggiornamenti disponibili per gli elementi software di base / ambiente della infrastruttura

tecnologica SISaR, il soggetto gestore / manutentore di quest’ultima concorderà con

l’Aggiudicatario le tempistiche e le modalità con cui saranno condotte tali upgrade

infrastrutturali al fine di non compromettere la continuità di servizio dei sistemi SISaR

medesimi; qualsiasi aggiornamento di carattere infrastrutturale, hardware e software di

base/ambiente, che il soggetto gestore / manutentore della infrastruttura tecnologica vorrà

introdurre dovrà essere verificato e certificato compatibile con le applicazioni SISaR

congiuntamente con l’Aggiudicatario e con la Direzione Esecuzione del Contratto /

SardegnaIT, e solo dopo si potrà pianificare la messa in produzione di tali upgrade

tecnologici.

In generale, le attività di gestione operativa, amministrazione, monitoraggio, manutenzione e garanzia

della infrastruttura tecnologica, nei suoi elementi hardware e software di base/ambiente, su cui

saranno in esecuzione le applicazioni SISaR, saranno assicurate dal soggetto gestore / manutentore

terzo della medesima e non saranno quindi ricadenti nei servizi inclusi nel contratto oggetto della

presente procedura. L'aggiudicatario dovrà assicurare la gestione sistemistica degli elementi software

di ambiente, RDP, Application Server, software di bilanciamento, RDBMS, che si innestano al di sopra




dei server fisici / virtuali fino ad arrivare ai sistemi operativi e servizi di base della infrastruttura

tecnologica, e che sono direttamente ed esclusivamente utilizzati dalle applicazioni SISaR,

costituendo gli ambienti di rispettiva esecuzione, venendo escluso quanto di competenza del soggetto

gestore / manutentore terzo della infrastruttura tecnologica anzi specificato. In ogni caso

l'aggiudicatario dovrà garantire la schedulazione, l’esecuzione e il controllo delle attività client di

predisposizione del salvataggio dei dati per la piena ripartenza del sistema in caso di disastro e la

definizione delle relative policy. Per quanto riguarda retention e conservazione, l'aggiudicatario è

tenuto a condividere le policy in modo che il sistema di backup, gestito dal soggetto gestore

dell'infrastruttura, possa assicurare quanto richiesto dalle policy stesse.

Il servizio nella sua totalità dovrà essere assicurato attraverso un pool di risorse composto da

Sistemisti che potranno operare di norma da remoto e che, laddove sia richiesto un intervento di

ripristino dei servizi applicativi eseguibile esclusivamente in loco, dovranno operare presso i data

center ove sono installati i sistemi applicativi SISaR – CSR\CRESSAN e CED ASSL/AO regionali. Per

usufruire di tale servizio saranno rese disponibili, a cura di SardegnaIT, le VPN necessarie per

raggiungere i sistemi SISaR presso tutti i siti di installazione.

L’aggiudicatario è in particolare tenuto ad assicurare un costante presidio e controllo, attraverso gli

strumenti di monitoraggio propri dei sistemi applicativi SISaR e del middleware di integrazione, il

funzionamento dei servizi di integrazione implementati lato sistemi SISaR verso sistemi esterni e

interni, in modo da rilevare interruzioni e malfunzionamenti. L’aggiudicatario dovrà assicurare il

monitoraggio applicativo di tutti i sistemi, inclusi il sistema SIDI, il Direzionale e l’ambiente di replica,

per i quali dovrà garantire il corretto, completo e tempestivo caricamento dei dati.

È richiesto che l'aggiudicatario effettui, con cadenza mensile, controlli di qualità sistematici sullo stato

di funzionamento dei moduli applicativi SISaR attraverso la registrazione di operazioni e dati di test,

atti ad assicurare la continuità di corretto funzionamento dei moduli e delle integrazioni. Le verifiche

dovranno riguardare in particolare operazioni che coinvolgano l’interoperabilità con altri

moduli/sistemi, sia interni al SISaR sia di terze parti. L’esecuzione delle attività di verifica dovrà essere

attestata da apposita relazione che descriva l’attività svolta, le verifiche effettuate e il loro esito.

Dovranno essere definite e concordate con la DEC apposite checklist (da affinare progressivamente)

per le attività e le verifiche da eseguire. Ad esempio, al fine di verificare la corretta trasmissione del

CDA del Verbale di Pronto Soccorso al FSE, dovranno essere registrati accessi di PS di pazienti di

test per i quali verificare, oltre alla trasmissione del CDA al FSE, anche la corrispondenza effettiva tra

le informazioni presenti nel Verbale di PS in formato PDF e il CDA acquisito nel FSE; l’attività svolta

dovrà essere documentata allegando i rispettivi documenti: verbale di PS in PDF, rendering del CDA e

lo stesso CDA in formato XML.




Gli errori applicativi rilevati dovranno essere tracciati sul sistema di TT (si veda cap. 10).

L’aggiudicatario dovrà predisporre e tenere aggiornato il manuale di gestione del sistema.








3.7. Servizio A1.7: Servizio di Help Desk

Il servizio di Help Desk ha l’obiettivo di garantire l’assistenza telefonica remota ai Key User ed End

User, per tutti i sistemi applicativi SISaR installati in ambiente di produzione, al fine di supportarli

nell’utilizzo degli stessi e di raccogliere le eventuali segnalazioni di malfunzionamenti del software

applicativo e delle componenti software infrastrutturali dei rispettivi ambienti di esecuzione. Esso viene

erogato in modalità continuativa da remoto dalle strutture di assistenza dell’aggiudicatario attraverso

l’impiego di figure professionali aventi prevalentemente un livello di competenza ed esperienza

corrispondente a Specialista di Prodotto Senior e Specialista di Prodotto.

Il servizio di Help Desk deve assicurare una competenza specialistica multidisciplinare, capace di

fornire un’assistenza telefonica globale sui sistemi applicativi SISaR e sui software di base e di

ambiente SISaR.

Le segnalazioni dovranno essere registrate almeno secondo le seguenti tipologie (la seguente lista

non è da ritenersi esaustiva):

- Formazione applicativa: è una richiesta di chiarimenti su utilizzo del componente\sistema

- Anomalia software: è un bug di un componente\sistema

- Anomalia DB: è una anomalia originata dal DBMS

- Anomalia Hardware: è una anomalia originata dalla infrastruttura hardware

- Richiesta evolutiva: è una richiesta che rappresenta l’esigenza di una nuova funzione o

evoluzione del componente\sistema

- In fase di analisi: è una segnalazione ancora non classificata

- Anomalia da recupero dati: è una anomalia che nasce da un recupero di dati da altro sistema

- Anomalia già registrata: è una anomalia già segnalata precedentemente da altri utenti

- Supporto tecnico-normativo: è una richiesta di supporto sull’utilizzo del sistema in relazione a

una normativa.




L’Aggiudicatario dovrà fornire numeri di telefono e indirizzi di e-mail che gli utenti potranno utilizzare

per inoltrare le richieste di assistenza. Le richieste di assistenza saranno raccolte in un sistema di TT

(p.e. Jira o altro) e saranno catalogate in modo da poter individuare il sistema su cui si chiede

l’Assistenza, il modulo interessato, il richiedente, la data e l’ora della richiesta, la data e l’ora della

chiusura del ticket di assistenza, il tempo netto impiegato per chiudere il ticket e su cui verranno

calcolati gli SLA.

Nel caso l’aggiudicatario dovesse concordare l’utilizzo di un diverso sistema di TT rispetto a quello

attualmente utilizzato (SIPWEB), è prerequisito necessario a carico dell’aggiudicatario che tutto lo

storico delle segnalazioni venga riportato nel nuovo strumento in modo da avere la knowledge base

sempre disponibile. I campi che dovranno essere registrati per ogni anomalia dovranno essere

almeno i seguenti:

- Utente che ha effettuato la segnalazione

- Ente a cui appartiene l’Utente che ha segnalato l’anomalia

- Data e ora della segnalazione

- Componente\sistema SISaR ove è stata riscontrata la anomalia

- Modulo dove è stata riscontrata l’anomalia

- Tipologia della segnalazione

- Stato della anomalia

- Operatore che ha registrato l’anomalia

- Tecnico che ha risolto l’anomalia

- Data e ora di risoluzione dell’anomalia

- Data e ora di risoluzione del malfunzionamento in produzione

- Maschera dove si è verificata l’anomalia

- Versione del modulo dove si è verificata l’anomalia

- Descrizione breve dell’anomalia

- Descrizione estesa dell’anomalia

- Allegato (pdf, jpg, etc.)

- Gravità dell’anomalia

- Urgenza dell’anomalia

- Data e ora di presa in carico della segnalazione

- Descrizione della soluzione

- Storico dei solleciti




Il sistema di TT, come quello attualmente usato, deve dare la possibilità di estrarre i dati almeno nei

formati excel, csv, pdf, xml per la misurazione degli SLA, per tipologia dell’anomalia, per intervallo di

data, per stato dell’anomalia, etc..

Il sistema TT deve essere utilizzabile sia dagli utenti per segnalare direttamente nella piattaforma

l’errore che dall’operatore di HD per registrarlo se ricevuto su telefonata o via e-mail.

Sarà oggetto di valutazione dell’offerta la proposta di ulteriori canali di erogazione del servizio oltre

quello telefonico e l’e-mail, in primis la chat, eventualmente richiamabile dall’interno degli applicativi

stessi.

A titolo informativo, si rappresenta che il numero di ticket gestiti dal servizio di HD nel 2017 per

l’ambito assistenza è stato pari a circa 3.880, mentre nel 2018 è stato pari a circa 3.720.








concorrente dovrà inoltre esplicitare gli eventuali miglioramenti rispetto ai canali di erogazione (p.e.

strumenti di chat), alle casistiche gestite ed all’orario di disponibilità, che saranno elementi oggetto di

valutazione dell’offerta.

3.8. Servizio A1.8: Reperibilità H24 mission critical

Il servizio di Reperibilità H24 completa il servizio di Help Desk, nonché il servizio di Gestione della

Infrastruttura Tecnologica, fornendo una copertura anche nei giorni e nelle fasce orarie da questi non

garantite. Il servizio dovrà operare in maniera opportunamente integrata con i servizi di Help Desk, di

Gestione dell'ambiente di produzione, di Gestione Sistemistico-Applicativa.

Nello specifico esso consta nella erogazione di:

● una reperibilità sistemistica H24 7x7, con esecuzione degli interventi manutentivi che si

rendessero necessari in virtù di malfunzionamenti delle componenti software di base,

middleware di integrazione ed ambiente del sistema SISaR o comunque per mancanza di

disponibilità di servizio della infrastruttura tecnologica SISaR, per quanto di competenza, negli

orari di non copertura del servizio di Gestione Sistemistico-Applicativa; tale servizio dovrà

assicurare anche una reperibilità sistemistica sulle applicazioni SISaR con esecuzione degli




interventi di ripristino dei servizi applicativi che si rendessero necessari a fronte di eventuali

fault dei rispettivi ambienti di esecuzione;

● una reperibilità H24 7x7 per assistenza sui sistemi mission-critical, quali sono i sistemi

applicativi SISaR Trasfusionale (denominato ELIOT) e Pronto Soccorso, nonché per interventi

manutentivi tesi a risolvere situazioni bloccanti derivanti da malfunzionamenti software, come

ad esempio i servizi web al cittadino, mediante soluzioni di work around – ovvero che non

implichino rilascio di patch/release software da rendersi negli orari di non copertura del

servizio di Help Desk sopra descritto;

● una reperibilità in giorno di sabato, almeno nella fascia oraria 08:00 – 13:00, per assistenza

sul sistema applicativo CUP SISaR, nonché per interventi manutentivi tesi a risolvere

situazioni bloccanti derivanti da malfunzionamenti di tale software, mediante soluzioni di work

around – ovvero che non implichino rilascio di patch/release software.

Tale servizio dovrà essere erogato da remoto mediante un apposito numero telefonico con cui l’utente

potrà contattare direttamente le risorse tecniche dell’Aggiudicatario SISaR preposte allo scopo,

nonché un accesso via VPN – assicurato a cura di SardegnaIT – ai sistemi infrastrutturali ed

applicativi SISaR.

L'aggiudicatario è tenuto a garantire la tracciabilità del servizio sul sistema di TT e il rispetto degli SLA

concordati.

A titolo informativo, si comunica che il numero di interventi in reperibilità dal 01.07.2017 al 30.06.2018

è stato pari a 175. Il numero di interventi in reperibilità nel 2018 è stato pari a 142.








4. AREA 2 – REALIZZAZIONE NUOVA ARCHITETTURA

Oggetto delle attività di quest’area è la reingegnerizzazione dell’architettura del SISaR al fine di

renderla allo stato dell’arte rispetto all’utilizzo compiuto di una infrastruttura di integrazione e

interoperabilità (ESB) standard, con l’obiettivo specifico di disaccoppiare su tale impianto i moduli e




sistemi che costituiscono il SISaR. Gli applicativi SISaR dovranno essere modificati di conseguenza

per adeguarli all’utilizzo ottimale della nuova architettura, nel rispetto dell’obiettivo, che deve essere

sempre assicurato, di migliorare la qualità e le performance del sistema complessivo. I rilasci di nuove

versioni del software centrale o dei moduli applicativi dipartimentali effettuati nell’ambito della presente

Area dovranno sempre essere concepiti ed attuati nel rispetto del corretto funzionamento di tutto il

sistema SISaR, senza soluzione di continuità. Quanto sviluppato e rilasciato nell’ambito della presente

Area diverrà a sua volta oggetto dei servizi dell’Area 1.

È oggetto della presente Area la reingegnerizzazione delle attuali integrazioni per portarle sulla nuova

piattaforma di interoperabilità, anch’essa da fornire nell’ambito dell’appalto, rendendo contestualmente

disponibile un sistema di monitoraggio che consenta di gestire in maniera più efficace le integrazioni

fra il sistema SISaR e i sistemi esterni e fra i macrocomponenti del sistema SISaR stesso.

Secondo le scadenze indicate al cap. 12, l’Aggiudicatario dovrà consegnare e aggiornare un piano per

la fornitura, installazione e configurazione della nuova infrastruttura di integrazione e per la migrazione

e disaccoppiamento dei macrocomponenti del SISaR.

Nella erogazione dei servizi in oggetto è richiesto che, in caso di modifica dell’interfaccia utente, si

applichino la Progettazione orientata all’utente e i principi di usabilità e User Experience, come già

specificato nel capitolo 2.3.

4.1. Servizio A2.1: Sistema Enterprise Service Bus

Si richiede la fornitura, l’installazione e la configurazione di una infrastruttura di interoperabilità di

livello enterprise, allo stato dell’arte rispetto agli standard qualitativi internazionali in materia, che

includa sia un Enterprise Service Bus (ESB) sia una componente API Gateway.

Per Enterprise Service Bus (ESB) si intende un'infrastruttura tecnologica che disaccoppia il dominio

dei sistemi fornitori di servizi (provider) da quello dei sistemi fruitori (consumer). I sistemi consumer si

collegano al bus e non al provider del servizio che effettivamente implementa il servizio. In questo

modo, da un lato si disaccoppia in modo forte il consumer dal provider del servizio specificatamente

richiesto e dall’altro si concentra nel canale (bus) l’implementazione dei servizi di log, di audit, di

routing, di sicurezza, di garanzia di consegna, di trasformazione e di integrazione che diversamente

necessiterebbero di specifico sistema di monitoraggio per ciascuna coppia provider-consumer.

L’implementazione e la gestione comune dei servizi del bus contribuiscono ad aumentare la

sicurezza, la flessibilità e la gestibilità di un’architettura SOA, aumentando l’ottimizzazione degli

investimenti ed aprendo la strada a future evoluzioni verso architetture a microservizi. Il Modello

architetturale di riferimento è particolarmente coerente con un approccio Hub&Spoke, che è quello cui

mira la Regione Sardegna, superando le frequenti integrazioni point-to-point, di difficile gestione e

monitoraggio, nonché maggiormente onerose.




L’infrastruttura di interoperabilità richiesta dovrà includere anche una componente di API Gateway

(API Management) che permetta la pubblicazione di API attraverso uno Store, con la centralizzazione

dei servizi di gestione, monitoraggio e sicurezza per i servizi pubblicati.

La fornitura dell’infrastruttura di interoperabilità ESB/API è funzionale anche al perseguimento di un

obiettivo generale di disaccoppiamento delle componenti applicative.

Ad esito dei servizi della presente Area, tutti i processi di integrazione (in essere e in divenire) fra i

macrocomponenti di cui è composto il SISaR e fra questi e i sistemi esterni al SISaR dovranno essere

gestiti tramite l’ESB/API.

È quindi inclusa e obiettivo del presente servizio la reingegnerizzazione delle attuali integrazioni per

portarle sulla piattaforma di interoperabilità rendendo al contempo disponibile il sistema di

monitoraggio che consenta di poter gestire in maniera più efficace le integrazioni fra il sistema SISaR

e i sistemi esterni e fra i macrocomponenti del sistema SISaR stesso (rif. cap. 4.2).

L’importo contrattuale per il componente sopra descritto verrà riconosciuto con valore a corpo unitario

una tantum da rendicontare secondo Stato d’avanzamento lavori e dovrà prevedere anche

l’assistenza in garanzia per tutta la durata del contratto.

4.1.1 Descrizione della infrastruttura richiesta / servizio

La fornitura della infrastruttura di interoperabilità dovrà essere composta almeno da quanto di seguito

descritto:

Un ESB con inclusa componente di API Gateway con le caratteristiche tecniche riportate ai

paragrafi seguenti, incluse tutte le licenze necessarie al suo utilizzo per l’intero periodo

contrattuale, indipendentemente dal numero di utenti o transazioni gestite o dall’incremento

del carico, e i servizi professionali di installazione, configurazione e messa in esercizio.

Qualora l’operatività del ESB/API richieda un DBMS di appoggio, la fornitura dovrà includere

tutte le licenze necessarie al suo utilizzo. L’installazione, la configurazione, la messa in

esercizio e la gestione per l’intero periodo contrattuale - indipendentemente dal numero di

utenti o transazioni gestite o dall’incremento del carico di tale ESB/API - sono incluse nei

servizi di gestione ambiente di test, gestione ambiente di produzione e gestione sistemistico-

applicativa.

Una volta condotta in esercizio la piattaforma fornita, i Servizi professionali di gestione e di

monitoraggio continuativo dell’infrastruttura ESB/API e dell’eventuale DBMS di cui sopra e la

produzione di report specifici sulle integrazioni per l’intero periodo contrattuale saranno inclusi nei

servizi di gestione degli ambienti applicativi di cui al cap. 3.5 e di gestione sistemistico-applicativa di

cui al cap. 3.6.

L'aggiudicatario potrà proporre - giustificando vantaggi e opportunità della scelta progettuale - una

modalità di deployment dell’infrastruttura di interoperabilità ESB/API secondo i seguenti modelli:

Deployment centralizzato: un’unica installazione centralizzata dell’EBS/API.




Deployment distribuito: singole installazioni ESB/API aziendali (una per ciascun nodo

aziendale SISaR) e una centrale: strumenti di sviluppo, monitoraggio e componenti runtime

sono indipendenti le une dalle altre.

Deployment in cloud:

o I flussi di integrazione sono deployabili in un ambiente gestito dal provider cloud,

oppure come componenti di runtime su infrastruttura locale, comunque collegati alla

piattaforma cloud.

o Gli strumenti di gestione, sviluppo e monitoraggio sono centralizzati, mentre le

componenti runtime possono essere sia centralizzate che locali.

Nell’offerta tecnica, il concorrente dovrà presentare una descrizione tecnica completa delle forniture

proposte e delle modalità di installazione, deployment e configurazione. Dovrà in particolare attestare

le caratteristiche dell’ESB/API secondo l’apposita griglia allegata al modello di offerta tecnica.

4.1.2 Caratteristiche specifiche della componente ESB

L’ESB dovrà supportare le seguenti caratteristiche funzionali:

Routing: fornire la possibilità di smistare una richiesta verso un particolare service provider

basandosi sia sugli standard di instradamento (ws:addressing e simili) sia sul contenuto dei

messaggi.

Filtering: possibilità di bloccare messaggi in base al loro contenuti.

Message transformation: essere in grado di convertire la struttura e il formato del payload

della richiesta effettuata dal consumer nel formato effettivamente gestibile dal service

provider, e viceversa per la risposta.

Message enhancement: aggiungere, modificare o eliminare un’informazione contenuta in un

messaggio in modo da renderlo compatibile col service provider (ad esempio, convertendo il

formato delle data o aggiungendo informazioni non presenti originariamente).

Message Delivering: assicurare il delivery dei messaggi di richiesta e di risposta.

Protocol transformation: consentire di inviare lo stesso payload utilizzando un differente

protocollo. Ad esempio, accettare un tipo di protocollo nei confronti del consumer (p.es.

SOAP, JMS) e comunicare al service provider attraverso un altro protocollo (p.es. REST).

Service orchestration: fungere da coordinatore che controlla i servizi coinvolti e coordina

l’esecuzione delle differenti operazioni. Per questa funzionalità devono essere supportati

linguaggi standard quali BPEL (Business Process Execution Language) o BPMN (Business

Process Modeling Notation).

Ulteriori requisiti funzionali dell’ESB:

La messaggistica deve supportare i principali standard di comunicazione: SOAP 1.1, SOAP

1.2, POX, HTML, Plain text, Binary, JSON.




La messaggistica deve supportare i principali protocolli di comunicazione, tra cui: HTTP/S,

POP/IMAP, SMTP, JMS, File transport (FTP/SFTP/CIFS).

Supporto degli standard: WS-Addressing, WS-Security, WS-Reliable Messaging, WS-Policy,

WS-Discovery.

Deve garantire l’interoperabilità tra sistemi a prescindere dalle tipologie del sistema operativo

(windows, unix, linux, etc.) e dei linguaggi di programmazione (JAVA, .NET, etc.).

Deve processare, consentire o rifiutare gli allegati alla messaggistica (MIME, DIME, MTOM).

Deve supportare i formati di messaggistica standard in sanità, tra cui HL7, DICOM, etc.. In

particolare, per la messaggistica HL7 deve essere previsto il supporto nativo per le versioni

2.x e 3.

Deve supportare i profili di integrazione IHE.

Deve supportare le integrazioni verso il data layer. e in particolare tutte le versioni dei

principali RDBMS (Oracle, Microsoft SQL Server, Postgres; MySQL, DB2, etc.).

Deve supportare i paradigmi publish&subscribe ed event driven.

Deve supportare i diversi Message Exchange Patterns: richiesta-risposta sincrona o

asincrona.

Deve essere integrato in un ambiente di sviluppo.

Deve offrire i servizi di test per validare le diverse componenti delle interfacce.

Deve essere gestito il versioning per i servizi ed i processi resi disponibili.

Deve fornire la persistenza di tutti i messaggi e dei processi attraverso il DBMS di appoggio.

Deve mettere in coda o bloccare i messaggi se alcune applicazioni collegate al bus non sono

momentaneamente disponibili.

Deve gestire un motore di regole (Business Rules Engine, BRE) estensibile ed utilizzabile in

modo efficace anche da non programmatori.

Deve garantire il log e la tracciabilità di tutte le operazioni e messaggi gestiti; in particolare,

deve disporre di una console grafica per il log, il monitoraggio la tracciabilità dei messaggi

(Business Activity Monitoring, BAM), il loro recupero, la loro visualizzazione, l’eventuale

modifica e re-inoltro. Inoltre, deve essere possibile monitorare i livelli di servizio (Service Level

Monitoring, SLM) e gli indicatori chiave di performance per ogni servizio/metodo esposto.

Possibilità di scrivere log su file dedicati o syslog.

Deve avere un motore per la gestione di Business Process (Business Process Management,

BMP) che supporti:

o l’orchestrazione dei processi di business;

o la possibilità per gli sviluppatori di definire la logica di business attraverso la

modellazione grafica o attraverso linguaggi quali BPEL e BPMN;




o l’integrazione con il BRE in modo da poter modificare il comportamento dei processi

gestiti lavorando sulle regole e non sul codice;

o la separazione delle regole dalla logica di business in modo da poterle riutilizzare

facilmente;

o l’integrazione con il BAM ai fini di monitorare l'attività e lo stato dei singoli processi

aziendali e dell'intero sistema.

Deve supportare l’esecuzione di task, anche periodici.

4.1.3 Caratteristiche specifiche della componente API Gateway

La componente API Gateway dovrà supportare i requisiti funzionali seguenti:

Deve fornire un’interfaccia grafica che renda disponibili tutte le funzionalità necessarie agli

amministratori del sistema.

API Store GUI: deve fornire un’interfaccia grafica che metta a disposizione tutte le funzionalità

necessarie ai consumer delle API per fare discovery, enrollment e sottoscrizione alle API in

modalità user friendly. L'interfaccia include anche un ambiente di test.

Publisher GUI: deve fornire un’interfaccia grafica che metta a disposizione tutte le funzionalità

necessarie alla pubblicazione delle API.

Deve supportare pienamente lo standard Swagger:

- possibilità di esportare le API in file di formato standard Swagger

- possibilità di creare API a partire da file in formato standard Swagger

- possibilità di creare API da endpoint Swagger.

Possibilità di configurare distintamente un endpoint per l'ambiente di sviluppo e un endpoint di

produzione.

Possibilità di storicizzare in modo permanente e consultabile tutti gli scambi di messaggi che

avvengono tramite API.

Possibilità di correlare i messaggi storicizzati afferenti allo stesso flusso logico.

Gestione del ciclo di vita delle API.

Possibilità di versionare differenti rilasci dell'API.

Throttling: limitare l’utilizzo delle API in base al tipo di sottoscrizione.

Possibilità di adottare policy bloccanti basate su:

- IP o range di IP preconfigurati

- campi specifici dell'header della request

- campi specifici del token JWT veicolato nella request

- campi specifici della URL della request

Possibilità di accettare un numero limitato di richieste per API in un intervallo di tempo

configurabile.




Possibilità di scrivere log su file dedicati o syslog.

Integrazione col sistema di pagamenti elettronici verso la Pubblica Amministrazione

(PagoPA).

Possibilità di esporre un API unica che integri diversi servizi di backend al fine di esporre una

singola funzionalità in modalità semplificata.

Supporto ad interfacce di backend di tipo REST, SOAP e Websocket.

Possibilità di trasformare il messaggio in ingresso al gateway prima che venga inoltrato al

backend, e, viceversa, possibilità di trasformare il messaggio di risposta al gateway prima che

venga inoltrato al client.

Possibilità di integrare sistemi di backend protetti con: user/pwd, protocollo OAuth2.

Strumenti di monitoraggio e analisi sull’utilizzo delle API sul carico a cui sono sottoposte

(numero di chiamate ricevute, numero di chiamate completate con successo, tempo medio,

minimo e massimo di risposta, risorse utilizzate, etc.).

4.1.4 Requisiti generici comuni per ESB/API

L’infrastruttura ESB/API complessiva deve inoltre garantire i seguenti requisiti:

Deve assicurare elevate performance e garantire la scalabilità orizzontale e verticale dellapiattaforma.

Deve essere configurabile per operare in alta affidabilità mediante l’installazione e la

configurazione di un cluster di almeno due nodi. Devono essere supportate le comuni

modalità di configurazione del cluster:

o Attivo/Passivo: in questa configurazione, composta tipicamente da 2 nodi, un nodo è

attivo, mentre l’altro, in riserva calda, subentra in caso di crash del nodo attivo.

o Attivo/Attivo: in questa configurazione l’ESB/API è installato su N nodi e il carico è

bilanciato su tutti i nodi. In caso di crash di un nodo, il carico viene automaticamente

ripartito sui rimanenti.

Gli strumenti di monitoraggio resi disponibili devono rilevare in anticipo le criticità che

potrebbero portare alla non disponibilità di uno o più nodi.

I requisiti di scalabilità e alta affidabilità devono intendersi estesi a tutte le componenti

dell’infrastruttura ESB/API.

Deve rendere disponibile un’interfaccia grafica che metta a disposizione tutte le funzionalità

necessarie agli amministratori del sistema.

Possibilità di effettuare operazioni di tuning per garantire un livello di servizio conforme alle

attese.

Deve permettere di gestire gli errori e definire le azioni da eseguirsi nel caso di un’eccezione.

Deve consentire di configurare alert basati su eventi.




Possibilità di creare report, generare statistiche e grafici.

Deploy in business continuity: il rilascio di nuove funzionalità, processi, metodi e operazioni

deve avvenire con rilasci a caldo senza dover gestire tempi di down del sistema.

4.1.5 Requisiti di sicurezza comuni per ESB/API

L’infrastruttura ESB/API complessiva deve soddisfare i seguenti requisiti di sicurezza:

Deve proteggere i servizi da accessi non autorizzati, gestendo: l’autenticazione,

l’autorizzazione e l’auditing.

Deve gestire la profilazione di utenti e gruppi di utenti per ruoli e attributi (RBAC, ABAC).

Integrazione con il Sistema Pubblico di Identità Digitale (SPID).

Transport Level Security: possibilità di configurare il protocollo SSL/TLS.

Deve supportate l'autenticazione SSL reciproca attraverso la verifica dei rispettivi certificati

digitali.

Possibilità di applicare il protocollo autorizzativo OAuth2 come controllo degli accessi ai

servizi.

Protezione da attacchi DOS.

Possibilità di applicare il protocollo autorizzativo SAML come controllo degli accessi utente.

Deve supportare obbligatoriamente i seguenti standard specifici di settore: WS Security 1.1,

WS Policy, WS Addressing, SAML 2, LDAP, X.509, XML Signature, XML Encryption.

sono inoltre considerati ulteriori standard rilevanti al fine della valutazione: WS Trust, XACML,

PKI, WS Reliability, WS ReliableMessaging.

4.2. Servizio A2.2: Evoluzione e migrazione su nuova infrastruttura e disaccoppiamentofunzionale

Il servizio in oggetto comprende l’attuazione degli interventi di evoluzione e manutenzione necessari

per l’implementazione, la migrazione e conduzione a regime del SISaR al nuovo modello di

interoperabilità su ESB:

Migrazione delle attuali integrazioni sul nuovo ESB/API

Disaccoppiamento delle macrocomponenti del SISaR

Obiettivo del servizio è condurre e migrare il sistema, entro la conclusione del contratto, in uno stato di

funzionamento ottimale consolidato e a regime sulla nuova architettura di integrazione basata su

ESB/API fornita nell’ambito dell’appalto stesso.









4.2.1 Migrazione delle attuali integrazioni sul nuovo ESB/API

Si richiede che tutte le integrazioni esistenti all’atto dell’avvio del contratto, tra cui quelle che

attualmente insistono sul middleware di integrazione SpagiC, realizzate con sistemi terze parti o tra

moduli SISaR, siano trasferite sulla nuova infrastruttura ESB/API proposta dall’Aggiudicatario (rif. cap.

4.1). Più in generale, per quanto concerne le integrazioni esistenti tra moduli SISaR, è richiesto che:

Le integrazioni tra due o più moduli distinti realizzate tramite accesso diretto ai dati devono

essere disaccoppiate tramite l’ESB/API, che esporrà una specifica API che accederà in lettura

ai dati del sistema provider e un’altra da invocare su richiesta dal sistema consumer, o

comunque secondo uno scheduling prestabilito definito nell’ESB.

Nell’ESB dovranno essere ricostruite le code applicative per la trasmissione asincrona di dati

ad altri sistemi. Ad esempio, ricadono in questa fattispecie le code di invio dei CDA al

FSE/Medir.

Tutte le integrazioni, flussi di dati (anche ETL) attualmente comandati da cron job devono

essere messi sotto il controllo dell’ESB che si occuperà dello scheduling e del monitoraggio.

Il concorrente dovrà descrivere come intende procedere per il servizio di Migrazione delle attuali

integrazioni sul nuovo ESB/API secondo le indicazioni riportate nel presente paragrafo e presentare il

piano temporale di realizzazione. Dato atto che è interesse dell’Amministrazione disporre quanto

prima del sistema in esercizio migrato sulla nuova infrastruttura, saranno infatti oggetto di valutazione

anche le tempistiche proposte.

4.2.2 Disaccoppiamento delle macrocomponenti del SISaR

Il termine macrocomponente indica un raggruppamento di uno o più componenti applicative distinte

tra le quali non è richiesta come obbligatoria la realizzazione di un disaccoppiamento tramite

l’ESB/API. Viceversa, qualunque accoppiamento tra componenti applicative appartenenti a

macrocomponenti differenti dovrà essere disaccoppiata per tramite dell’ESB/API.

Il servizio consiste nella realizzazione di manutenzione evolutiva necessaria affinché le principali

macrocomponenti funzionali di cui è composto il SISaR dialoghino esclusivamente tramite l’ESB/API

oggetto di fornitura nella presente procedura di gara (Cap. 4.2.1). Le macrocomponenti

(raggruppamenti composti da uno o più componenti applicative distinte) da disaccoppiare tramite

l’ESB/API sono individuate di seguito (le macrocomponenti sono indicate come elenco di componenti

racchiuse tra [..]):




Per il Sistema Informativo Amministrativo si individuano le seguenti macrocomponenti:

o [AMC]

o [Controllo di Gestione]

o [HR]

o [Ripresa]

o [Protocollo]

o [Atti e delibere]

o [Documentale]

Per il Sistema Informativo Ospedaliero si individuano le seguenti macrocomponenti:

o [XMPI, LA, ADTWEB, PSWEB, OEPR, EMR]

o [SOWEB]

o [ELIOT]

o [Repository Documentale]

Per il Sistema Gestore Risorse (CUPWEB) e Cartella Clinica Ambulatoriale (CCA) si

individuano le seguenti macrocomponenti:

o [CUPWEB]

o [ePrescription]

o [CCA]

Per il Sistema Informativo Territoriale si individuano le seguenti macrocomponenti:

o [PUA]

o [CSS]

o [ADI]

o [Medicina Legale]

o [Cartella Consultori]

o [SPRESAL]

o [Protesica]

o [RSA]

o [SIAN]

o [Amianto]

o [Notifica Preliminare Cantieri]

Per il Sistema Integrato Debito Informativo (SIDI) si individuano le seguenti macrocomponenti:

o [SIDI]

Per il Sistema Informativo Direzionale si individuano le seguenti macrocomponenti:

o [Direzionale]




Le integrazioni esistenti, o da realizzarsi, tra macrocomponenti distinte del SISaR, dovranno migrare

sul nuovo ESB/API, secondo le seguenti linee guida:

Le integrazioni tra due o più moduli appartenenti a macrocomponenti distinti realizzate tramite

accesso diretto ai dati devono essere disaccoppiate tramite l’ESB/API, che esporrà specifiche

API, una che accederà in lettura ai dati del sistema provider e una da invocare su richiesta dal

sistema consumer, o comunque secondo uno scheduling prestabilito definito nell’ESB/API.

Nell’ESB dovranno essere ricostruite le code applicative per la trasmissione asincrona di dati

ad altri sistemi.

Tutte le integrazioni e i flussi di dati (anche ETL) attualmente comandati da cron job devono

essere messi sotto il controllo dell’ESB che si occuperà dello scheduling e del monitoraggio.

Il disaccoppiamento effettivo tra macrocomponenti distinte dovrà consentire la sostituzione di singoli

macrocomponenti senza rinunciare ad alcuna funzionalità del sistema preesistente, senza apportare

altre modifiche ad alcun componente del sistema SISaR, e senza che il macrocomponente sostitutivo

debba conoscere dettagli implementativi del macrocomponente SISaR preesistente.

La figura seguente riassume lo scenario di integrazione complessivo; in particolare, evidenzia la

modalità di integrazione tra i livelli SISaR centralizzato e aziendali, da realizzarsi tramite i rispettivi

ESB/API o comunque sotto il loro stretto controllo e continuo monitoraggio.




Figura 1 Panoramica di alto livello sulle integrazioni

SISaR - Nodo Regionale

Enterprise Serv ice Bus (ESB) [Regionale]

Enterprise Serv ice Bus (ESB) [Aziendale]

Livello Regionale

Livello Aziendale

SISaR - Nodo Aziendale

Sistema Terze Parti

Sistema Terze Parti

Sistema Terze PartiModulicentralizzati

Modulicentralizzati

Modulicentralizzati

Sistema Terze Parti

Sistema Terze Parti

Sistema Terze PartiModuli

dipartimentale

Modulidipartimentale

Modulidipartimentali




La figura seguente riassume lo scenario di integrazione interne ai moduli SISaR centralizzati, e tra

questi e i sistemi terze parti.

Figura 2 Panoramica integrazioni regionali centralizzate

La figura seguente riassume lo scenario di integrazione interna ai moduli SISaR aziendali, e tra questi

e i sistemi terze parti.

Figura 3 Panoramica integrazioni aziendali e dipartimentali

Le integrazioni da realizzarsi tramite intermediazione del nuovo ESB/API sono individuate sulla base

del singolo applicativo specifico e sono individuate ai paragrafi che seguono.

Portali

SISaR - Nodo Regionale

SIDI

Direzionale

HR DocumentaleModulo SRC AMC

Atti e DelibereProtocollo RENCAM CUP/WBS

XMPI

Enterprise Serv ice Bus (ESB) [Regionale]

Livello Regionale

PortaleDipendente

Monitor PS Portale Amianto NPCWEB

ETL Flussi

CUPWEB

ePrescription

Sistema TerzeParti

Sistema TerzeParti

Sistema TerzeParti

ADI PUA

ProtesicaMedicina Legale

SPRESAL CartellaConsultori

RSA/Hospice

Livello Aziendale

SIANCEDAP Medicina delloSport

Enterprise Serv ice Bus (ESB) [Aziendale]

SISaR - Nodo Aziendale

ADTWEB PSWEB SOWEBXMPI OEPRLista Attesa

RepositoryDocumentale

ETL FlussiEMRCCAELIOT

SISP

Sistemi DipartimentaliTerze Parti

Sistemi DipartimentaliTerze Parti

LIS

RIS/PACS

AP

Altri sistemi





corpo unitario ed erogato per Stati di Avanzamento Lavori.

Il concorrente dovrà descrivere come intende procedere per l’evoluzione delle integrazioni come

richiesto nel presente paragrafo e fornire il piano temporale di realizzazione. Il concorrente dovrà

descrivere la proposta progettuale e tecnica, relativamente al servizio in oggetto, incluso il passaggio

in produzione della versione del SISaR con la nuova release del SISaR, le tempistiche di

realizzazione con gli annessi eventuali rischi e disservizi eventualmente necessari per il passaggio in

produzione e le misure previste per l’attenuazione e il contenimento degli stessi.

4.2.2.1 Integrazioni da migrare o realizzare su ESB/API

Nei paragrafi seguenti vengono indicate le integrazioni tra i moduli SISaR e altre componenti afferenti

a macrocomponenti distinti o sistemi terze parti, per le quali è richiesta la realizzazione per mezzo

della nuova infrastruttura ESB/API.

4.2.2.1.1 Integrazioni in ambito Sistema Informativo Amministrativo

Per quanto riguarda le integrazioni inerenti il sistema informativo amministrativo, si richiede che tutte

le integrazioni fra i macrocomponenti ad esso afferenti siano realizzate per tramite della nuova

infrastruttura ESB/API e poste sotto controllo e monitoraggio dell’ESB.

4.2.2.1.2 Integrazioni del modulo XMPI

Per quanto riguarda le integrazioni tra XMPI e i sistemi di terze parti, i messaggi HL7 per l’inserimento

e le variazioni anagrafiche dovranno essere trasmessi tramite l’ESB: XMPI dovrà notificare l’evento

all’ESB il quale a sua volta si occuperà di trasmetterlo a tutti i sistemi sottoscrittori.

Per quanto attiene i flussi di interoperabilità anagrafica tra le installazioni XMPI dipartimentali (più il

CUP) e l’installazione XMPI centrale è richiesto che siano messe sotto il controllo dell’ESB.

Per quanto riguarda l’integrazione tra ANAGS e l’installazione XMPI centrale per lo scarico delle

variazioni anagrafiche, già attiva, questa dovrà essere messa sotto controllo e monitoraggio dal ESB.

4.2.2.1.3 Integrazioni del modulo ADTWEB

È richiesto che tutti gli eventi di prericovero, accettazione, trasferimento e dimissione, nonché

annullamento e aggiornamento delle relative informazioni, trasmessi con messaggistica HL7 da

ADTWEB ai sistemi terzi integrati, siano implementati tramite l’ESB: ADTWEB dovrà notificare

l’evento all’ESB che si occuperà di trasmetterlo a tutti i sistemi sottoscrittori.

Per quanto riguarda le code applicative di invio al FSE/Medir dei CDA prodotti da ADTWEB è richiesto

che siano implementate sull’ESB, che si dovrà occupare della trasmissione al FSE.




Si richiede che le seguenti integrazioni di ADTWEB con gli altri moduli SISaR siano messe sotto

controllo e monitoraggio dell’ESB:

- Repository Documentale. Gli eventi di salvataggio e recupero della documentazione dal

repository dovranno essere implementati tramite l’ESB.

- SOWEB. L’acquisizione nella SDO delle informazioni su interventi gestite da SOWEB dovrà

transitare da ESB con l’implementazione di un servizio provider che acquisisca i dati richiesti

da SOWEB e di un consumer da invocare da ADTWEB o comunque schedulato.

- ETL Flussi. Le estrazioni massive di dati da altri sistemi dovranno essere messe sotto il

controllo e monitoraggio dell’ESB

4.2.2.1.4 Integrazioni del modulo PSWEB

Si richiede che le seguenti integrazioni di PSWEB con gli altri moduli SISaR siano messe sotto

controllo e monitoraggio dell’ESB:

- Repository Documentale. Gli eventi di salvataggio e recupero della documentazione dal

repository dovranno essere implementati tramite l’ESB.

- ETL Flussi. Le estrazioni massive di dati da altri sistemi dovranno essere messe sotto il

controllo e monitoraggio dell’ESB

- SPRESAL. Tale integrazione è necessaria per la notifica degli infortuni sul lavoro.

- CUPWEB. La trasmissione bidirezionale di dati tra PSWEB e CUPWEB per le informazioni di

pagamento, per i ticket di Pronto Soccorso e le prestazioni erogate per pazienti solventi, e le

informazioni di avvenuto pagamento dovrà transitare tramite ESB

È richiesto che tutti gli eventi di accettazione e dimissione trasmessi con messaggistica HL7 da

PSWEB ai sistemi terzi integrati siano implementati tramite l’ESB: il PSWEB dovrà notificare l’evento

all’ESB che si occuperà di trasmetterlo a tutti i sistemi sottoscrittori.

Per quanto riguarda le code applicative di invio al FSE/Medir dei CDA prodotti da ADTWEB è richiesto

che siano implementate sull’ESB, che si dovrà occupare della trasmissione al FSE.

Il PSWEB dovrà verificare lo stato di attivazione del FSE e la presenza del documento PS-EDS

tramite l’ESB.

È richiesto che le integrazioni bidirezionali tra PSWEB e le Centrali Operative 118 avvengano tramite

ESB.

È richiesto che anche la trasmissione all’INAIL delle certificazioni di infortunio sia governata da ESB.




4.2.2.1.5 Integrazioni del Monitor Pronto Soccorso

È richiesto che i flussi di dati sugli accessi di PS e sui posti letto nei reparti di degenza acquisiti dal

Monitor di Pronto Soccorso con strumenti ETL siano schedulati e monitorati dall’ESB.

4.2.2.1.6 Integrazioni modulo OEPR

Tutti i messaggi HL7 bidirezionali tra OEPR e i sistemi dipartimentali LIS, RIS/PACS, AP,

Trasfusionale e CCA è richiesto che transitino sull’ESB.

È richiesto che tutti gli eventi di salvataggio e recupero della documentazione dal Repository

Documentale siano messi sotto controllo e monitoraggio dell’ESB.

4.2.2.1.7 Integrazioni modulo SOWEB

È richiesto che le informazioni su interventi chirurgici ai fini della condivisione con ADTWEB transitino

tramite ESB con l’implementazione di un servizio provider per l’accesso ai dati SOWEB e uno

consumer da invocare da ADTWEB o comunque schedulato.

Analogamente, le informazioni sul consumo dei medicinali da trasmettere al sistema AMC dovranno

transitare sull’ESB, sotto il controllo e monitoraggio dello stesso.

È richiesto che gli eventi di salvataggio e recupero della documentazione dal Repository Documentale

siano messi sotto controllo e monitoraggio dell’ESB.

4.2.2.1.8 Integrazioni del modulo ELIOT

Per quanto riguarda le integrazioni del modulo ELIOT si richiede:

- che i messaggi HL7 bidirezionali tra ELIOT e OEPR per le richieste informatizzate di

emocomponenti ed esami e dello stato di esecuzione transitino tramite l’ESB;

- che gli eventi di salvataggio e recupero della documentazione dal Repository Documentale

siano messi sotto controllo e monitoraggio dell’ESB;

- che l’interscambio bidirezionale dei dati di richiesta ed esito tra ELIOT e il LIS/Galileo sia

realizzato tramite ESB;

- che i flussi massivi di dati da ELIOT a SRC siano governati da ESB;

- che l’interscambio di dati tra ELIOT e il Broker Esami avvenga sotto controllo e monitoraggio

dell’ESB.

4.2.2.1.9 Integrazioni del modulo EMR

Per quanto riguarda le integrazioni del modulo EMR si richiede:

- che gli eventi di salvataggio e recupero della documentazione dal Repository Documentale

siano messi sotto controllo e monitoraggio dell’ESB;




- che la trasmissione ad AMC delle informazioni sui medicinali somministrati sia messa sotto

controllo e monitoraggio dell’ESB.

4.2.2.1.10 Integrazioni in ambito CUPWEB e CCA

Per quanto riguarda le integrazioni fra CUPWEB e Cartella Clinica Ambulatoriale è richiesto:

- che i messaggi bidirezionali tra CUPWEB e la CCA per le richieste di prestazioni e la notifica

dello stato di esecuzione transitino tramite gli ESB/API centrale e aziendale;

- che i messaggi HL7 bidirezionali tra CUPWEB e i sistemi dipartimentali LIS e RIS (e altri

eventuali sistemi terze parti) per le richieste di prestazioni e la notifica dello stato di

esecuzione transitino tramite gli ESB centrale e aziendale;

- che i messaggi HL7 bidirezionali tra OEPR e CCA per le richieste di prestazioni, notifica dello

stato di esecuzione e invio del referto finale transitino tramite l’ESB aziendale.

4.2.2.1.11 Integrazioni in ambito Sistema Informativo Territoriale

Per quanto riguarda il sistema informativo territoriale si richiede che tutte le integrazioni fra i

macrocomponenti ad esso afferenti siano realizzate per il tramite della nuova infrastruttura ESB/API e

poste sotto controllo e monitoraggio dell’ESB.

4.2.2.1.12 Integrazioni in ambito SIDI

Per quanto riguarda il sistema integrato debito informativo non sono previste integrazioni da mettere

sotto il controllo e monitoraggio dell’ESB.

4.2.2.1.13 Integrazioni in ambito Sistema Informativo Direzionale

Per quanto riguarda il Sistema Informativo Direzionale è richiesto che la schedulazione delle attività

eseguite dal Direzionale per l’estrazione dei dati che alimentano il DWH transitino sotto il controllo e

monitoraggio dell’ESB centrale.

5. AREA 3 – SERVIZI DI TRANSIZIONE

I servizi della presente area hanno per oggetto il passaggio di consegne “in uscita” dal contratto,

consistente nelle attività finalizzate a consentire il pieno subentro di uno o più nuovi fornitori nelle

attività di gestione e manutenzione del sistema. Tali servizi saranno erogati negli ultimi 3 mesi della

durata contrattuale (compreso l’eventuale ricorso alle opzioni di rinnovo e/o proroga) come riportato

anche nel Capitolo 2.1.

Durante il periodo di transizione non saranno più consentiti interventi di manutenzione evolutiva “a

consumo\misura” quali quelli descritti nel capitolo 3.3. Prima dell’avvio dei servizi di transizione gli

interventi di manutenzione evolutiva “a consumo” dovranno essere quindi consolidati e stabili. Nello

stesso periodo di transizione dovranno essere invece assicurati tutti i servizi di gestione e




manutenzione a canone di Area 1 previsti nel Cap. 3, e i servizi di Area 4 previsti nel cap. 6. I servizi di

Area 2 previsti nel cap. 4 dovranno essere, invece, già completati, rilasciati in ambiente di produzione

e consolidati.

5.1. Servizio A3.1: Transizione verso il fornitore/i subentrante/i

I servizi dovranno prevedere sia la casistica in cui, alla conclusione del contratto oggetto della

presente procedura, il soggetto aggiudicatario (o i soggetti aggiudicatari) del/i futuro/i contratto/i, per

ciascun modulo applicativo, gestirà e manuterrà direttamente i sistemi SISaR, sia quella in cui opererà

una sostituzione parziale o totale degli applicativi esistenti con nuovi applicativi. Dovranno pertanto

essere offerti sia servizi di trasferimento di knowledge / competenze sul sistema oggetto del presente

contratto, sia servizi di supporto alla migrazione su nuovi sistemi e recupero dati, con possibilità di

combinare in modo flessibile gli stessi in modo da ottimizzare l’efficacia e massimizzare il risultato in

caso di mix tra le casistiche.

Infatti, dato atto che non è possibile alla data della presente procedura prevedere le modalità con cui

avverrà il subentro dei nuovi fornitori a fine contratto, la presente Area dovrà avere carattere

altamente flessibile, in modo da consentire all’Amministrazione di configurare il servizio nella maniera

più opportuna in funzione delle esigenze che si definiranno in corso di esecuzione del contratto e a

seguito dell’aggiudicazione della/e futura/e procedura/e. L’offerta tecnica dovrà dunque descrivere le

opzioni tra cui l’Amministrazione potrà scegliere, indicando e segmentando il relativo

dimensionamento per singola sotto-attività e singolo sistema, così da permettere in fase esecutiva la

costruzione di un mix chiaro e non ambiguo di servizi e costi, entro il budget fissato, quando saranno

consolidate le condizioni e il quadro attuativo della transizione. Il servizio include la predisposizione

del progetto di migrazione, da avviarsi non appena le suddette condizioni saranno conosciute, che

sarà sottoposto all’approvazione dell’Amministrazione Aggiudicatrice.

Entro le scadenze previste nel cap. 12, l’Aggiudicatario dovrà consegnare un piano per la transizione,

da sottoporre all’approvazione della DEC.

L’impegno dell’aggiudicatario nella fase di transizione sarà variabile in funzione del tipo di subentro

richiesto (con o senza sostituzione del sistema). Nella tabella sottostante sono indicati il numero di

giorni persona che al minimo l’aggiudicatario dovrà erogare per ciascun sistema nel caso in cui tale

sistema sia sostituito (in tal caso l’attività da erogare consisterà nel supporto alla migrazione del

sistema), oppure nel caso in cui il sistema sia mantenuto (in tal caso l’attività da erogare consisterà

nel passaggio delle competenze).

Il totale delle giornate persona che al minimo l’aggiudicatario dovrà quindi erogare è compreso fra 890

(nessun sistema migrato, solo passaggio di competenze sui sistemi esistenti) e 1176 giornate (tutti i

sistemi migrati, nessun passaggio di competenze sui sistemi esistenti).




Sistema Moduli Applicativi

Effort minimi inGG/U per Sistema

per l’attività disupporto alla

Migrazione Dati nelcaso di sostituzione

del Sistema

Effort minimi inGG/U per l’attività diTrasferimento delle

Competenze perciascun sistema in

caso dimantenimento dello

stesso

AMC – Amministrazione eControllo

Contabilità, Acquisti e Contratti, Logistica(Magazzini, Richieste di Approvvigionamento,Armadietto di Reparto), Gestione Attrezzature eManutenzioni / Cespiti

152 120

HR – Risorse UmaneTrattamento Giuridico, Dotazione Organica,Gestione Economica e Contributiva, RilevazionePresenze

174 120

PD – Protocollo, Atti eDocumentale Protocollo Informatico, Atti Amministrativi 20 20

SIO – Ospedaliero

Anagrafe

340 220

ADT e Liste di Attesa

Pronto Soccorso

Order Entry di Prestazioni

Sale Operatorie

EMR – Cartella Clinica (per l’attuale PresidioOspedaliero in cui è in uso)

Prescrizione Elettronica

SIO - TrasfusionaleTrasfusionale

140 90SRC (ex CRCC)

AAP – Attività Assistenziali

CSS

80 80

Consultorio

PUA

ADI

RSA

Protesica

AAP – Attività diPrevenzione

Medicina dello Sport

70 70

Medicina Legale

SPRESAL

SISP

SIAN

CUP – Gestore Risorse Ambulatorio 110 110




CUPWEB

EPI – EpidemiologicoCEDAP

10 10RENCAM

Sistema Integrato delDebito Informativo SIDI 80 50

Totale 1176 890

Nel presente servizio è ricompresa la consegna dei sorgenti aggiornati (relativamente a tutti i sistemi e

moduli e componenti facenti parte del sistema SISaR, e, in ogni caso, per tutti gli eventuali nuovi

moduli sviluppati ad hoc nell’ambito del contratto di cui alla presente procedura), opportunamente

commentati e corredati di tutta la manualistica e la documentazione tecnica, funzionale, diagrammi

UML, test cases, manualistica utente, documentazione architetturale, etc., e in generale di tutto

quanto necessario per assicurare la corretta presa in carico e la gestione e manutenzione autonoma a

regime da parte di uno o più nuovi fornitori. La consegna dovrà avvenire secondo le tempistiche di

dettaglio che saranno concordate con l’Amministrazione e formalizzate nel piano di transizione. In

ogni caso, l’Aggiudicatario è tenuto a consegnare i sorgenti e la documentazione di cui sopra allo

stato finale del sistema nel momento di avvio del processo di migrazione, ossia entro e non oltre 3

mesi dalla conclusione del contratto. Inoltre, la documentazione dovrà essere comunque resa

disponibile almeno 9 mesi prima della conclusione del contratto, al fine di consentirne la verifica da

parte dell’Amministrazione e la messa a disposizione nell’ambito delle nuove procedure di gara, e

dovrà essere sempre aggiornata fino alla consegna finale al nuovo aggiudicatario. È obbligo

dell’Aggiudicatario curare il costante aggiornamento dei sorgenti e della documentazione di cui sopra

durante tutto l’arco contrattuale ed è altresì facoltà dell’Amministrazione richiederne in qualunque

momento della fase esecutiva del contratto la consegna allo stato dell’arte, con almeno 30 giorni di

preavviso.

Dovranno in particolare essere consegnati opportuni documenti e/o schemi che descrivano, allo stato

finale del sistema, in maniera adeguatamente dettagliata, almeno i seguenti elementi:

• l'infrastruttura sia software (linguaggi di programmazione, standard, naming convention,

framework, programmi utilizzati), sia hardware, necessaria al funzionamento del sistema;

• l'architettura delle basi di dati;

• le interfacce di integrazione;

• l'architettura complessiva e di dettaglio del sistema, delle sue componenti e del deployment.

Il servizio deve prevedere almeno:

• 1 mese di formazione in aula a favore dell’eventuale/i nuovo/i fornitore/i




• 2 mesi di training on the job a favore dell’eventuale/i nuovo/i fornitore/i

Dovranno inoltre essere previsti:

• 6 mesi di elapsed per la erogazione del remote training support e/o di webinar.

Il percorso formativo da erogare dovrà essere tarato per un destinatario costituito da profili tecnici che

dovranno essere in grado di:

1. svolgere azioni di configurazione/parametrizzazione delle funzionalità applicative SISaR e

supportare in affiancamento gli utenti delle singole Aziende Sanitarie della Regione Autonoma

della Sardegna nell’uso del sistema;

2. eseguire interventi di modifica ed evoluzione al codice sorgente degli elementi software

applicativi SISaR.

In ragione di tali obiettivi, i percorsi formativi devono essere definiti e rivolti a:

- Specialista di Prodotto per ciascuna area applicativa del SISaR, preposto alla esecuzione

delle azioni di cui al primo punto.

- Analista Programmatore per ciascuna area applicativa del SISaR, preposto alla esecuzione

delle azioni di cui al secondo punto.





riuscirà a garantire gli SLA richiesti e dichiarare eventuali SLA migliorativi (cfr. capitolo 13). Dovrà, in

particolare, essere dettagliato il dimensionamento delle giornate persona da erogare per ciascun

modulo, considerati il dimensionamento minimo sopra riportato, eventuali webinar, FAD, etc..

L’importo contrattuale per il servizio verrà riconosciuto con valore a corpo unitario da rendicontare

secondo Stato d’avanzamento lavori.

6. AREA 4. SERVIZI TRASVERSALI

I servizi specificati in quest’area devono essere erogati per tutta la durata dell’esecuzione del contratto

e riguardano attività di supporto e di accompagnamento finalizzate alla qualità e alla buona riuscita del

progetto.




6.1. Servizio A4.1: Program, Project e Service Management

Il servizio consta nel coordinare e gestire l'erogazione dei servizi delle altre Aree contrattuali,

assicurando la buona e corretta esecuzione degli stessi, nonché nel verificare il rispetto degli accordi

sui livelli di servizio (Service Level Agreement – SLA), presentando report sull’andamento del progetto

e sui livelli di servizio garantiti al Committente, e nel curare in generale il coordinamento contrattuale

con la DEC e il RUP e la comunicazione strategica e di alto livello con l’Amministrazione

Aggiudicatrice.

Nello specifico, ricadono in tale servizio, avente carattere continuativo a canone, le attività di Service /

Project Management dei diversi servizi, quali, a titolo di esempio non esaustivo:

• la gestione dei rapporti e delle comunicazioni con il RUP e con la Direzione dell’Esecuzione;

• la raccolta delle esigenze di alto livello dall’Amministrazione Aggiudicatrice e dalla Direzione

dell’Esecuzione e l’opportuna attivazione delle proprie strutture operative per rispondere ai

fabbisogni;

• il recepimento delle linee guida, degli indirizzi e delle indicazioni contrattuali, esecutive e

strategiche dell’Amministrazione Aggiudicatrice e della Direzione dell’Esecuzione e

l’opportuna implementazione delle stesse all’interno dell’organizzazione dell’aggiudicatario;

• il coordinamento delle risorse professionali impiegate nei diversi team preposti alla erogazione

dei singoli servizi;

• il mantenimento di standard qualitativi elevati nell’erogazione dei servizi in maniera omogenea

e uniforme su tutte le diverse aree e ambiti del progetto;

• l’efficiente ed efficace organizzazione, pianificazione e monitoraggio del lavoro per il

raggiungimento dei risultati e degli obiettivi qualitativi e quantitativi attesi per i servizi e le

attività;

• la redazione e gestione di tutta la documentazione di supporto al governo dei servizi/attività e

della rispettiva rendicontazione economica;

• la gestione amministrativa – contrattuale dei servizi;

• il rilevamento di rischi e criticità di carattere organizzativo e strutturale nell’andamento

gestionale del progetto e l’individuazione tempestiva di appositi correttivi e contromisure;

• la misurazione del raggiungimento degli obiettivi, della soddisfazione del cliente e della

performance aziendale;

• la produzione di opportuna reportistica per il RUP e il DEC per consentire il monitoraggio

dell'andamento del contratto, con adeguata frequenza e in piena trasparenza.




A supporto e completamento del Service / Project Management, è da considerarsi inclusa nel

presente servizio una costante attività di Project Office Management ed Assicurazione di Qualità,

consistente, a titolo di esempio non esaustivo:

• nel garantire la piena aderenza di tutte le fasi e processi dell’esecuzione del contratto agli

standard di qualità concordati con l’Amministrazione aggiudicatrice e la Direzione

dell’Esecuzione (Piano di Qualità del Servizio nel suo complesso) ed al Sistema di Qualità

aziendale;

• nella definizione ed aggiornamento del Piano della Qualità del Servizio nel suo complesso in

accordo con i referenti dell’Amministrazione aggiudicatrice e della Direzione dell’Esecuzione;

• nella gestione della documentazione prodotta nella erogazione dei servizi e delle attività, con

garanzia della rispettiva conformità al Piano di Qualità del Servizio, ovvero alle regole e

procedure di qualità concordate con l’Amministrazione aggiudicatrice e la Direzione

dell’Esecuzione;

• nel servizio redazionale del Portale Intranet di Progetto SISaR;

• nel monitoraggio e controllo dei Service Level Agreement concordati e nella produzione delle

relative statistiche e reportistiche di interesse.

Nel servizio sono comprese le attività di pianificazione degli interventi richiesti nell’ambito dei servizi

oggetto del contratto, con modalità che garantiscano un’ottimale allocazione delle risorse facenti capo

all’Aggiudicatario e che consentano altresì all’Amministrazione aggiudicatrice ed alla Direzione

dell’Esecuzione un corretto monitoraggio della presa in carico della singola tipologia di richiesta di

intervento e del rispettivo esito.





riuscirà a garantire gli SLA richiesti e dichiarare eventuali SLA migliorativi (cfr. capitolo 13). Dovrà

inoltre rappresentare tutti i deliverable che produrrà, evidenziando anche quelli che eventualmente

sono aggiuntivi rispetto a quelli richiesti nel presente capitolato.

Per questi servizi è richiesta una disponibilità temporale minima dalle 09:00 alle 18:00, da lunedì a

venerdì.


erogato sotto forma di canone mensile.




6.2. Servizio A4.2: Formazione e Affiancamento

Il servizio ha l’obiettivo di garantire l’esecuzione di tutte le attività di formazione, avvio, supporto e

affiancamento necessarie per abilitare il pieno e corretto utilizzo da parte degli utenti interessati degli

avviamenti in produzione per eventuali nuovi moduli o funzionalità, dal kick-off fino alla necessaria

formazione vera e propria degli operatori. Sono incluse pertanto tutte le attività di supporto in loco,

consulenza per il change management, presenza di personale specializzato per l’affiancamento degli

utilizzatori, training on the job, organizzazione delle sessioni informative e formative, con relativa

logistica, nonché qualunque altra attività formativa specialistica accessoria che si rendesse necessaria

per il corretto e pieno utilizzo del sistema da parte degli utenti.

Il servizio è a consumo e potrà essere erogato fino ad esaurimento del budget massimo stabilito da

contratto, sulla base delle tariffe per figura professionale offerte e delle giornate effettivamente erogate

ed approvate dalla DEC.

Secondo le scadenze indicate nel cap. 12, l’Aggiudicatario dovrà consegnare un rapporto di dettaglio

sull’utilizzo e consumo delle giornate e del budget.

A discrezione e su richiesta dell’Amministrazione aggiudicatrice, una quota del budget previsto

nell’ambito del presente servizio potrà altresì essere destinato alla realizzazione di eventuali moduli

FAD (formazione a distanza / e-learning) sui sistemi SISaR, che si possano rendere necessari in

ragione di nuove funzionalità rilasciate nell’ambito delle major release dei medesimi; in tale evenienza

l’aggiudicatario provvederà a stimare l’effort necessario per evadere la singola richiesta di

realizzazione di un nuovo modulo FAD, che andrà ad erodere il budget disponibile nell’ambito del

servizio in esame. L’effort per la realizzazione dei moduli FAD dovrà essere approvato dalla DEC e

sarà riconosciuto a seguito di rendicontazione a SAL, nella misura delle giornate persona

effettivamente erogate e autorizzate per la tariffa relativa ai profili professionali utilizzati.

È ricompresa nel presente servizio la rilevazione del livello di soddisfazione degli utenti per quanto

attiene agli interventi a carattere formativo erogati, di qualunque natura essi siano, il tutto attraverso i

migliori strumenti e procedure operative che l’Aggiudicatario dovrà proporre in offerta tecnica, con

produzione di report di sintesi nell’ambito dei SAL. In linea di massima, tale rilevazione, avente come

obiettivo quello di misurare il livello di gradimento da parte degli utenti fruitori del servizio in esame,

dovrà registrare e determinare il grado di soddisfazione medio dell’utenza per gli interventi formativi

almeno come di seguito indicato:

CodiceIndicatore Descrizione Indicatore Descrizione Rilevazione

FOR Grado di soddisfazione A conclusione di ciascunasessione di formazione viene

Aggiornato con verifica trimestrale




medio degli utenti rilevato il grado di soddisfazionemedio dei partecipanti.

Liv. 1 – Scarso

Liv. 2 – Insufficiente

Liv. 3 - Sufficiente

Liv. 4 - Buono

Liv. 5 - Ottimo

AFF Grado di soddisfazionemedio degli utenti

A conclusione di ciascunasessione di affiancamento,viene rilevato il grado disoddisfazione medio degli utentirispetto alla totalità diaffiancamento nel trimestre.

Liv. 1 – Scarso

Liv. 2 – Insufficiente

Liv. 3 - Sufficiente

Liv. 4 - Buono

Liv. 5 - Ottimo

Aggiornato con verifica trimestrale

Detta rilevazione del livello di soddisfazione degli utenti non avrà effetto ai fini della determinazione di

eventuali penali per tale servizio.






concorrente dovrà specificare il numero massimo di giornate persona che potranno essere erogate

mediamente in una stessa giornata lavorativa, per tutto il periodo di durata del contratto.

L’effettivo numero di giornate da erogare sarà determinato dalla tariffa offerta per ciascun profilo

professionale richiesto, fino al tetto massimo costituito dal budget contrattuale disponibile per il

servizio.

Considerata la natura flessibile e il contenuto non stimabile a priori delle attività ricadenti nel presente

servizio e degli obiettivi che questo intende perseguire, esso è da intendersi integralmente “a

consumo”, ovvero remunerato a misura sulla base dell’effort approvato dalla Direzione

dell’Esecuzione del Contratto su proposta dell’aggiudicatario ed effettivamente erogato giustificato con




report attività firmato dall’utente, basato sulle tariffe per figura professionale offerte per le giornate

erogate, fino al raggiungimento del budget massimo di risorse disponibili per il servizio medesimo.

Il servizio dovrà essere garantito nei giorni lavorativi dal Lunedì al Venerdì nella fascia oraria 09:00 –

18:00.

7. PASSAGGIO DI CONSEGNE “IN INGRESSO” E PRESA IN CARICO DALL’ATTUALEGESTORE DEL SISTEMA

Per quanto concerne il passaggio di consegne “in ingresso” all’avvio del contratto, l’aggiudicatario

potrà fruire di un mese di durata di formazione in aula più due mesi di passaggio di consegne\training

on the job, su tutti i sistemi costituenti il SISaR, da parte dell’attuale fornitore del servizio di gestione e

manutenzione di SISaR (Fase 1). Gli oneri del passaggio di consegne lato fornitore uscente sono a

carico dell’Amministrazione Aggiudicatrice nell’ambito del contratto cessante, mentre, lato

aggiudicatario della presente procedura, che riceve ed è beneficiario dei suddetti servizi, non sono

previste remunerazioni, come da cap. 2.1, in quanto non sussiste produzione né erogazione di servizi.

Riassumendo, la pianificazione di massima per il periodo di presa in carico “in entrata” del sistema

prevede:

1 mese di elapsed per la fruizione di formazione in aula

2 mesi di training on the job

Sarà inoltre possibile per l'aggiudicatario avvalersi del supporto del fornitore uscente per rispondere a

dubbi o richieste atte a chiarire e colmare eventuali carenze associate al passaggio di consegne

svolto, che si dovessero manifestare entro 6 mesi dal completamento delle attività di formazione e

training on the job e in ogni caso prima che vengano rilasciate in produzione sul modulo contestato

nuove evoluzioni e modifiche da parte dell'aggiudicatario.

Al fine di coordinare l’attività del passaggio di consegne l’aggiudicatario dovrà concordare con la

Direzione dell’Esecuzione del Contratto la formazione e il training attraverso la redazione della

seguente documentazione, con il dettaglio del personale che parteciperà alle sessioni di formazione:

Piano della presa in carico

Di seguito si riporta, per ciascun Applicativo, il numero di giornate che il fornitore uscente è tenuto ad

erogare all’aggiudicatario nei primi 3 mesi di transizione.

Area Tematica/Sistema ModuliEffort in GG/U x

Trasferimento delleCompetenze




AMC – Amministrazione e Controllo

Contabilità, Acquisti e Contratti, Logistica (Magazzini,Richieste di Approvvigionamento, Armadietto diReparto), Gestione Attrezzature e Manutenzioni /Cespiti

120

HR – Risorse Umane Trattamento Giuridico, Dotazione Organica, GestioneEconomica e Contributiva, Rilevazione Presenze 120

PD – Protocollo, Atti e Documentale Protocollo Informatico, Atti Amministrativi 20

SIO – Ospedaliero

Anagrafe

220

ADT e Liste di Attesa

Pronto Soccorso

Order Entry di Prestazioni

Sale Operatorie

EMR – Cartella Clinica (per l’attuale PresidioOspedaliero in cui è in uso)

Prescrizione Elettronica

SIO - TrasfusionaleTrasfusionale

90SRC (ex CRCC)

AAP – Attività Assistenziali

Consultorio

80

PUA

ADI

RSA

Protesica

AAP – Attività di Prevenzione

Medicina dello Sport

70

Medicina Legale

SPRESAL

SISP

SIAN

Portale Amianto e NPC WEB

CUP – Gestore RisorseAmbulatorio

110CUPWEB

EPI – EpidemiologicoCEDAP

10RENCAM

Sistema Integrato del DebitoInformativo SIDI 50

Totale 890

Tabella Giornate di formazione erogate dall’attuale fornitore nel periodo di transizione

Il quantitativo di 890 giornate di cui sopra, da erogarsi a carico dell’attuale fornitore, potrà essere

incrementato fino ad un massimo di 1048 giornate in caso di necessità straordinarie motivate ed




approvate dalla DEC, a seconda delle esigenze manifestate dall’aggiudicatario della presente

procedura.

Gli aspetti di integrazione, anche quelli effettuati attraverso l’integratore SpagiC, sono trattati

nell’ambito della formazione sui singoli sistemi interessati dalle integrazioni.

I percorsi formativi che potranno essere oggetto di erogazione sono orientati a formare profili

professionali tecnici sul sistema SISaR che siano in grado di:

1. svolgere azioni di configurazione/parametrizzazione delle funzionalità applicative SISaR e

affiancare gli utenti regionali e delle singole Aziende Sanitarie della Regione nel rispettivo uso;

2. eseguire interventi di modifica ed evoluzione al codice sorgente degli elementi software

applicativi SISaR, ivi incluse le componenti software sviluppate ad hoc e le integrazioni con

sistemi terzi.

I tecnici dell’aggiudicatario che potranno ricevere la formazione dovranno avere al minimo i seguenti

profili professionali:

Specialista di Prodotto per ciascuna area applicativa del SISaR, preposto alla esecuzione

delle azioni di cui al punto 1.

Analista Programmatore per ciascuna area applicativa del SISaR, preposto alla esecuzione

delle azioni di cui al punto 2.

Affinché le azioni di trasferimento delle competenze oggetto dei percorsi formativi possano essere

efficaci, è necessario che il personale discente allo scopo selezionato dall’aggiudicatario sia in

possesso di determinate conoscenze e competenze di dominio e tecnico-informatiche all’ingresso,

che costituiscono i prerequisiti che dovranno essere da questo soddisfatti, ovvero:

personale discente partecipante al percorso di Specialista di Prodotto SISaR: deve possedere

approfondita competenza di dominio ed esperienza almeno settennale sui temi funzionali su

cui deve operare, ovvero:

o Contabilità Economico Patrimoniale, Cespiti/Patrimonio, Acquisti e Magazzino in

ambito pubblico, nel caso debba operare nell’area applicativa SISaR Sistema

Informativo Amministrativo Contabile – AMC;

o Gestione delle Risorse Umane in ambito pubblico, nel caso debba operare nell’area

applicativa SISaR Sistema Informativo del Personale - HR;

o Protocollo ed Atti Amministrativi, nel caso debba operare nelle aree applicative SISaR

dei Sistemi di Protocollo Informatico, Atti Amministrativi e Documentale;

o Processi e Sistemi di Gestione delle Prenotazioni di Prestazioni Sanitarie in ambito

pubblico, nel caso debba operare nell’area applicativa SISaR CUP ed Ambulatoriale;




o Processi e Sistemi Clinico-Ospedalieri in ambito pubblico (ADT, Pronto Soccorso,

Sale Operatorie, Order Entry, Trasfusionale, etc …), nel caso debba operare nell’area

applicativa SISaR Sistema Informativo Ospedaliero;

o Processi e Sistemi delle Attività Assistenziali e di Prevenzione sul territorio in ambito

pubblico (Punto Unico di Accesso, Assistenza Domiciliare, Consultorio, Protesica,

RSA, Dipartimento di Prevenzione, etc …), nel caso debba operare nell’area

applicativa SISaR Sistema Informativo delle Attività Assistenziali e di Prevenzione;

o Processi e Sistemi di Governo, quali Datawarehuosing, Business Intelligence e Flussi

del Debito Informativo in ambito sanità pubblica, nel caso debba operare nelle aree

applicative SISaR Sistema integrato del debito informativo – SIDI, Sistema

Informativo Direzionale ed Epidemiologico.

Le risorse devono preferibilmente possedere una laurea pertinente rispetto alle materie

oggetto dell’apprendimento, in particolare con riferimento alle materie economiche o tecnico-

scientifiche, in quest’ultimo caso affini all’ambito IT; le risorse devono inoltre possedere

approfondita conoscenza di database relazionali (in particolare Oracle), essere in grado di

effettuare query anche complesse su database, essere in grado di realizzare procedure di

scripting per la esecuzione di elaborazioni e task complessi su database (es. PL/SQL), etc.;

devono inoltre possedere conoscenze di architetture web-based basate su tecnologia Java –

J2EE nonché dei più comuni application server Java – J2EE (es. Tomcat, JBoss, ecc …);

personale discente partecipante al percorso di Analista Programmatore SISaR: deve

possedere una approfondita competenza ed esperienza almeno settennale nello sviluppo di

applicazioni basate su architetture web-based ed in tecnologia Java – J2EE nei domini

funzionali del SISaR – identificati secondo la medesima classificazione anzi effettuata per i

discenti del percorso di Specialista di Prodotto (es. Contabilità, Personale, ecc …); le risorse

devono avere competenze sui più comuni application server Java – J2EE (es. Tomcat, JBoss,

ecc …), nonché nella progettazione, realizzazione e tuning di database relazionali basati su

Oracle (ultime versioni disponibili); devono essere in grado di effettuare azioni di installazione,

configurazione, monitoraggio e tuning avanzate sia a livello di database che di application

server, intervenendo su tali elementi per risolvere eventuali anomalie / malfunzionamenti

applicativi; devono possedere una laurea in materie tecnico-scientifiche, in ambito IT, con

attestazioni / qualificazioni rilasciate a fronte della partecipazione a corsi di formazione

specifici su linguaggi e/o ambienti di programmazione / database / application server.




8. ASPETTI RELATIVI AL GDPR E TRATTAMENTO DEI DATI PERSONALI

L’aggiudicatario dovrà erogare i servizi oggetto della presente procedura nel rispetto della normativa

nazionale e comunitaria vigente in materia di trattamento dei dati personali, e in particolare del

Regolamento U.E. 27 aprile 2016 n.679 - General Data Protection Regulation (nel seguito GDPR).

Come già rappresentato, si precisa che, alla data attuale, sono in corso o sono programmati sul

sistema SISaR, nell’ambito del contratto cessante attualmente vigente, alcuni interventi necessari per

l’adeguamento al GDPR, con particolare riferimento alle misure di sicurezza minime infrastrutturali di

cui all'art. 32, comma 1, dello stesso. In particolare, si prevede che le azioni in corso consentiranno di

consegnare all'aggiudicatario della presente procedura un sistema adeguato sotto i seguenti aspetti:

- Cifratura della base dati a livello di datafile, con impossibilità di lettura delle informazioni

sensibili direttamente dallo storage a livello di sistema operativo, dispositivi di archiviazione,

dispositivi di backup e file di esportazione e visibilità dei dati solo alle modalità di accesso

“autorizzate”.

- Controllo dell’accesso alla base dati attraverso un iter di profilatura di regole, di ruoli e privilegi

da assegnare alle utenze.

- Monitoraggio e tracciatura delle attività del database.

- Disponibilità di strumenti per la gestione, parametrizzazione e configurazione delle interfacce

applicative atti a consentire l'applicazione delle modalità di trattamento stabilite dai diversi

Titolari del Trattamento nonché gli adempimenti in materia di accountability tramite opportuno

log degli eventi di interesse.

Qualora, all’avvio e nel corso dell'esecuzione del contratto, emergano ulteriori necessità di

adeguamento del sistema consegnato, queste saranno richieste, gestite, rendicontate e riconosciute

economicamente nell'ambito del servizio di manutenzione evolutiva a consumo di cui al cap. 3.3.

Nel corso del contratto, potranno essere effettuate da parte dei Titolari una o più valutazioni d'impatto

sulla protezione dei dati ai sensi dell’art. 35 del GDPR, anche sulla base delle misure di garanzia che

saranno emanate ai sensi e per gli effetti dell’art. 2-septies D.lgs 196/2003 e ss.mm.ii., e delle misure

e accorgimenti a garanzia ex art. 2-quinquiesdecies D.lgs 196/2003 e ss.mm.ii., a seguito delle quali

potranno essere individuate nuove misure, da implementarsi a cura dell'aggiudicatario.

L’aggiudicatario è tenuto ad assicurare ai Titolari la disponibilità di tutte le informazioni necessarie per

le attività connesse al GDPR e la massima collaborazione al fine di agevolarne l’esecuzione.

L’aggiudicatario è in ogni caso tenuto, nell’esecuzione del contratto, a procedere in coerenza con tutti

gli adempimenti previsti dalla normativa vigente in materia di trattamento dei dati personali, senza

oneri ulteriori per il Committente, per tutta la nuova produzione di propria competenza ed in generale




per tutte le attività e i servizi, effettuati nell'ambito dell'appalto, che introducano nuovi trattamenti o

comportino impatti sui trattamenti esistenti.

A seguito della stipula del contratto, l’aggiudicatario sarà nominato Responsabile del Trattamento, ai

sensi dell’art. 28 del GDPR, dai diversi Titolari del Trattamento, mediante appositi Data Protection

Agreement specifici per Titolare e per i rispettivi trattamenti di competenza svolti nell’erogazione dei

servizi previsti dal contratto. Attualmente, i Titolari dei diversi trattamenti oggetto dei servizi SISaR

sono i seguenti, ognuno per la propria area di competenza che sarà specificata in sede di nomina a

Responsabile:

Regione Autonoma della Sardegna

Azienda per la Tutela della Salute (ATS)

Azienda Ospedaliera “G. Brotzu”

Azienda Ospedaliera Universitaria di Cagliari

Azienda Ospedaliera Universitaria di Sassari

Azienda Regionale per l’Emergenza Urgenza della Sardegna (AREUS)

L’elenco dei Titolari potrà variare in corso di esecuzione del contratto a seguito, per esempio,

dell’introduzione di nuove funzionalità, di variazioni di legge o di riforme all’assetto organizzativo del

Servizio Sanitario Regionale. Le indicazioni di dettaglio sui trattamenti e sulle responsabilità

dell’aggiudicatario in relazione all'incarico di Responsabile saranno comunicate dai rispettivi Titolari in

sede di nomina. Il formato dei Data Protection Agreement sarà stabilito dai rispettivi Titolari secondo

gli schemi standard in uso presso le rispettive organizzazioni.

A mero titolo esemplificativo, tra la documentazione allegata alla presente procedura è riportato lo

schema dell’accordo esistente tra la Regione Autonoma della Sardegna in qualità di Titolare e l’attuale

fornitore (rif. Allegato 9 - Schema di accordo per il trattamento dei dati personali ex art. 28 del

Regolamento UE 679_2016). Tale schema sarà oggetto di rielaborazione congiunta in sede di stipula

del contratto con l’Aggiudicatario della presente procedura.

9. ORGANIZZAZIONE DI PROGETTO

L’aggiudicatario dovrà erogare i servizi oggetto del contratto mediante un’organizzazione adeguata

alla complessità ed alle dimensioni del progetto. In particolare, dovrà essere garantita, in fase di

esecuzione e per tutta la durata del contratto, almeno la presenza dei seguenti profili professionali:

Contract manager: è il rappresentante apicale dell’Aggiudicatario verso la Stazione

Appaltante, responsabile della corretta gestione ed esecuzione del contratto. Si occupa di tutti

gli aspetti contrattuali ed amministrativi. È richiesto un diploma di laurea rilasciato secondo il




vecchio ordinamento, ovvero laurea specialistica o magistrale o laurea triennale in ingegneria,

informatica, matematica, fisica o discipline equipollenti, rilasciate in attuazione del D.M.

n.509/99 o del D.M. 270/04, ed una esperienza in campo ICT di almeno 15 anni negli ultimi

20, di cui almeno 10 nella gestione di contratti ICT con ruoli apicali. L’organizzazione di

progetto dell’Aggiudicatario dovrà prevedere un unico contract manager.

Program manager: è il responsabile apicale dell’aggiudicatario per l’esecuzione tecnica del

contratto. Costituisce il riferimento organizzativo di vertice in rappresentanza

dell’aggiudicatario per la gestione degli aspetti tecnici ed è responsabile della buona e corretta

erogazione dei servizi. Per questa figura è richiesto un diploma di laurea rilasciato secondo il



n.509/99 o del D.M. 270/04, una certificazione in Project Management ottenuta almeno da 5

anni, un’esperienza di almeno 15 anni negli ultimi 20, nella gestione di progetti in campo ICT

col ruolo di Project manager. L’organizzazione di progetto dell’Aggiudicatario dovrà prevedere

un unico program manager.

Responsabile della qualità: è il referente per la qualità dei servizi erogati ed è colui che

monitora e governa gli standard qualitativi delle attività e dei livelli di servizio, in

coordinamento con il program manager, i project manager e il service manager. Per questa

figura è richiesta un’esperienza lavorativa, con profilo manageriale, nel campo della qualità

nel settore sistemi informativi di almeno 10 anni negli ultimi 12. L’organizzazione di progetto

dell’Aggiudicatario dovrà prevedere un unico Responsabile della qualità.

Service manager, uno per ciascun servizio richiesto: i Service manager sono i responsabili

operativi dei singoli servizi oggetto del contratto e si occupano del coordinamento del team di

lavoro dedicato al servizio specifico ai fini della corretta erogazione dello stesso. Ciascun

Service manager è responsabile inoltre del rispetto degli SLA del servizio di cui è referente.

Per questa figura è richiesto un diploma di laurea rilasciato secondo il vecchio ordinamento,

ovvero laurea specialistica o magistrale o laurea triennale in ingegneria, informatica,

matematica, fisica o discipline equipollenti, rilasciate in attuazione del D.M. n.509/99 o del

D.M. 270/04, esperienza in campo ICT di almeno 10 anni negli ultimi 12, di cui almeno 8 nella

gestione di servizi software, con ruoli di coordinamento. L’organizzazione di progetto

dell’Aggiudicatario dovrà prevedere un Service Manager per ogni servizio, per un totale quindi

di N. 8 service manager distinti. In particolare, i servizi (alcuni accoppiati) che dovranno avere

uno specifico Service manager distinto assegnato sono i seguenti:

o Servizio A1.1: Manutenzione Preventiva, Adeguativa, Correttiva, Perfettiva

o Servizio A1.2: Miglioramento delle performance e dell’usabilità

o Servizio A1.3: Manutenzione Evolutiva e Servizio A2.2: Evoluzione e migrazione su

nuova infrastruttura e disaccoppiamento funzionale




o Servizio A1.4: Servizi Specialistico-Applicativi

o Servizio A1.5: Gestione degli ambienti applicativi di test e di produzione

o Servizio A1.6: Gestione sistemistico-applicativa e Servizio A1.8: Reperibilità H24

mission critical

o Servizio A1.7: Servizio di Help Desk

o Servizio A3.1: Transizione verso il fornitore subentrante e Servizio A4.2: Formazione

e Affiancamento

Per il Servizio A4.1: Service e Project Management, il ruolo di service manager dovrà

essere ricoperto dal Program Manager.

Project Manager\Responsabili singolo sistema SISaR, uno per ciascuna area tematica di cui è

composto il SISaR: è il responsabile del componente tematico (sistema) e quindi del team di

specialisti di prodotto di quel sistema. Segue direttamente le attività relative alle evoluzioni

delle singole aree. È richiesto un diploma di laurea rilasciato secondo il vecchio ordinamento,

ovvero laurea specialistica o magistrale o laurea triennale in ingegneria, informatica,

matematica, fisica o discipline equipollenti, rilasciate in attuazione del D.M. n.509/99 o del

D.M. 270/04, esperienza in campo ICT di almeno 10 anni negli ultimi 12, di cui almeno 8 nella

gestione di progetti col ruolo di Project manager. L’organizzazione di progetto

dell’Aggiudicatario dovrà prevedere un Project Manager per ciascun sistema, per un totale di

7 Responsabili di sistema. I sistemi considerati sono i seguenti:

o AAP - Sistema Attività assistenziali e della prevenzione

o SIO - Sistema Informativo Ospedaliero

o AMC-HR-PROT - Sistema Amministrativo

o CUP-AMB-EPRE –Sistemi CUP, ambulatoriale, e-prescription

o DIR-EPI - Sistema Direzionale ed Epidemiologico

o SIDI - Sistema Integrato Debito Informativo

o INFRA – Sistema infrastrutturale

Consulenti Organizzativi di Prodotto\Dominio, almeno uno per ciascun sistema: sono

consulenti di altro profilo che si occupano di supportare dal punto di vista organizzativo

l’introduzione e\o le modifiche su un componente software all’interno dell’organizzazione,

tenendo conto in particolare degli impatti di change management sull’organizzazione stessa.

Per questa figura sono richiesti almeno 8 anni, negli ultimi 12, di comprovata esperienza in

consulenza organizzativa. L’organizzazione di progetto dell’Aggiudicatario dovrà prevedere

almeno 1 consulente di dominio\prodotto per ogni sistema di cui all’elenco del punto

precedente, per un totale minimo quindi di 7 risorse.

Specialisti di prodotto per ciascun componente (moduli SISaR di cui all’elenco contenuto nel

cap. 1.1): sono gli operatori che erogano operativamente i servizi richiesti su ciascun modulo




di cui è composto il SISaR, nel rispetto dei livelli di servizio specificati nella presente

procedura. È richiesta un’esperienza lavorativa in campo ICT di almeno 8 anni negli ultimi 10,

di cui almeno 5 nello specifico ambito di assegnazione (con riferimento ai sistemi

precedentemente elencati). L’organizzazione di progetto dell’Aggiudicatario dovrà prevedere

almeno 2 specialisti di prodotto per ciascun componente. È consentito che, compatibilmente

con il carico di lavoro conseguente e in relazione alle dimensioni e alla complessità del

singolo modulo, uno stesso specialista possa essere assegnato contemporaneamente a più di

un componente. Il concorrente dovrà a tale proposito giustificare in offerta come intende

organizzare il team degli specialisti e giustificare le proprie scelte quantitative e qualitative, in

modo da assicurare un servizio efficiente ed efficace, anche alla luce della necessaria alta

capacità di parallelizzazione delle attività. Tali aspetti saranno altresì attentamente monitorati

in fase di esecuzione del contratto.

Sistemisti e DBA Senior: sono gli operatori che erogano i servizi tecnici, infrastrutturali e di

monitoraggio, necessari per garantire le performance e la continuità del servizio. È richiesta

una esperienza in campo ICT di almeno 8 anni negli ultimi 10, di cui almeno 5 nella gestione

di sistemi/DB. L’organizzazione di progetto dell’Aggiudicatario dovrà prevedere almeno 3

sistemisti e 3 DBA di livello senior per entrambi i profili e comunque in sede di offerta tecnica

dovrà giustificare in offerta come intende organizzare il team dei sistemisti e giustificare le

proprie scelte quantitative e qualitative, in modo da assicurare un servizio efficiente ed

efficace,

User experience architect: è responsabile del design e della user experience, e in generale di

tutti gli aspetti relativi alla soddisfazione dell’utente. Questa figura cura il miglioramento

dell'usabilità, della facilità d'uso e dell’esperienza nell'interazione tra il cliente e il prodotto. È

richiesto un diploma di laurea rilasciato secondo il vecchio ordinamento, ovvero laurea

specialistica o magistrale o laurea triennale in ingegneria, informatica, matematica, fisica o

discipline equipollenti, rilasciate in attuazione del D.M. n.509/99 o del D.M. 270/04. Inoltre, si

richiedono almeno 8 anni, negli ultimi 10, di esperienze professionali nell’ambito ICT di cui

almeno 5 anni di esperienze direttamente pertinenti al ruolo richiesto nel progetto.

L’organizzazione di progetto dell’Aggiudicatario dovrà prevedere almeno 3 user experience

architect e comunque in sede di offerta tecnica dovrà giustificare in offerta come intende

organizzare il team degli user experience architect e giustificare le proprie scelte quantitative

e qualitative, in modo da assicurare un servizio efficiente ed efficace.

Analisti Programmatori: sono gli operatori che lavorano in tutta la filiera produttiva degli

sviluppi software per l’evoluzione e manutenzione del sistema SISaR e svolgono attività di

analisi, programmazione e testing. Per questa figura è richiesto almeno un diploma di scuola

media secondaria. Si richiedono almeno 8 anni, negli ultimi 10, di esperienze professionali

nell’ambito ICT di cui almeno 5 anni di esperienze direttamente pertinenti al ruolo richiesto nel




progetto. Il numero di risorse per questo profilo non è fissabile a priori in sede di capitolato, in

quanto dipendente dalle metodologie proposte dal concorrente e dalla propria organizzazione

aziendale, e dovrà essere specificato nell’offerta tecnica.

Architetti\Progettisti software: sono gli operatori che lavorano in tutta la filiera produttiva degli

sviluppi software per l’evoluzione e manutenzione del sistema SISaR e svolgono l’attività di

progettazione di componenti e sistemi. È richiesto un diploma di laurea rilasciato secondo il



n.509/99 o del D.M. 270/04. Inoltre, si richiedono almeno 8 anni, negli ultimi 10, di esperienze

professionali nell’ambito ICT di cui almeno 5 anni di esperienze direttamente pertinenti al

profilo. Il numero di risorse per questo profilo non è fissabile a priori in sede di capitolato, in

quanto dipendente dalle metodologie proposte dal concorrente e dalla propria organizzazione


Service Desk Specialists: sono gli operatori di help desk. Si richiede comprovata esperienza

in attività di supporto telefonico agli utenti per servizi IT, con almeno 4 anni, negli ultimi 10, di

esperienza già maturata nell’assistenza in ambiti attinenti alle materie della procedura. Il

numero di risorse per questo profilo non è fissabile a priori in sede di capitolato, in quanto

dipendente dalle metodologie proposte dal concorrente e dalla propria organizzazione


L’Amministrazione si riserva la facoltà di richiedere all’Aggiudicatario la sostituzione del personale

messo a disposizione per lo svolgimento del presente progetto ove rilevasse, anche su segnalazione

della DEC, il non rispetto dei requisiti richiesti. Le sostituzioni richieste costituiranno elemento di

valutazione dello SLA PRG17.

La localizzazione operativa di lavoro è tutto il territorio della Regione Sardegna. I centri principali

presso cui dovranno essere erogati servizi in presenza sono le sedi centrali e periferiche dei seguenti

soggetti:

Regione Autonoma della Sardegna (Assessorato dell’Igiene e Sanità e dell’Assistenza Sociale

e Centro Servizi Regionale - CSR)

Società in house SardegnaIT

Azienda per la Tutela della Salute (ATS)

Azienda Ospedaliera “G. Brotzu”

Azienda Ospedaliera Universitaria di Cagliari

Azienda Ospedaliera Universitaria di Sassari

Azienda Regionale per l’Emergenza Urgenza della Sardegna (AREUS)




L’Assessorato dell’Igiene e Sanità e dell’Assistenza Sociale – Direzione Generale della Sanità è

l’unico soggetto responsabile dell’indirizzo, governo e controllo strategico del progetto. Il Direttore del

Servizio sistema informativo, affari legali e istituzionali è il Responsabile Unico del Procedimento

(RUP) per la fase esecutiva. La Direzione dell’Esecuzione del Contratto (DEC) sarà affidata alla

società in house SardegnaIT. L’ATS con le proprie ASSL, le Aziende Ospedaliere e l’AREUS sono i

principali stakeholders beneficiari/utenti del progetto, ma non sono investiti di alcun ruolo contrattuale

o di qualsivoglia posizione formale rispetto agli organi per legge deputati al governo del contratto,

RUP e DEC, che sono pertanto gli unici soggetti autorizzati a dare disposizioni all’Aggiudicatario in

relazione al contratto stesso. All’avvio della Fase 2 del contratto saranno, se necessario, ulteriormente

precisate all’Aggiudicatario le procedure dettagliate di ingaggio per i servizi che comportano

un’attivazione su input del committente (referenti autorizzati ad attivare i servizi e processi per la

richiesta e il controllo degli stessi).

10. Strumenti di supporto

Gli strumenti di supporto attualmente utilizzati per la gestione dei servizi sono:

• il sistema SIPWEB o ALM Atlassian Jira per il tracciamento delle anomalie e delle richieste di

assistenza al servizio di Help Desk;

• ALM (Application Lifecycle Management) Atlassian Jira per il tracciamento delle richieste e di

intervento specialistico, per la manutenzione e supporto specialistico e altre richieste ed

interventi.

• un portale documentale intranet dedicato, in cui tutta la documentazione SISaR è archiviata e

resa disponibile agli utenti abilitati.

Il portale della documentazione è installato presso il Centro Servizi Regionale, è di piena proprietà

della Regione e la gestione e manutenzione dello stesso è in capo al fornitore SISaR. Esso è pertanto

oggetto di presa in carico e di erogazione dei servizi previsti nell’ambito del presente appalto. È

obbligo dell’aggiudicatario assicurare il caricamento sul portale di tutta la documentazione di progetto,

incrementata con i nuovi documenti necessari e aggiornata costantemente allo stato dell’arte per tutta

la fase di esecuzione del contratto. I deliverable dei SAL dovranno essere caricati puntualmente sul

portale documentale. Il portale documentale, per cui è disponibile apposito manuale d’uso, è basato

sullo strumento Microsoft Sharepoint.

Il sistema Jira è opensource, ma è necessario che l’aggiudicatario utilizzi una propria installazione o

metta a disposizione un sistema equivalente (sempre open source). In alternativa, SardegnaIT potrà

configurarne una apposita. Si precisa che, per quanto concerne il sistema Jira, non vi sarà passaggio

di consegne da parte del fornitore uscente, in quanto, come sopra indicato, dovrà essere fornita

un’installazione ex novo nell’ambito del presente appalto.




Il sistema SIPWEB è uno strumento interno del fornitore uscente, non facente parte del parco sistemi

SISaR di proprietà della Regione. Pertanto, tale sistema non sarà oggetto di passaggio di consegne, il

suo utilizzo cesserà con la conclusione del contratto precedente e l’aggiudicatario dovrà sostituirlo con

il sistema Jira (o con sistema equivalente, come sopra), preferibile per maggiore omogeneità con gli

strumenti attualmente utilizzati, o con altro sistema equivalente di trouble ticketing (sempre open

source).

Considerata la natura accessoria e di supporto, i costi correlati alla fornitura, installazione,

configurazione e gestione dei sistemi di cui sopra sono da intendersi inclusi negli oneri dei servizi di

Area 1 e non è pertanto associata agli stessi una valorizzazione specifica e separata. Le relative

installazioni e i dati in esse contenuti sono soggetti alla disciplina in tema di proprietà di cui al cap. 15.

Per quanto attiene alle attività di manutenzione (evolutiva, normativa, perfettiva, adattativa, preventiva,

etc.) Jira dovrà essere configurato in maniera tale che l’aggiudicatario compili al minimo i seguenti

campi:

• Codice Richiesta

• Tipo Richiesta (Manutenzione evolutiva, perfettiva, normativa, preventiva, supporto

specialistico, etc)

• Descrizione breve Richiesta

• Descrizione lunga Richiesta

• Fase Richiesta

• Stato Richiesta

• Priorità Richiesta

• Data aggiornamento

• Data chiusura CR

• Struttura Assegnataria dell’Aggiudicatario

• Nome risorsa dell’aggiudicatario che ha preso in carico la richiesta

• E-mail della risorsa dell’aggiudicatario che ha preso in carico la richiesta

• Ente Richiedente

• E-mail del Richiedente

• Ruolo del richiedente




• Data segnalazione richiesta

• Data creazione record sul sistema Jira

• Data presa in carico

• Data rilascio Analisi Funzionale

• Data Approvazione Analisi Funzionale

• Data invio quantificazione economica da parte dell’aggiudicatario

• Data approvazione quantificazione economica

• Data invio piano di rilascio in produzione alla DEC

• Data prevista di rilascio in produzione

• Data effettiva di rilascio in produzione

• Sistema\Modulo software SISaR interessato

• Tempo intercorrente fra la data di presa in carico e la data di segnalazione della richiesta

(calcolato automaticamente)

• Tempo intercorrente fra la data di invio dell’analisi funzionale e la data di presa in carico

(calcolato automaticamente)

• Tempo intercorrente fra la data di invio della proposta di quantificazione economica e la data

di approvazione dell’analisi funzionale (calcolato automaticamente)

• Tempo intercorrente fra la data di invio del piano di rilascio e la data di approvazione della

quantificazione economica (calcolato automaticamente)

• Tempo intercorrente fra la data effettiva di rilascio in produzione e la data prevista di rilascio in

produzione (calcolato automaticamente)

L’aggiudicatario è tenuto a prendere in carico e gestire correttamente gli strumenti di cui sopra. Tutti

gli utenti e operatori abilitati del sistema SISaR, afferenti sia al SSR che alla Regione, sono in

possesso di una utenza per la segnalazione delle anomalie del software o per richieste di assistenza.

Il fornitore dovrà gestire correttamente gli account di tutti gli utenti che possono accedere ai sistemi di

supporto.

Come già rappresentato, l’aggiudicatario potrà eventualmente proporre la sostituzione degli strumenti

con altri o l’aggiunta di nuovi strumenti, ed in tal caso eventuali costi di licenza e di formazione o

manualistica, nonché l’obbligatoria migrazione di tutto il dato storico e del pregresso, saranno a carico

dell’aggiudicatario stesso. Tale opzione, risultando indifferente dal punto di vista dei servizi oggetto del




contratto e del valore aggiunto per l’Amministrazione, non costituisce oggetto di punteggio in sede di

valutazione dell’offerta ai fini dell’aggiudicazione della presente procedura di gara.

11. DELIVERABLES

I deliverable minimi da produrre nell’esecuzione del contratto sono elencati, per ciascun servizio, nella

seguente tabella. L’elenco è indicativo e non esaustivo, e potrà subire variazioni in corso di

esecuzione sulla base delle esigenze dell’Amministrazione.

Servizio DeliverableAREA 1 - Gestione

Manutenzione correttiva

Registro Manutenzione CorrettivaDocumentazione tecnica di analisi e design, note Operative e manuali utenteaggiornatiCheck List e Verbale di Installazione Ambiente di Test

Check List e Verbale di Installazione Ambiente di Produzione

Piano dei Test/Rapporto Esecuzione Test

No-regression Test

Manutenzione preventiva

Piano della manutenzione preventiva e aggiornamento trimestrale dello stesso


Note Operative e manuali utente aggiornati

Check List e Verbale di Installazione Ambiente di Test

Check List e Verbale di Installazione Ambiente di ProduzioneDocumentazione tecnica (sia funzionale che architetturale), manualistica, diagrammiUML, User Exeperience Design

Manutenzione adeguativa e adattativa

Piano della manutenzione adeguativa e adattativa con paragrafo distinto dedicatoalla manutenzione ordinaria per adeguamenti normativi e aggiornamento trimestraledello stessoPiano dei Test/Rapporto Esecuzione Test



Check List e Verbale di Installazione Ambiente di ProduzioneDocumentazione tecnica (sia funzionale che architetturale), manualistica, diagrammiUML, User Exeperience DesignIn particolare, per gli adeguamenti normativi ordinari:- Registrazione dell’esigenza sul sistema di tracciamento sul sistema di TT.- Documento di analisi.- Applicazione delle linee guida usabilità.- Valutazione economica.- Aggiornamento della documentazione tecnica di analisi e progettazione e dei

relativi elaborati UML, BPMN, etc- Pianificazione attività.- Eventuale aggiornamento del piano di lavoro- Produzione piano dei Test, unit testing, integration testing, system testing,

regression testing- Tracciamento dei test effettuati- Test in ambiente di test SISaR, regression testing- Rilascio della patch in produzione- Verifiche di funzionamento in ambiente di produzione- Registrazione dei documenti attestanti l’attività sul portale documentazione




Manutenzione perfettiva

Piano della manutenzione perfettiva e aggiornamento trimestrale dello stesso

Piano dei Test/Rapporto Esecuzione Test/Risultati code inspection



Check List e Verbale di Installazione Ambiente di ProduzioneDocumentazione tecnica (sia funzionale che architetturale), manualistica, diagrammiUML, User Exeperience Design

Manutenzione evolutiva

Piano della manutenzione evolutiva e aggiornamento mensile dello stessoPer ciascuna CR:- Documento d’analisi- Piano di sviluppo con descrizione delle iterazioni, cronoprogramma equantificazione economica- Software sviluppato- Piano dei test\No regression test\Test di integrazione\Risultato dei test- Rilascio- Documentazione tecnica a corredo del software: design del software(UML), user experience design, manualistica utente, piano dei test, report dei testeffettuatiCheck List e Verbale di Installazione Ambiente di Test



Miglioramento delle performance edell’usabilità

Piano per il miglioramento delle performance e della user experience eaggiornamento trimestrale dello stessoGantt complessivo con mappatura delle risorse impiegate per profilo professionaleutilizzato aggiornatoCheck List e Verbale di Installazione Ambiente di Test


Piano dei Test/No regression Test/Rapporto Esecuzione Test

Note Operative e manuali utente aggiornatiAnalisi Funzionale/Analisi dei requisiti/Specifica architetturale delle soluzionisw/Diagrammi UML, User Experience Design

Servizi Specialistico-Applicativi Report segnalazioni registrate su JIRA> Relazione sullo Stato Avanzamento Lavori

Gestione dell’Ambiente Applicativo diTest



No-regression Test

Gestione dell’Ambiente Applicativo diProduzione


Note Operative e manuali utente (applicativi e amministrazione) aggiornati

Verbale verifiche effettuate in ambiente di produzione

Gestione Sistemistico-Applicativa

Produzione mensile dei report di dettaglio (da definirsi con l’AmministrazioneAggiudicatrice) su tutte le integrazioni che insistono sull’integratore SpagiC\nuovointegratore ESB: Conteggio dei messaggi, per tipologia e destinatario, trasmessi con esito

positivo (ACK OK), senza ACK e in errore (ACK KO) Conteggio dei messaggi, per tipologia e sistema sorgente, ricevuti con esito

positivo (ACK OK) e in errore (ACK KO)Individuazione dei sistemi sorgente per i quali i messaggi ricevuti risultano in numeroinferiore a quanto atteso (soglia da definirsi in base alla media)Relazioni mensili sulle verifiche di qualità eseguite su moduli, integrazioni eaggiornamento dei dati del Direzionale.

Servizio di Help Desk Report segnalazioni registrate sul sistema di trouble ticketing, all’interno dei rapportibimestrali sui servizi erogati

Servizio di Reperibilità H24 Mission-Critical

Report segnalazioni registrate sul sistema di trouble ticketing, all’interno dei rapportibimestrali sui servizi erogati

AREA 2 - Infrastruttura di interoperabilità ESB/API




Fornitura infrastruttura di interoperabilitàESB/API

Piano per la fornitura, installazione e configurazione della nuova infrastruttura diintegrazione e per la migrazione e disaccoppiamento dei macrocomponenti delSISaRLicenze di utilizzo e/o canone di manutenzione per 3 anni a partire dalla data diinstallazione/attivazioneReport di Installazione e attivazione

Manuali di utilizzo

Report e statistiche periodiche di utilizzo e funzionamento

Piano di migrazione delle integrazioni esistenti

Evoluzione e migrazione su nuovainfrastruttura e disaccoppiamentofunzionale

Piano per la fornitura, installazione e configurazione della nuova infrastruttura diintegrazione e per la migrazione e disaccoppiamento dei macrocomponenti delSISaRDocumentazione tecnica sulle integrazioni

Check List e Verbali di Installazione


Note Operative



AREA 3 -Transizione

Transizione verso il fornitore\isubentrante\i

Piano di transizione

Verbali Attività

Relazione sullo Stato Avanzamento Lavori

Sorgenti SOFTWARE allineati all’ultima versione in produzioneDocumentazione funzionale, tecnica, manuali utenti, Manuali configurazioni,diagrammi UML etc. allineati ai sorgenti aggiornati

AREA 4 –Servizi Trasversali

Program, Project e ServiceManagement

Piano di progetto generale complessivo

Piano di Qualità e Matrice dei Rischi

Documento della Configurazione e Standard di Progetto

Rapporto trimestrale di Stato Avanzamento Lavori

Rapporto bimestrale sui servizi a canone

Rapporto sui Livelli di Servizio

Report stato Change Request

Piano di presa in carico

Verbali attivitàAggiornamento di tutti i documenti Tecnico\Funzionali del SISaR allegati allapresente garaReport audit interni ed esterni

Formazione e Affiancamento

Registri Presenze Formazione

Rapporto giornate pianificate ed erogate per Formazione e AffiancamentoFogli con la rilevazione del livello di soddisfazione degli utenti e statistiche sul livellodi soddisfazione degli utentiVerbali Attività




12. MODALITÀ DI ESECUZIONE

Come specificato nel paragrafo 2.1 Fasi del progetto e durata, durante la Fase 1 l’aggiudicatario dovrà

predisporsi all’erogazione delle prestazioni e acquisire le competenze operative per la presa in carico

effettiva del sistema SISaR. In questa fase dovrà predisporre, entro 10 giorni lavorativi dalla data di

stipula del contratto, la seguente documentazione:

o Piano di presa in carico (da concordare con la DEC)

La presa in carico dell’intero sistema e la formazione dovranno concludersi entro 3 mesi dalla data

della stipula del contratto.

La Fase 2 - Erogazione dei servizi inizierà a partire dal primo giorno successivo al termine di questa

Fase.

A decorrere dalla data di avvio della Fase 2, l’aggiudicatario dovrà:

1. presentare, entro 1 mese, la seguente documentazione:

o piano di progetto generale;

o piano di qualità e matrice dei rischi;

o documento della configurazione e standard di progetto;

o modello e prima versione di piano per la manutenzione preventiva;

o modello e prima versione di piano per la manutenzione adeguativa e adattativa;

o modello e prima versione di piano per la manutenzione perfettiva;

o modello e prima versione di piano per il miglioramento delle performance e della user

experience;

o piano per la fornitura, installazione e configurazione della nuova infrastruttura di

integrazione e per la migrazione e disaccoppiamento dei macrocomponenti del

SISaR;

o modello e prima versione del piano della manutenzione evolutiva;

2. produrre, con cadenza mensile:

o aggiornamento del piano della manutenzione evolutiva;

o rapporto giornate pianificate ed erogate per Formazione e Affiancamento;

o report di dettaglio (da definirsi con l’Amministrazione Aggiudicatrice) sullo stato di

tutte le integrazioni che insistono sull’integratore SpagiC e sul nuovo integratore;

3. produrre, con cadenza bimestrale:

o rapporto dei servizi erogati contenente la descrizione dettagliata delle attività

riguardanti i servizi a corpo con rendicontazione a canone svolte nel periodo di

riferimento, con i relativi deliverable (verbali, documentazione, etc.) e il relativo

rendiconto economico;




4. produrre, con cadenza trimestrale:

o rapporto di Stato di avanzamento lavori per i servizi a corpo e a misura per cui è

prevista la rendicontazione a SAL;

o aggiornamento del Piano di progetto, del piano della qualità e gestione dei rischi, del

documento della configurazione e standard di progetto;

o aggiornamento del piano per la manutenzione preventiva;

o aggiornamento del piano per la manutenzione adeguativa e adattativa;

o aggiornamento del piano per la manutenzione perfettiva;

o aggiornamento del piano per il miglioramento delle performance e della user

experience;

o aggiornamento del piano per la fornitura, installazione e configurazione della nuova

infrastruttura di integrazione e per la migrazione e disaccoppiamento dei

macrocomponenti del SISaR;

o calcolo dei livelli di servizio – SLA - per ciascun indicatore effettuato sui dati

riscontrabili dai tool di trouble ticketing, JIRA o ricavabili da sistemi di monitoraggio;

5. presentare, prima di 6 mesi dalla data di conclusione del contratto:

o piano di transizione.

Nell’erogazione dei servizi oggetto del presente appalto, l’aggiudicatario è tenuto ad adempiere agli

obblighi inerenti all’utilizzo dei sistemi di supporto per ciascuno specifico servizio, come da indicazioni

di dettaglio contenute nella descrizione dei servizi di cui al presente Capitolato.

13. SLA – LIVELLI DI SERVIZIO E OBBLIGHI DELL’AGGIUDICATARIO

Con decorrenza dalla data di avvio della Fase 2 (cap. 2.1), l’aggiudicatario è tenuto a garantire il

rispetto dei livelli di servizio (SLA) e delle modalità di esecuzione indicati nel seguito del presente

capitolo.

Il periodo di osservazione per il calcolo degli SLA è trimestrale, intendendosi con ciò che la

misurazione degli SLA sarà effettuata ogni 3 mesi a partire dall’avvio della Fase 2. L’aggiudicatario

entro il 20 del mese successivo al trimestre, a partire dal primo trimestre di erogazione dei servizi,

dovrà presentare regolarmente il report completo di tutti gli SLA. Più precisamente, il periodo

contrattuale della Fase 2 risulta diviso in 6 trimestri di rilevazione al fine del controllo degli SLA, che

sono pertanto così individuati:

1. dal mese 4 al mese 7,








6. dal mese 24 al mese 27.

13.1. Metodo di calcolo degli SLA

Per gli indicatori con valori di soglia del tipo “<soglia 1> nel X% dei casi; <soglia 2> nel restante Y%

dei casi”, il metodo di calcolo degli SLA è il seguente:

1. Si ordinano i casi rientranti nel periodo di riferimento per valore di interesse crescente.

2. Si considera il sottoinsieme costituito dal primo X% dell’insieme ordinato di cui al punto

precedente e si contano i casi che superano la soglia 1.

3. Analogamente, si considera il sottoinsieme costituito dal restante Y% dell’insieme ordinato di

cui al punto precedente e si contano i casi che superano la soglia 2.

4. Il totale dei casi che superano i valori di soglia per i due sottoinsiemi, rapportato al numero

totale (100%) dei casi, rappresenta la violazione dello SLA ed è la percentuale da utilizzare ai

fini della determinazione delle penali di cui al cap. 14.1.

5. Se entrambi i valori di cui ai punti precedenti 2 e 3 sono minori o uguali alle rispettive soglie, lo

SLA è rispettato.

Come caso particolare del precedente, se l’indicatore è del tipo valor medio, il metodo di calcolo di cui

sopra è il seguente:

1. Si ordinano i casi rientranti nel periodo di riferimento per valore di interesse crescente.

2. Si considera il sottoinsieme costituito dal primo X% dell’insieme ordinato di cui al punto

precedente e si calcola l’indicatore (media). Se l’indicatore (media) risulta superiore alla soglia

1, si conta il numero minimo di casi del sottoinsieme che portano la media sopra la soglia 1.

3. Analogamente, si considera il sottoinsieme costituito dal restante Y% dell’insieme ordinato di

cui al punto precedente e si calcola l’indicatore (media). Se l’indicatore (media) risulta

superiore alla soglia 2, si conta il numero minimo di casi del sottoinsieme che portano la

media sopra la soglia 2.

4. Il totale dei casi di cui ai punti 2 e 3, che portano l’indicatore a superare i valori di soglia per i

due sottoinsiemi, rapportato al numero totale (100%) dei casi, rappresenta la violazione dello

SLA ed è la percentuale da utilizzare ai fini della determinazione delle penali di cui al cap.

14.1.

5. Se entrambi i valori di cui ai punti precedenti 2 e 3 sono minori o uguali alle rispettive soglie, lo

SLA è rispettato.




Per tutti gli altri indicatori, ogni caso superiore al valore di soglia determina la violazione dello SLA e il

totale dei casi fuori SLA, rapportato al numero totale (100%) dei casi, rappresenta la percentuale da

utilizzare ai fini della determinazione delle penali di cui al cap. 14.1.

Si consideri comunque che il calcolo degli SLA deve consentire di valutare tutti gli eventi accaduti nel

periodo. In particolare, oltre a prendere in considerazione le segnalazioni registrate nel periodo per il

quale si stanno calcolando gli SLA, è necessario anche prendere in considerazione le segnalazioni

registrate in periodi precedenti a quello in esame ma prese in carico, chiuse o elaborate nel periodo in

esame.

13.2. Manutenzione Correttiva

La manutenzione correttiva fa parte del Servizio A1.1: Manutenzione Preventiva, Adeguativa,

Correttiva, Perfettiva (Cap. 3.1.3).

Codice SLA Indicatore Valore di soglia Descrizione

A1.1-1Tempo medio dirimozione di guasti oerrori bloccanti

Entro 8 ore consecutive di coperturadel servizio nel 90% dei casi

Entro 16 ore consecutive nelrestante 10% dei casi

In caso di guasti o errori bloccanti vienemisurato il tempo medio necessario perla individuazione, risoluzionedell’inconveniente e ripristino delsoftware applicativo dalla rispettiva presain carico durante le ore di copertura delservizio di manutenzione correttiva

A1.1-2Tempo medio dirimozione di guasti oerrori non bloccanti

Entro 24 ore consecutive dicopertura del servizio nel 90% deicasi

Entro 36 ore consecutive nelrestante 10% dei casi

In caso di guasti o errori non bloccantiviene misurato il tempo medionecessario per la individuazione erisoluzione dell’inconveniente e ripristinodel software applicativo dalla rispettivapresa in carico durante le ore dicopertura del servizio di manutenzionecorrettiva

A1.1-3Tempo massimo dirisoluzione dei guasti oerrori bloccanti

30 ore consecutive

Per guasti o errori bloccanti di severità 1il tempo impiegato per la individuazionee risoluzione dell’inconveniente eripristino del software applicativo inproduzione, anche medianteapplicazione di work-around, dallarispettiva presa in carico durante le ore dicopertura del servizio di manutenzionecorrettiva, non deve superare in nessuncaso la soglia massima indicata.

A1.1-4Tempo massimo dirisoluzione dei guasti oerrori non bloccanti

130 ore consecutive

Per guasti o errori non bloccanti il tempoimpiegato per la individuazione erisoluzione dell’inconveniente e ripristinodel servizio in produzione, anchemediante applicazione di work-around,dalla rispettiva presa in carico durante leore di copertura del servizio dimanutenzione correttiva, non devesuperare in nessun caso la sogliamassima indicata.

A1.1-5Numero interventi di Casi rilevati < 3 Numero di interventi che hanno

comportato la riapertura su stesso




manutenzione recidivi malfunzionamento di casi di guasti oerrori che risultavano già risolti sulsistema di TT

La classificazione del livello di gravità dell’errore è la seguente:

Severità 1 (A1.1-1, A1.1-3) Anomalia bloccante L’intero sistema\modulo è indisponibile agli utenti o gravemente

degradato.

Severità 2 (A1.1-1, A1.1-3) Anomalia grave Funzioni critiche del sistema\modulo sono indisponibili agli utenti o

gravemente degradate.

Severità 3 (A1.1-2, A1.1-4) Anomalia media

Funzioni non critiche del sistema\modulo sono indisponibili agliutenti o gravemente degradate, oppure funzioni critiche sonolievemente degradate.

Severità 4 (A1.1-2, A1.1-4) Anomalia lieve Funzioni non critiche del sistema\modulo sono lievemente

degradate.

Ai fini del calcolo degli SLA, per l’applicazione di eventuali penali, come tempo di risoluzione del

singolo ticket si considera il tempo netto di risoluzione registrato dall’aggiudicatario nello strumento di

Trouble Ticketing.

Le tipologie di ticket registrate nello strumento di TT gestito dall’aggiudicatario prese in considerazione

per il calcolo degli SLA relativi alla manutenzione correttiva sono almeno le seguenti:

• Anomalia Software

• Anomalia DB

• Anomalia Hardware

• Anomalia Recupero dati.

13.3. Manutenzione Preventiva, Adeguativa, Perfettiva

Il presente SLA si applica alla manutenzione Preventiva, Adeguativa e Perfettiva.

Queste manutenzioni fanno parte del Servizio A1.1: Manutenzione Preventiva, Adeguativa, Correttiva,

Perfettiva (Cap. 3.1.1, Cap. 3.1.2, Cap. 3.1.4). Il servizio viene attivato aprendo un ticket sul sistema

Jira\Sistema di TT. La segnalazione può essere fatta da utenti della Direzione Generale della Sanità,

dagli utenti delle Aziende Sanitarie, dalla Direzione dell’esecuzione del contratto o dall’Aggiudicatario

stesso.

I livelli di servizio minimi che devono essere garantiti sono i seguenti:

Codice SLA Descrizione Indicatore Valore Soglia Descrizione

A1.1-6Intervallo medio di presain carico della richiesta dimanutenzione

<5 giorni lavorativi nel90% dei casi

<10 giorni lavorativi nel

A fronte della richiesta di manutenzione vienemisurato il tempo medio per la presa in caricodella richiesta stessa da parte del ServiceManager




restante 10% dei casi

A1.1-7

Intervallo medio diemanazione delladocumentazione diprogettazione per larichiesta di manutenzioneprevista al cap. 3.1.2


<25 giorni lavorativi nelrestante 10% dei casi

A fronte della presa in carico e dell’analisi dellamanutenzione richiesta viene misurato il tempomedio per la produzione della progettualitàrichiesta

Tutto il processo di manutenzione Preventiva, Adeguativa e Perfettiva dovrà essere tracciato

attraverso il sistema Jira / sistema di TT. L'aggiudicatario è tenuto (con decorrenza dalla data di avvio

della Fase 2 di cui al cap. 2.1) a garantire che all’interno del sistema di Jira \Sistema di TT,

contestualmente alla conferma della presa in carico, sia espressamente indicato il tempo entro cui

sarà consegnato il piano delle attività.

L'aggiudicatario è tenuto a consegnare la pianificazione e le note di rilascio delle manutenzioni, in

coerenza con gli SLA previsti per la messa in produzione delle release/add.

13.4. Manutenzione per adeguamenti normativi ordinari

La manutenzione normativa ordinaria fa parte del Servizio A1.1: Manutenzione Preventiva,

Adeguativa, Correttiva, Perfettiva (Cap. 3.1.2), ed è un caso particolare della manutenzione

adeguativa.

Il servizio, per quanto attiene gli adeguamenti normativi ordinari derivanti da norme di livello regionale

o nazionale, viene attivato aprendo una segnalazione sul sistema Jira \Sistema di TT. La

segnalazione può essere fatta da utenti della Direzione Generale della Sanità, dagli utenti delle

Aziende Sanitarie, dalla Direzione dell’esecuzione del contratto o dall’Aggiudicatario stesso.

I livelli di servizio minimi che devono essere garantiti per gli adeguamenti normativi ordinari sono i

seguenti:


A1.1-8Intervallo medio di presain carico della richiesta divariazione normativa

<5 giorni lavorativi nel 90%dei casi


A fronte della richiesta di variazionenormativa viene misurato il tempo medioper la presa in carico della richiestastessa da parte dell’Aggiudicatario

A1.1-9




A fronte della presa in carico e dell’analisidella variazione normativa richiesta vienemisurato il tempo medio per laproduzione della documentazione diprogettazione richiesta




Tutto il processo di adeguamento normativo ordinario dovrà essere tracciato attraverso il sistema Jira.

L'aggiudicatario è tenuto (con decorrenza dalla data di avvio della Fase 2 di cui al cap. 2.1) a garantire

per gli adeguamenti normativi ordinari che all’interno del sistema di Jira \Sistema di TT,

contestualmente alla conferma della presa in carico, sia espressamente indicato il tempo entro cui

sarà consegnato il rispettivo documento di progettazione.

L'aggiudicatario è tenuto a consegnare la pianificazione e le note di rilascio delle evoluzioni normative

in coerenza con gli SLA previsti per la messa in produzione delle release / add.

13.5. Servizi per il miglioramento delle performance e dell’usabilità

Per i servizi in oggetto (Cap. 3.2), i livelli di servizio minimi che devono essere garantiti sono i

seguenti:


A1.2-1

Rispetto dei tempi diconsegna dei diversiaggiornamenti del sistemasecondo il piano

100% del rispetto dei tempiprevisti nei piani rilasciatidall’aggiudicatario

L’aggiudicatario dovrà rispettare ilpiano dei rilasci riportato nel piano peril miglioramento delle performance edella user experience

A1.2-2Numero interventi diaggiornamento rimossi surichiestadell'amministrazione/DEC

Casi rilevati < 4Casi rilevati di intervento chepeggiorano le performance e l'usabilitàsegnalati dall'amministrazione/DEC

Per quanto riguarda il calcolo dello SLA A1.2-1, si dovrà verificare se “il pronti al rilascio in

produzione” rispetta le date previste nel piano di progetto aggiornato trimestralmente.

L’aggiornamento del piano di progetto per il miglioramento delle performance e della user experience

non potrà prevedere ritardi del rilascio in produzione delle integrazioni, salvo cause non imputabili

all’aggiudicatario, pena l’applicazione delle penali previste nell’apposita sezione.

Tutto il processo di interventi per il miglioramento delle performance dovrà essere tracciato attraverso

il sistema Jira / sistema di TT. L'aggiudicatario è tenuto (con decorrenza dalla data di avvio della Fase

2 di cui al cap. 2.1) a garantire la registrazione dei dati degli interventi sul sistema Jira \Sistema di TT,

analogamente a quanto specificato per gli altri interventi di manutenzione.

13.6. Servizi di Manutenzione Evolutiva

I servizi (cap. 3.3) vengono attivati aprendo un ticket sul sistema Jira\Sistema di TT. La segnalazione

può essere fatta da utenti della Direzione Generale della Sanità o dalla Direzione dell’esecuzione del

contratto.






A1.3-1Tempo di presa in caricodella richiesta di evoluzionedel software applicativo

<5 giorni lavorativi dallarichiesta nel 90% dei casi

<10 giorni lavorativi dallarichiesta nel restante 10%dei casi

A partire dalla data di richiesta dievoluzione del software applicativoviene misurato il tempo per la presain carico della richiesta stessa daparte dell’Aggiudicatario SISaR

A1.3-2Tempo di presentazione deldocumento di analisifunzionale relativo alla CR

<20 giorni lavorativi dallapresa in carico nel 90% deicasi

<30 giorni lavorativi dallapresa in carico nel restante10% dei casi

A partire dalla data di presa in caricodella richiesta di evoluzione delsoftware applicativo viene misurato iltempo per il rilascio della versionedel documento di analisi funzionale.Nel periodo dalla presa in carico alrilascio del documentol’Aggiudicatario potrà eventualmentechiedere approfondimenti necessariall’AmministrazioneAggiudicatrice\DEC\Utente

A1.3-3

Tempo di presentazione delpiano di sviluppo della CRcon descrizione delleiterazioni, cronoprogramma equantificazione economica

<10 giorni lavoratividall’approvazionedell’analisi funzionale nel90% dei casi

<15 giorni lavoratividall’approvazionedell’analisi funzionale nelrestante 10% dei casi

A partire dalla data di approvazionedel documento di analisi funzionaleviene misurato il tempo per il rilasciodel piano di sviluppo della CR condescrizione delle iterazioni,cronoprogramma e quantificazioneeconomica

A1.3-4

Avvio dell’esecuzione delpiano di sviluppo della CR aseguito dell’approvazionedella DEC

100% del rispetto delladata di avvio prevista perl’avvio dell’esecuzione

L’aggiudicatario dovrà rispettare ladata di avvio dell’esecuzione delleattività concordata in sede diapprovazione del piano di sviluppo.

A1.3-5

Rispetto delle milestone delpiano di sviluppo della CR edei tempi di rilascio dellesingole funzionalità resedisponibili per ogni iterazione


L’aggiudicatario dovrà rispettare lapianificazione approvata e dovràriportare nel piano per lamanutenzione evolutiva le milestoneseffettive di rilascio intermedie e inproduzione (pronti al rilascio inproduzione)

A1.3-6 Casi di test falliti nel collaudopreliminare

Percentuale di test falliti sutest effettuati <= 10%

Casi di test falliti durante la fase dicollaudo preliminare al rilascio dellefunzionalità, rispetto al numero di testeffettuati secondo il piano di test

Tutto il processo del singolo intervento di evoluzione, dalla richiesta fino alla effettiva messa in

produzione, dovrà essere tracciato attraverso il sistema Jira\Sistema di TT. L'aggiudicatario è tenuto

(con decorrenza dalla data di avvio della Fase 2 di cui al cap. 2.1) a garantire la registrazione dei dati

all’interno del sistema di ALM Jira, come specificato nel cap. 10 Strumenti di supporto.

Si consideri che il periodo di osservazione deve consentire di valutare gli SLA degli eventi accaduti

nel periodo. In particolare, oltre a prendere in considerazione le CR registrate nel periodo per il quale

si stanno calcolando gli SLA, è necessario anche prendere in considerazione le CR registrate in




periodi precedenti a quello in esame ma analizzate, valutate, prese in carico, chiuse, etc., nel periodo

in esame.

13.7. Servizi Specialistico-Applicativi

Il servizio (Cap. 3.4) viene attivato aprendo un ticket sul sistema Jira\Sistema di TT, attraverso una

chiamata ad un numero di telefono dedicato o attraverso invio mail ad indirizzo dedicato. La richiesta

dovrà essere comunque tracciata sul sistema Jira \Sistema di TT. La segnalazione può pervenire da

utenti della Direzione Generale della Sanità, dagli utenti delle Aziende Sanitarie, dalla Direzione

dell’esecuzione del contratto\SardegnaIT o dall’Aggiudicatario stesso.



A1.4-1

Intervallo medio di presa incarico della richiesta disupporto specialistico-applicativo remoto

<8 ore lavorative nel90% dei casi

<16 ore lavorative nelrestante 10% dei casi

A fronte della richiesta di supportospecialistico - applicativo remoto vienemisurato il tempo medio per la presa incarico della richiesta stessa da partedell’Aggiudicatario SISaR

A1.4-2 Sostituzione del personale <2 risorse

Numero di sostituzioni unilateraliingiustificate dal punto di vistadell'esecuzione del contratto diSpecialisti di prodotto. Eventualisostituzioni finalizzate ad un migliorefunzionamento dei servizi/attività,purché preventivamente condivise eapprovate dai referentidell’Amministrazione, noncontribuiscono al conteggio. Eventualisostituzioni operate a fronte didimissioni / licenziamento di risorseimpegnate nell’erogazione dei servizinon contribuiscono al conteggio purchéopportunamente documentate.

Tutto il processo di supporto specialistico-applicativo remoto dovrà essere tracciato attraverso il

sistema Jira. L'aggiudicatario è tenuto (con decorrenza dalla data di avvio della Fase 2 di cui al cap.

2.1) a garantire che all’interno del sistema di ALM Jira, contestualmente alla conferma della presa in

carico, sia espressamente indicato il tempo entro cui sarà effettuata la

parametrizzazione/configurazione della soluzione applicativa.

13.8. Gestione ambiente applicativo di test

Il servizio (Cap. 3.5) viene attivato allorquando viene pubblicata la disponibilità di una nuova release /

patch / add. Non si applica per gli interventi correttivi.






A1.5-1

Intervallo medio per la messa inesercizio in ambiente di test diuna nuova Patch/Add/NuovaRelease rilasciata



A fronte della comunicazione delladisponibilità di una patch/Add/nuovarelease viene misurato il tempomedio entro il quale il Team diApplication Operation la installa inambiente di test

I livelli di servizio devono essere calcolati dall’Aggiudicatario ed esposti alla DEC su tracciato a scelta

dell’Aggiudicatario dove compaiono le date di disponibilità della nuova patch/add/release ricavabili

nello strumento di pubblicazione della patch e la data di messa in esercizio nell’ambiente di test.

Il tracciamento degli interventi mediante il quale verranno calcolati gli SLA dovrà essere effettuato

attraverso il sistema Jira / Sistema di TT.

13.9. Gestione ambiente applicativo di produzione

Il servizio (Cap. 3.5) viene attivato allorquando la DEC, o l’aggiudicatario autonomamente, decide di

mettere in produzione una nuova release / add che ha superato i test nell’ambiente applicativo di test.

Non si applica per gli interventi correttivi.



A1.5-2Rispetto dei tempi di preavvisorichiesti per interventi cheimplicano disservizi

=100% Questo SLA deve essere semprerispettato salvo diversaautorizzazione della DEC

A1.5-3

Intervallo medio per la messa inesercizio in ambiente diproduzione di una nuovaPatch/Add/Nuova Releaserilasciata



A fronte della verifica in test di unaNuova Release, ADD o di una Patchviene misurato il tempo medio entro ilquale il Team di ApplicationOperation la installa in ambiente diproduzione

A1.5-4

Tempo di disservizio per la messain esercizio di una nuovaPatch/Add/Nuova Release

<30 ore solari

Tempo complessivo di disserviziocausato da tutti i casi in cui èpossibile mettere in esercizio lanuova Patch/Add/Nuova Releaseutilizzando la modalità hot-deploy mail fornitore ha scelto una modalitàdifferente.

I livelli di servizio devono essere calcolati dall’Aggiudicatario ed esposti alla DEC su tracciato a scelta

dell’Aggiudicatario dove compaiono le date di decisione della messa in produzione / data di verifica

positiva in test e data di condivisione del piano operativo di rilascio.

Il servizio dovrà essere erogato nel rispetto dei vincoli e delle cautele sugli orari e sulla pianificazione

degli interventi già descritti nel Cap. 3.5.




Il tracciamento degli interventi mediante il quale verranno calcolati gli SLA dovrà essere effettuato

attraverso il sistema Jira / Sistema di TT.

13.10.Gestione sistemistico-applicativa

Per questo servizio (cap. 3.6), i livelli di servizio minimi rientrano nella casistica censita nella

manutenzione correttiva cioè i blocchi segnalati che saranno originati da non corretta gestione

sistemistico-applicativa saranno censiti come anomalia e saranno ricompresi nel calcolo di A1.1-1,

A1.1-2, A1.1-3, A.1.1-4.

Per quanto riguarda la componente di integrazione si riportano i livelli di servizio richiesti:


A1.6-1Tempo di risoluzionedall’insorgenza del blocco dellaintegrazione al suo riavvio

< 4 ore Questo SLA deve essere semprerispettato

A1.6-2

Disponibilità in produzione delmodulo per la compilazione delmodello 770 per l’annualità diriferimento

Entro 1 mese primadella scadenza dipresentazione delmodello

Questo SLA deve essere semprerispettato

A1.6-3

Numero massimo di errori sulDirezionale inerenti mancatocaricamento dei dati o erratocaricamento dei dati

< 5

Questo SLA deve essere semprerispettato. Gli utenti che utilizzano ildirezionale devono avere sempredisponibili i dati sul direzionalecaricati in maniera corretta. Lafrequenza minima di aggiornamentodegli indicatori di utilizzo è giornalieramentre quella dei vari data mart saràvariabile e stabilita dalla stazioneappaltante all’avvio del contratto.

Il tracciamento degli errori, mediante il quale verranno calcolati gli SLA, dovrà essere effettuato

attraverso il sistema di TT.

13.11.Help Desk

Il servizio (cap. 3.7) viene attivato mediante segnalazione telefonica all’operatore di help desk, il quale

prende in carico la richiesta provvedendo ad aprire un ticket sul sistema di Trouble Ticketing ed a

comunicare il numero di Ticket all’utente richiedente. La segnalazione può essere fatta da utenti della

Direzione Generale della Sanità, dagli utenti delle Aziende Sanitarie, dalla Direzione dell’esecuzione

del contratto o dall’Aggiudicatario stesso.

I livelli di servizio minimi che devono essere garantiti per quanto concerne l’efficienza di presa in

carico telefonica della richiesta sono i seguenti:





A1.7-1 Tempo di attesa netto

Il tempo diconnessione conl’operatore non devesuperare i 30secondi.

TT1 ≥ 90%.

Misura del tempo che intercorre tra larichiesta di contatto con l’operatore(ingresso della chiamata in assenza di IVR,oppure la digitazione della richiestanell’ambito della struttura dell’IVR),espressa secondo la formula_

TT1 = (CRO/CROT)*100

Dove CRO è il numero totale di chiamateche hanno richiesto un contatto conl’operatore e sono state connesse conl’operatore entro i tempi definiti, CROT è ilnumero totale di chiamate che hannorichiesto di essere connesse conl’operatore.

A1.7-2 Tempo di presa in carico dellarichiesta

< 10 min nel 95% deicasi

Viene misurato il tempo che intercorre dallaricezione della richiesta multicanale(telefono, mail, ecc.) alla presa in caricodella segnalazione

A1.7-3 Numero richieste riaperte < 5%Percentuale di richieste riaperte per casiimputabili all'aggiudicatario sul totale dellerichieste chiuse

I livelli di servizio minimi che devono essere garantiti per quanto concerne la risoluzione del problema

segnalato dall’Utente sono i seguenti:

Codice SLA DescrizioneIndicatore Valore soglia Descrizione

A1.7-4Tempo medio dirisoluzione dallapresa in carico

Entro 1 giorno lavorativo nel 70% dei casi

Entro 2 giorni lavorativi nel restante 30% dei casiErrori con livello di gravitàCNIPA 1


Entro 2 giorni lavorativi nel 70% dei casi








I livelli di servizio devono essere calcolabili autonomamente da parte della Direzione dell’Esecuzione a

partire dai dati riportati sul sistema di Trouble Ticketing (si veda cap. 10 Strumenti di supporto). Nel

sistema di Trouble Ticketing devono essere presenti gli eventuali tempi di ritardo causati dai tempi di

risposta degli utenti.

Tutte le attività di assistenza help desk, dalla segnalazione e apertura del ticket a seguito di

segnalazione telefonica fino alla risoluzione, dovranno essere tracciate attraverso lo strumento di

Trouble Ticketing che, in particolare, dovrà consentire la tracciabilità sia dei tempi complessivi che




vanno dalla segnalazione all’intervento risolutivo, sia anche di eventuali sospensioni dei termini in

attesa di riscontro alle richieste di chiarimenti/integrazioni effettuate verso l’utente.

Le tipologie di ticket registrate nello strumento di TT gestito dall’aggiudicatario prese in considerazione

per il calcolo degli SLA relativi alla manutenzione correttiva sono almeno le seguenti:

• Formazione Applicativa

• Richieste Evolutive

• In fase di analisi

• Assistenza Generica

• Supporto Tecnico Normativo

• Verifica su dati del DB.

13.12.Reperibilità H24 mission critical

Il servizio di reperibilità H24 (cap. 3.8) prevede che le segnalazioni di malfunzionamenti/guasti

relativamente ai sistemi coperti da tale servizio vengano avanzate direttamente dagli utenti ai numeri

telefonici di reperibilità specifici. Il tecnico reperibile di turno, cui viene indirizzata la singola

segnalazione telefonica di malfunzionamento/guasto, alla risposta sottopone all’utente chiamante le

richieste di informazioni utili a definire la problematica e attivare la gestione dell’intervento risolutivo e

dunque provvede alla conferma della rispettiva presa in carico.

Compiuto l’intervento, il tecnico reperibile provvede a confermare la chiusura del medesimo all’utente,

nonché a registrare successivamente sul sistema di trouble ticketing i dati dell’attività operata allo

scopo.



A1.8-1

Tempo medio di intervento daremoto dalla presa in carico dellasegnalazione di malfunzionamentosu Infrastruttura Tecnologica e/oPronto Soccorso e/o TrasfusionaleSISaR nella fascia oraria direperibilità H24

<= 1 ora dalla presa incarico della segnalazionenel 90% dei casi

<= 4 ore dalla presa incarico della segnalazionenel restante 10% dei casi

A fronte della segnalazione dimalfunzionamento, nella fascia oraria direperibilità H24, su infrastrutturatecnologica e/o pronto soccorso e/otrasfusionale SISaR, viene misurato iltempo medio intercorrente tra la presa incarico della segnalazione medesima el’inizio delle attività di intervento daremoto

A1.8-2

Tempo medio di intervento in locodalla presa in carico dellasegnalazione di malfunzionamentosu Infrastruttura TecnologicaSISaR nella fascia oraria direperibilità H24

<= 4 ore dalla presa incarico della segnalazionenel 90% dei casi

<= 6 ore dalla presa incarico della segnalazionenel restante 10% dei casi

A fronte della segnalazione dimalfunzionamento, nella fascia oraria direperibilità H24, su infrastrutturatecnologica SISaR, viene misurato iltempo medio intercorrente tra la presa incarico della segnalazione medesima el’inizio delle attività di intervento in loco




I livelli di servizio devono essere calcolabili dalla DEC a partire dai dati riportati sul sistema di Trouble

Ticketing o su altro strumento. Considerato che in genere la segnalazione viene condivisa tramite

chiamata al numero telefonico di reperibilità, è onere e obbligo dell’aggiudicatario tracciare la

segnalazione sul sistema di Trouble Ticketing o altro strumento.

13.13.Realizzazione nuova infrastruttura interoperabilità

Il servizio (cap. 4.1) viene attivato a partire dal piano di progetto che l’aggiudicatario dovrà predisporre

coerentemente all’offerta tecnica presentata in sede di gara.



A2.1-1

Rispetto dei tempi diinstallazione e attivazionedell’infrastruttura ESB/APIsecondo piano di progetto

100% del rispetto deitempi previsti nei pianirilasciatidall’aggiudicatario

L’aggiudicatario trimestralmente dovràaggiornare un piano delle attività in cuisono specificate le milestones di rilascio inproduzione (pronti al rilascio inproduzione)

Per quanto il calcolo dello SLA A2.1-1 si dovrà verificare se “il pronti al rilascio in produzione” rispetta

le date previste nel piano di progetto. L’aggiornamento del piano di progetto non potrà prevedere

ritardi del rilascio in produzione dell’infrastruttura, salvo cause non imputabili all’aggiudicatario, pena

l’applicazione delle penali previste.

13.14.Evoluzione e migrazione su nuova infrastruttura e disaccoppiamento funzionale

Il servizio (cap. 4.2) viene attivato a partire dal piano di progetto che l’aggiudicatario dovrà predisporre

coerentemente all’offerta tecnica presentata in sede di gara.

I livelli di servizio minimi che devono essere garantiti sono i seguenti (si veda anche SLA A.4.1-13 dei

servizi trasversali):


A2.2-1

Rispetto dei tempi dimigrazione delle integrazioniesistenti secondo piano diprogetto


L’aggiudicatario trimestralmente dovràaggiornare un piano della Evoluzione emigrazione su nuova infrastruttura edisaccoppiamento funzionale a corpoin cui sono specificate le milestones dirilascio in produzione (pronti al rilascioin produzione)

A2.2-2

Rispetto dei tempi di rilasciodelle nuove integrazionipresentate nel piano diprogetto


L’aggiudicatario trimestralmente dovràaggiornare un piano della Evoluzione emigrazione su nuova infrastruttura edisaccoppiamento funzionale a corpoin cui sono specificate le milestones dirilascio in produzione (pronti al rilascioin produzione)

A2.2-3 Casi di test falliti nel Percentuale di test falliti su Casi di test falliti durante la fase di




collaudo preliminare test effettuati <= 10% collaudo preliminare al rilascio dellefunzionalità, rispetto al numero di testeffettuati secondo il piano di test

Per quanto il calcolo dello SLA A2.2-1 e A2.2-2 si dovrà verificare se “il pronti al rilascio in produzione”

rispetta le date previste nel piano di progetto della manutenzione evolutiva per le integrazioni a corpo

aggiornato trimestralmente. L’aggiornamento del piano di progetto non potrà prevedere ritardi del

rilascio in produzione delle integrazioni, salvo cause non imputabili all’aggiudicatario, pena

l’applicazione delle penali previste.

13.15. Transizione verso il fornitore subentrante

Per il servizio in oggetto (Cap. 5.1) l’aggiudicatario è tenuto al rispetto dei tempi di consegna del piano

di transizione e al rispetto del medesimo secondo le tempistiche definite dall’Amministrazione

Aggiudicatrice.

Tutta la documentazione tecnica e i sorgenti aggiornati dovranno essere resi disponibili al nuovo

fornitore secondo le tempistiche richieste dall’Amministrazione Aggiudicatrice e che saranno previste

nel piano di transizione.


A3.1-1Tempo massimo di rilascio deldocumento riguardante il piano ditransizione

Secondo le tempistiche dicui al cap. 12

A conclusione della procedura diaggiudicazione della nuova gara, in casodi aggiudicatario diverso dal fornitoreattuale, lo stesso dovrà produrre unpiano di lavoro dettagliato

A3.1-2Tempo massimo di rilascio di tuttala documentazione aggiornata perla pubblicazione della gara

100% dei casi: tutta ladocumentazione tecnicacompleta ed i sorgenti adhoc e personalizzazioniche sarà consideratanecessaria per lapubblicazione della garadovrà essere rilasciataentro tre mesi dalla data dirichiesta

Per rendere disponibili tutte leinformazioni tecniche che consentano aipartecipanti alla nuova gara di poterpresentare le offerte tecniche eeconomiche, è necessario chel’Aggiudicatario condivida tutte le versioniaggiornate dei documenti e del codicesorgente dei software sviluppati ad hoc etutte le configurazioni eparametrizzazioni

A3.1-3 Rispetto delle milestones del pianodi transizione


A fronte delle milestones definite nelpiano di transizione approvatodall’Amministrazione Aggiudicatrice,l’Aggiudicatario dovrà rispettare le datedelle milestones

13.16.Program/Project/Service Management

I livelli di servizio minimi che devono essere garantiti per questo servizio (Cap. 6.1) sono i seguenti:

CodiceSLA Descrizione Indicatore Valore Soglia Descrizione




A4.1-1Tempo massimo di rilasciodel documento riguardantegli SLA trimestrali

100% dei casi

Entro il 20 del mese successivo al trimestre dirilevazione (cap. 13) dovrà essere inviato ildocumento con il calcolo degli SLA per ciascunservizio

A4.1-2

Tempo massimo diaggiornamento del portaledocumentazione su richiestadel DEC\SA

100% dei casi: tutti ideliverable riportati nelRapporto dei ServiziErogati o nel documento diSAL dovranno essereregistrati sul portaledocumentazione nellacartella riferita al bimestredi riferimento (servizi acorpo rendicontati acanone) o nel SAL (servizia misura e a corporendicontata a SAL) entro5 giorni lavorativi dalladata di richiestaaggiornamento del Portaledocumentazione

A conclusione di ciascun bimestre contrattuale dovràessere inviato il documento di Rapporto dei ServiziErogati (corpo-canone) e i deliverable in essoriportati dovranno essere inseriti nel portaledocumentazione. In caso di mancato inserimento diun deliverable l’Aggiudicatario è tenuto adottemperare alla richiesta di aggiornamento delportale entro 5 giorni lavorativi dalla data disegnalazione della DEC\SA. Analogamente nel casodi SAL.

A4.1-3Intervallo medio di rispostaalla richiesta di chiarimentida parte della DEC\SA



A fronte della richiesta di chiarimento da parte dellaDEC\SA l’Aggiudicatario dovrà provvedere arispondere secondo la tempistica media minimadefinita come soglia

A4.1-4Partecipazione alla verificatrimestrale SLA e riesamedel contratto

100%

Il contract manager, ilprogram manager, tutti iservice manager,dovranno partecipareobbligatoriamente dipersona presso laDirezione Generale dellasanità o comunque pressoun’altra sede localizzata inCagliari

Riunione trimestrale sull’andamento del progetto

A4.1-5Partecipazione a riunioni dilavoro, verifiche, raccolta deirequisiti utente

100%

Il program manager e iservice manager dovrannopartecipareobbligatoriamente dipersona alle riunioniconvocate con almeno unagiornata di anticipo che sisvolgeranno presso laDirezione Generale dellaSanità o comunque pressoun’altra sede localizzata inCagliari. Non sarannoconsiderate le assenzedovute a contemporaneaattività presso altri utenti eriguardanti i servizi oggettodella presente procedura

Riunione su convocazione dell’AmministrazioneAggiudicatrice ovvero della DEC

A4.1-6Consegna e aggiornamentodel piano di progettocomplessivo generale delcontratto, secondo le

100%L’Aggiudicatario deve consegnare e aggiornare ilpiano di progetto complessivo per i servizi delcontratto secondo le tempistiche di cui al cap. 12




tempistiche di cui al cap. 12

A4.1-7

Consegna e aggiornamentodel piano di qualità, matricedei rischi e documento dellaconfigurazione e standard diprogetto, secondo letempistiche di cui al cap. 12

100%

L’Aggiudicatario deve consegnare e aggiornare ilpiano di qualità, matrice dei rischi e documento dellaconfigurazione e standard di progetto, secondo letempistiche di cui al cap. 12

A4.1-8

Consegna e aggiornamentodel piano dellamanutenzione preventiva,secondo le tempistiche di cuial cap. 12

100%L’Aggiudicatario deve consegnare e aggiornare ilpiano della manutenzione preventiva secondoquanto previsto nel cap. 3.3 e nel cap. 12.

A4.1-9

Consegna e aggiornamentodel piano dellamanutenzione adeguativa eadattativa, secondo letempistiche di cui al cap. 12

100%L’Aggiudicatario deve consegnare e aggiornare ilpiano della manutenzione adeguativa e adattativasecondo quanto previsto nel cap. 3.3 e nel cap. 12.

A4.1-10

Consegna e aggiornamentodel piano per lamanutenzione perfettiva,secondo le tempistiche di cuial cap. 12

100%L’Aggiudicatario deve consegnare e aggiornare ilpiano per la manutenzione perfettiva, secondo letempistiche di cui al cap. 12

A4.1-11

Consegna e aggiornamentodel piano dellamanutenzione evolutiva,secondo le tempistiche di cuial cap. 12

100%L’Aggiudicatario deve consegnare e aggiornare ilpiano della manutenzione evolutiva secondo quantoprevisto nel cap. 3.3 e nel cap. 12.

A4.1-12

Consegna e aggiornamentodel piano per ilmiglioramento delleperformance e della userexperience, secondo letempistiche di cui al cap. 12

100%

L’Aggiudicatario deve consegnare e aggiornare ilpiano per il miglioramento delle performance e dellauser experience, secondo le tempistiche di cui alcap. 12

A4.1-13

Consegna e aggiornamentodel piano per la fornitura,installazione econfigurazione della nuovainfrastruttura di integrazionee per la migrazione edisaccoppiamento deimacrocomponenti delSISaR, secondo letempistiche di cui al cap. 12

100%

L’Aggiudicatario deve consegnare il piano per lafornitura, installazione e configurazione della nuovainfrastruttura di integrazione e per la migrazione edisaccoppiamento dei macrocomponenti del SISaR,secondo le tempistiche di cui al cap. 12

A4.1-14

Consegna dei risultati degliaudit dell’Ente Certificatore edel servizio interno perl’Assicurazione Qualità

100%

L’Aggiudicatario deve consegnare il risultato dei dueAudit annuali svolti dall’Ente Certificatore del sistemadi Qualità e interni del Servizio Aziendale perl’Assicurazione di qualità

A4.1-15 Rispetto scadenze temporalidei deliverable 0 giorni La data di consegna e la data prevista non devono

discostarsi

A4.1-16 Qualità delladocumentazione <2 documenti Numero di documenti rielaborati a seguito della

richiesta dell'Amministrazione/DEC

A4.1-17 Inadeguatezza delpersonale proposto <2 risorse

Numero di sostituzioni richieste dall'Amministrazioneper inadeguatezza secondo quanto specificato nelcap. 9




13.17.Formazione e affiancamento

Il servizio (Cap. 6.2) viene attivato a partire dal piano per la formazione proposto e accettato

dall’Amministrazione Aggiudicatrice.



A4.2-1

Rilascio dei fogli dirilevazione soddisfazioneutente compilati e calcolodegli indici statistici

100% delle sessioni diformazione con ilrilascio dei foglicompilati disoddisfazione utente ecalcolo indici statistici

L’aggiudicatario dovrà proporre lacompilazione del foglio di feedback per larilevazione del grado di soddisfazionedell’utente e dovrà calcolare gli indicistatistici per ogni sessione di formazionesvolta. Si dovrà verificare se sono statirilasciati e ritirati i fogli di feedbackcompilati e se sono stati calcolati gli indicistatistici.

A4.2-2 Numero sessioni diformazioni erogate inparallelo

3 sessionicontemporanee

A richiesta dell'Amministrazione/DECdeve essere sostenibile avere un numerominimo di sessioni di formazionecontemporaneamente anche in sedidifferenti.

13.18.Livelli di servizio Sicurezza/GDPR

Per quanto concerne il rispetto della normativa sulla sicurezza e sulla protezione dei dati personali,

con particolare riferimento al GDPR, l’aggiudicatario dovrà rispettare i livelli di servizio minimi

rappresentati nella seguente tabella. È previsto che il sistema consegnato in fase di presa in carico

disponga delle funzionalità necessarie per assicurare il rispetto di questi SLA. In ogni caso,

l’aggiudicatario, nel periodo di acquisizione delle competenze (Fase 1), dovrà verificare la sussistenza

di questi requisiti e relazionare alla DEC. Nel caso si dovesse rilevare la necessità di adeguamento

del sistema, le relative modifiche potranno essere richieste ed effettuate attraverso il servizio di

manutenzione evolutiva a consumo. Naturalmente, anche tutte le variazioni dei sistemi sviluppate

dall’aggiudicatario nel corso dell’esecuzione del contratto dovranno rispettare gli stessi SLA.


SICAPP1 Profilazione degli accessi inbase al ruolo 100% dei casi

Il sistema deve consentire di creare profili diautenticazione in base al ruolo rivestito(sistema di autorizzazione).

SICAPP2 Utilizzo di credenzialiuninominali 100% dei casi

L’aggiudicatario deve assicurarsi che ilsistema software consenta ad ogni operatoredi utilizzare credenziali uninominali (ossiadifferenti tra i singoli operatori).

SICAPP3 Autenticazione delle utenzetramite

100% casi Il sistema deve prevedere una autenticazionebasata su username e password, tramite




username/password, SPIDo CNS

SPID livello 2 o CNS\Tessera Sanitaria.

SICAPP4 Utilizzo di password sicure 100%

Il sistema deve prevedere i seguenti vincoliper la password:

Ha almeno 8 caratteri. Non è banale, ovvero non è soggetta ad

attacchi dizionario. Viene modificata dall’incaricato al primo

utilizzo. Viene modificata ogni 6 mesi o, in caso di

dati sensibili/giudiziari, ogni 3 mesi. Evita il riutilizzo di password

precedentemente utilizzate dallo stessoutente.

SICAPP5 Mascheratura della basedati 100%

Il sistema deve prevedere la possibilità dimodulare le informazioni alle quali si possaaccedere per singole attività.

SICAPP6 Encryption dei dati 100% Il sistema deve assicurare il corretto utilizzodel sistema di cifratura delle basi dati.

SICAPP7 Tracciatura degli accessi 100%

Il sistema deve memorizzare in un file di logtutti gli accessi degli operatori (sia gli accessiriusciti che quelli falliti). Dovrannomemorizzarsi, quindi, Data, ora, UID, esitologin (successo, fallito). I log devono essereconservati per almeno 6 mesi in manieracriptata.

SICAPP8 Tracciatura delle modifiche 100% Il sistema deve memorizzare in un file di logtutte le modifiche effettuate.

SICAPP9 Protezione dellecomunicazioni client/server 100%

Il sistema deve garantire che nellecomunicazioni client/server siano utilizzatiprotocolli di comunicazione sicuri (es. SSH).

SICAPP10Archivi separati tra daticomuni e altre categorie didati

100%

Il sistema deve garantire la possibilità ditrattare in modo differente (anche con sistemidi mascheramento o cifratura differenziati) idati comuni e le altre categorie di dati.

SICAPP11

Installazione patch disicurezza dellainfrastruttura software delsistema

100%

L’aggiudicatario dovrà tempestivamenteinstallare le patch di sicurezza dei diversisoftware che utilizza quali DBMS, ESB, Java,SPAGIC, SPAGOBI, Sistema Operativo,etcove questo non abbia impatti sulla continuitàdel servizio o funzionamento dei sistemi.Dovrà procedere a condividere l’analisi degliimpatti e dei rischi sulla mancata installazionenel caso questa possa procurare deidisservizi.

SICAPP12 Programma di backup deidati 100%

L’aggiudicatario deve adempiere alle policy dibackup che verranno condivise all’avvio delcontratto.

SICAPP13 Programma di backup delleconfigurazioni 100%

L’aggiudicatario deve adempiere alle policy dibackup che verranno condivise all’avvio delcontratto.

SICAPP14 Protezione / cifratura dei 100% L’aggiudicatario dovrà assicurare che i




backup backup siano protetti \ cifrati appositamente.

SICAPP15 Programma di test deirestore 100%

L’aggiudicatario dovrà rispettare le policy ditest dei restore dei dati secondo quantocondiviso all’avvio del contratto.

SICAPP16 Protezione/ cifratura delcanale di comunicazione 100%

Il sistema deve prevedere che lecomunicazioni relative al sistema sianoprotette/cifrate.

SICAPP17 Nomina del DPO 100% L’aggiudicatario deve aver nominato al suointerno un DPO.

SICAPP18 Nomina degli incaricati 100%

Tutto il personale che lavora sul Sistema eche effettua trattamenti dei dati deve avereun incarico al trattamento dei dati da partedell’aggiudicatario

SICAPP19 Comunicazione databreach 100% L’aggiudicatario dovrà notificare entro 1 ora

gli eventi di data breach.

SICAPP20 Comunicazione databreach 100%

L’aggiudicatario dovrà comunicare senzaritardi ingiustificati e comunque entro 48 oredal data breach l’analisi sull’evento avverso.

14. PENALI

Come riportato nel cap. 13 SLA – Livelli di servizio e obblighi dell’aggiudicatario, il periodo di

osservazione per il calcolo degli SLA è trimestrale, cioè l’aggiudicatario dovrà presentare il report su

tutti gli SLA dell’ultimo trimestre entro il 20 del mese successivo al trimestre di erogazione dei servizi.

Relativamente alle modalità amministrative per la proposta dell'applicazione di penali, il soggetto

proponente sarà la Direzione dell’Esecuzione. Il RUP prenderà atto della proposta e presenterà una

contestazione dettagliata all’Aggiudicatario. All’Aggiudicatario sarà dato un termine temporale per la

presentazione delle proprie controdeduzioni, ricevute le quali il RUP procederà o meno a determinare

formalmente l'applicazione delle eventuali penali. In caso di conferma dell’applicazione della penale,

la trattenuta contabile avverrà alla prima liquidazione utile successiva. L’aggiudicatario pertanto

fatturerà, in relazione a tale Canone o SAL, l’importo già ridotto del valore della penale applicata. In

caso di penali applicate in fase di chiusura del progetto, a seguito della verifica di conformità,

l’applicazione contabile si realizzerà a valere sul saldo finale contrattuale di svincolo delle ritenute

progressive del 10% applicate sui SAL, in corso di esecuzione, a garanzia della corretta esecuzione

delle prestazioni.

La decisione da parte del RUP in merito all’applicabilità delle penali ed alla relativa quantificazione

dovrà tener conto del grado di responsabilità imputabile all’Aggiudicatario, risultante dalla relazione

del Direttore dell’Esecuzione e dalle controdeduzioni dell’aggiudicatario, sulla base di quanto

comprovato da idonea documentazione. Il RUP inoltre potrà, sulla base della gravità




dell’inadempimento, decidere di tener conto di elementi attenuanti, quali il fatto che nel medesimo

periodo di riferimento del canone o SAL al quale le penali si riferiscono l’Aggiudicatario abbia dovuto

sostenere maggiori oneri a causa di circostanze impreviste imputabili alle Aziende Sanitarie,

all’Amministrazione Regionale o alla società in house SardegnaIT.

L’Aggiudicatario è soggetto alle seguenti penali, applicabili esclusivamente a partire dalla data di avvio

della Fase 2 (cap. 2.1).

14.1. Penali per mancato rispetto degli SLA

Per l’individuazione degli SLA soggetti a questo tipo di penali, si veda la tabella sinottica al par. 14.3.

Tali penali saranno determinate come di seguito descritto:

- Nel caso di SLA calcolati in termini percentuali, la penale applicabile sarà pari allo 0,1 per mille

dell’importo contrattuale associato allo specifico servizio per ogni punto percentuale eccedente i

valori di soglia previsti per gli SLA violati;

- Nel caso di SLA espressi in termini di conteggio degli eventi in violazione di una soglia, la

penale applicabile sarà pari allo 0,5 per mille dell’importo contrattuale associato allo specifico

servizio per ogni unità/evento eccedente la soglia.

- Per quanto riguarda gli SICAPP1-SICAPP20, la penale applicabile sarà pari allo 0,1 per mille

dell’importo contrattuale per ogni giorno di mancato rispetto dello SLA, a partire dalla prima data

nota in cui si è verificato l’evento.

L’ammontare complessivo delle penali applicate può raggiungere un massimo cumulativo pari al 10%

del valore complessivo del contratto.

In funzione dello specifico SLA, come da tabella sinottica, alcune penali potranno essere applicate

solo nel caso in cui il valore assoluto del numero di eventi costituenti l’insieme di calcolo per ciascuna

tipologia di servizio per il trimestre di rilevazione sia superiore ad un numero minimo casi.

14.2. Penali per mancato rispetto degli SLA relativi a cronoprogrammi

Per gli SLA che misurano il rispetto della pianificazione (si veda la tabella sinottica al par. 14.3), per

accertata e univoca responsabilità dell’aggiudicatario, l’importo delle penali è determinato nella misura

giornaliera compresa tra lo 0,3 per mille e l'1 per mille del valore contrattuale della specifica attività a

cui si riferisce il cronoprogramma non rispettato, e comunque per un totale complessivo cumulativo

delle stesse non superiore al dieci per cento dello stesso. Diversamente dalle penali per mancato

rispetto degli SLA tecnici, non sono previste soglie minime quantitative per l’applicazione.

Le penali saranno associate alle principali milestone dei cronoprogrammi, eventualmente accorpate

nel caso di attività particolarmente complesse. Dovrà comunque essere data visibilità dell’insieme di




sotto-milestones cui faranno riferimento le milestones accorpate, in quanto la percentuale utilizzata

per la determinazione della penale sarà determinata in modo proporzionale al numero di sotto-attività

risultanti in ritardo rispetto alla milestone principale. A titolo di esempio:

● se la milestone principale non è composta da milestone secondarie nel piano di progetto, si

applicherà la percentuale minima pari allo 0,3 per mille dell’importo contrattuale associato alla

specifica attività, per ogni giorno di ritardo;

● se la milestone principale è composta da milestone secondarie nel piano di progetto, si

applicherà una percentuale proporzionale al numero di milestone secondarie che sono andate

oltre la milestone principale, fino al massimo dell’1 per mille dell’importo contrattuale associato

alla specifica attività se tutte le milestone secondarie sono risultate in ritardo rispetto alla

milestone principale, per ogni giorno di ritardo.

14.3. Tabella sinottica SLA – Penali

Servizio CodiceSLA Indicatore Valore di soglia Tipo penale

Casi minimiperl'applicabilitàdella penale

A1.1 -ManutenzioneCorrettiva

A1.1-1Tempo medio dirimozione di guasti oerrori bloccanti

Entro 8 ore consecutivedi copertura del servizionel 90% dei casi

0,1 per milledell’importocontrattualeassociato allospecifico servizio perogni puntopercentualeeccedente i valori disoglia

NessunoEntro 16 oreconsecutive nel restante10% dei casi

A1.1-2Tempo medio dirimozione di guasti oerrori non bloccanti

Entro 24 oreconsecutive di coperturadel servizio nel 90% deicasi


10Entro 36 oreconsecutive nel restante10% dei casi

A1.1-3Tempo massimo dirisoluzione degli erroribloccanti

30 ore consecutive

0,5 per milledell’importocontrattualeassociato allospecifico servizio perogni eventoeccedente la soglia

Nessuno

A1.1-4Tempo massimo dirisoluzione degli errorinon bloccanti

130 ore consecutive

0,5 per milledell’importocontrattualeassociato allospecifico servizio perogni evento

Nessuno




eccedente la soglia

A1.1-5 Numero interventi dimanutenzione recidivi Casi rilevati < 3


Nessuno

A1.1 -ManutenzionePreventiva,Adeguativa,Perfettiva

A1.1-6Intervallo medio di presain carico della richiesta dimanutenzione



5<10 giorni lavorativi nelrestante 10% dei casi

A1.1-7





A1.1 -Manutenzionenormativa ordinaria

A1.1-8Intervallo medio di presain carico della richiesta divariazione normativa



Nessuno<10 giorni lavorativi nelrestante 10% dei casi

A1.1-9





A1.2 -Miglioramentodelle performancee dell’usabilità

A1.2-1

Rispetto dei tempi diconsegna dei diversiaggiornamenti delsistema secondo il piano


0,3 per milledell’importocontrattualeassociato allospecifico servizio,per ogni giorno diritardo

5

A1.2-2

Numero interventi diaggiornamento rimossisu richiestadell'amministrazione/DEC

Casi rilevati < 4


Nessuno

A1.3 -ManutenzioneEvolutiva

A1.3-1

Tempo di presa in caricodella richiesta dievoluzione del softwareapplicativo

<5 giorni lavorativi dallarichiesta nel 90% deicasi


5<10 giorni lavoratividalla richiesta nelrestante 10% dei casi

A1.3-2Tempo di presentazionedel documento di analisifunzionale relativo alla

<20 giorni lavoratividalla presa in carico nel90% dei casi

0,5 per milledell’importocontrattuale

5




CR <30 giorni lavoratividalla presa in carico nelrestante 10% dei casi

associato allospecifico servizio perogni eventoeccedente la soglia

A1.3-3

Tempo di presentazionedel piano di sviluppodella CR con descrizionedelle iterazioni,cronoprogramma equantificazioneeconomica

<10 giorni lavoratividall’approvazionedell’analisi funzionalenel 90% dei casi


5<15 giorni lavoratividall’approvazionedell’analisi funzionalenel restante 10% deicasi

A1.3-4

Avvio dell’esecuzione delpiano di sviluppo dellaCR a seguitodell’approvazione dellaDEC

100% del rispetto delladata di avvio previstaper l’avviodell’esecuzione

0,3 per milledell’importocontrattualeassociato allaspecifica attività, perogni giorno di ritardo

5

A1.3-5

Rispetto delle milestonedel piano di sviluppodella CR e dei tempi dirilascio delle singolefunzionalità resedisponibili per ogniiterazione


Tra lo 0,3 e l'1 permille dell’importocontrattualeassociato allaspecifica attività, perogni giorno di ritardo

5

A1.3-6 Casi di test falliti nelcollaudo preliminare

Percentuale di test fallitisu test effettuati <= 10%


Nessuno

A1.4 - ServiziSpecialistico-Applicativi

A1.4-1

Intervallo medio di presain carico della richiesta disupporto specialistico-applicativo remoto

<8 ore lavorative nel90% dei casi


10<16 ore lavorative nelrestante 10% dei casi

A1.4-2 Sostituzione delpersonale <2 risorse


Nessuno

A1.5 - Gestionedegli ambientiapplicativi di test edi produzione

A1.5-1

Intervallo medio per lamessa in esercizio inambiente di test di unanuova Patch/Add/NuovaRelease rilasciata




A1.5-2

Rispetto dei tempi dipreavviso richiesti perinterventi che implicanodisservizi

100%


Nessuno




A1.5-3

Intervallo medio per lamessa in esercizio inambiente di produzionedi una nuovaPatch/Add/NuovaRelease rilasciata




A1.5-4

Tempo di disservizio perla messa in esercizio diuna nuovaPatch/Add/NuovaRelease

<30 ore solari


Nessuno

A1.6 - Gestionesistemistico-applicativa

A1.6-1

Tempo di risoluzionedall’insorgenza delblocco della integrazioneal suo riavvio

< 4 ore


Nessuno

A1.6-2

Disponibilità inproduzione del moduloper la compilazione delmodello 770 perl’annualità di riferimento

Entro 1 mese primadella scadenza dipresentazione delmodello


Nessuno

A1.6-3

Numero massimo dierrori sul Direzionaleinerenti mancatocaricamento dei dati oerrato caricamento deidati

< 5


Nessuno

A1.7 - Servizio diHelp Desk

A1.7-1 Tempo di attesa netto

Il tempo di connessionecon l’operatore nondeve superare i 30secondi.


10

TT1 ≥ 90%.

A1.7-2 Tempo di presa in caricodella richiesta

< 10 min nel 95% deicasi


10

A1.7-3 Numero richieste riaperte < 5%


10

A1.7-4 Tempo di risoluzionedalla presa in carico

Entro 1 giorno lavorativonel 70% dei casi

0,1 per milledell’importocontrattualeassociato allospecifico servizio perogni punto

10Entro 2 giorni lavorativinel restante 30% deicasi




percentualeeccedente i valori disoglia


Entro 2 giorni lavorativinel 70% dei casi











A1.8 - ReperibilitàH24 mission critical

A1.8-1

Tempo medio diintervento da remotodalla presa in carico dellasegnalazione dimalfunzionamento suInfrastruttura Tecnologicae/o Pronto Soccorso e/oTrasfusionale SISaRnella fascia oraria direperibilità H24

<= 1 ora dalla presa incarico dellasegnalazione nel 90%dei casi


5<= 4 ore dalla presa incarico dellasegnalazione nelrestante 10% dei casi

A1.8-2

Tempo medio diintervento in loco dallapresa in carico dellasegnalazione dimalfunzionamento suInfrastruttura TecnologicaSISaR nella fascia orariadi reperibilità H24

<= 4 ore dalla presa incarico dellasegnalazione nel 90%dei casi


5<= 6 ore dalla presa incarico dellasegnalazione nelrestante 10% dei casi

A2.1 - SistemaEnterprise ServiceBus

A2.1-1

Rispetto dei tempi diinstallazione e attivazionedell’infrastrutturaESB/API secondo pianodi progetto



Nessuno

A2.2 - Evoluzionee migrazione sunuova infrastrutturaedisaccoppiamentofunzionale

A2.2-1

Rispetto dei tempi dimigrazione delleintegrazioni esistentisecondo piano diprogetto



Nessuno

A2.2-2

Rispetto dei tempi dirilascio delle nuoveintegrazioni presentatenel piano di progetto



Nessuno




A2.2-3 Casi di test falliti nelcollaudo preliminare

Percentuale di test fallitisu test effettuati <= 10%


10

A3.1 - Transizioneverso il fornitore/isubentrante/i

A3.1-1

Tempo massimo dirilascio del documentoriguardante il piano ditransizione

Secondo le tempistichedi cui al cap. 12


Nessuno

A3.1-2

Tempo massimo dirilascio di tutta ladocumentazioneaggiornata per lapubblicazione della gara

100% dei casi: tutta ladocumentazione tecnicacompleta ed i sorgentiad hoc epersonalizzazioni chesarà consideratanecessaria per lapubblicazione della garadovrà essere rilasciataentro tre mesi dalla datadi richiesta


Nessuno

A3.1-3 Rispetto delle milestonesdel piano di transizione



Nessuno

A4.1 - Program,Project e ServiceManagement

A4.1-1

Tempo massimo dirilascio del documentoriguardante gli SLAtrimestrali

100% dei casi


Nessuno

A4.1-2

Tempo massimo diaggiornamento delportale documentazionesu richiesta del DEC\SA

100% dei casi: tutti ideliverable riportati nelRapporto dei ServiziErogati o nel documentodi SAL dovranno essereregistrati sul portaledocumentazione nellacartella riferita albimestre di riferimento(servizi a corporendicontati a canone) onel SAL (servizi amisura e a corporendicontata a SAL)entro 5 giorni lavoratividalla data di richiestaaggiornamento delPortale documentazione


Nessuno

A4.1-3

Intervallo medio dirisposta alla richiesta dichiarimenti da parte dellaDEC\SA




A4.1-4 Partecipazione alla 100% 0,5 per mille Nessuno




verifica trimestrale SLA eriesame del contratto

Il contract manager, ilprogram manager, tutti iservice manager,dovranno partecipareobbligatoriamente dipersona presso laDirezione Generaledella sanità o comunquepresso un’altra sedelocalizzata in Cagliari

dell’importocontrattualeassociato allospecifico servizio perogni eventoeccedente la soglia

A4.1-5

Partecipazione a riunionidi lavoro, verifiche,raccolta dei requisitiutente

100%


Nessuno

Il program manager e iservice managerdovranno partecipareobbligatoriamente dipersona alle riunioniconvocate con almenouna giornata di anticipoche si svolgerannopresso la DirezioneGenerale della Sanità ocomunque pressoun’altra sede localizzatain Cagliari. Non sarannoconsiderate le assenzedovute acontemporanea attivitàpresso altri utenti eriguardanti i servizioggetto della presenteprocedura

A4.1-6

Consegna eaggiornamento del pianodi progetto complessivogenerale del contratto,secondo le tempistiche dicui al cap. 12

100%


Nessuno

A4.1-7

Consegna eaggiornamento del pianodi qualità, matrice deirischi e documento dellaconfigurazione estandard di progetto,secondo le tempistiche dicui al cap. 12

100%


Nessuno

A4.1-8

Consegna eaggiornamento del pianodella manutenzionepreventiva, secondo letempistiche di cui al cap.12

100%


Nessuno

A4.1-9

Consegna eaggiornamento del pianodella manutenzioneadeguativa e adattativa,secondo le tempistiche dicui al cap. 12

100%


Nessuno

A4.1-10

Consegna eaggiornamento del pianoper la manutenzioneperfettiva, secondo letempistiche di cui al cap.12

100%


Nessuno

A4.1-11

Consegna eaggiornamento del pianodella manutenzioneevolutiva, secondo letempistiche di cui al cap.

100%

0,3 per milledell’importocontrattualeassociato allaspecifica attività, per

Nessuno




12 ogni giorno di ritardo

A4.1-12

Consegna eaggiornamento del pianoper il miglioramento delleperformance e della userexperience, secondo letempistiche di cui al cap.12

100%


Nessuno

A4.1-13

Consegna eaggiornamento del pianoper la fornitura,installazione econfigurazione dellanuova infrastruttura diintegrazione e per lamigrazione edisaccoppiamento deimacrocomponenti delSISaR, secondo letempistiche di cui al cap.12

100%


Nessuno

A4.1-14

Consegna dei risultatidegli audit dell’EnteCertificatore e delservizio interno perl’Assicurazione Qualità

100%


Nessuno

A4.1-15 Rispetto scadenzetemporali dei deliverable 0 giorni


Nessuno

A4.1-16 Qualità delladocumentazione <2 documenti


Nessuno

A4.1-17 Inadeguatezza delpersonale proposto <2 risorse


Nessuno

A4.2 - Formazionee Affiancamento

A4.2-1

Rilascio dei fogli dirilevazione soddisfazioneutente compilati e calcolodegli indici statistici

100% delle sessioni diformazione con ilrilascio dei foglicompilati disoddisfazione utente ecalcolo indici statistici


Nessuno

A4.2-2Numero sessioni diformazioni erogate inparallelo

3 sessionicontemporanee


Nessuno




Sicurezza e GDPR

SICAPP1 Profilazione degli accessiin base al ruolo 100% dei casi

0,1 per milledell’importocontrattuale per ognigiorno di mancatorispetto dello SLA, apartire dalla primadata nota in cui si èverificato l’evento

Nessuno

SICAPP2 Utilizzo di credenzialiuninominali 100% dei casi


Nessuno

SICAPP3

Autenticazione delleutenze tramiteusername/password,SPID o CNS

100% casi


Nessuno

SICAPP4 Utilizzo di passwordsicure 100%


Nessuno

SICAPP5 Mascheratura della basedati 100%


Nessuno

SICAPP6 Encryption dei dati 100%


Nessuno

SICAPP7 Tracciatura degli accessi 100%


Nessuno

SICAPP8 Tracciatura dellemodifiche 100%


Nessuno

SICAPP9Protezione dellecomunicazioniclient/server

100%

0,1 per milledell’importocontrattuale per ognigiorno di mancatorispetto dello SLA, a

Nessuno




partire dalla primadata nota in cui si èverificato l’evento

SICAPP10Archivi separati tra daticomuni e altre categoriedi dati

100%


Nessuno

SICAPP11

Installazione patch disicurezza dellainfrastruttura software delsistema

100%


Nessuno

SICAPP12 Programma di backup deidati 100%


Nessuno

SICAPP13 Programma di backupdelle configurazioni 100%


Nessuno

SICAPP14 Protezione / cifratura deibackup 100%


Nessuno

SICAPP15 Programma di test deirestore 100%


Nessuno

SICAPP16 Protezione/ cifratura delcanale di comunicazione 100%


Nessuno

SICAPP17 Nomina del DPO 100%


Nessuno




SICAPP18 Nomina degli incaricati 100%


Nessuno



Nessuno



Nessuno

15. PROPRIETÀ DEL SOFTWARE

Per quanto concerne la proprietà di software, si applica la disciplina prevista in merito dallo “Schema

di contratto”. A titolo di richiamo non esaustivo, si ricorda che tutto il software consegnato, sviluppato,

modificato, integrato resterà di piena proprietà della Regione Autonoma della Sardegna. Le licenze di

nuovi prodotti infrastrutturali di base, come p.e. l’ESB, dovranno essere illimitate in termini di tempo,

illimitate per numero di installazioni ed istanze necessarie al funzionamento del sistema, illimitate per

numero di Aziende Sanitarie della Regione Sardegna, illimitate per numero di utenti utilizzatori. Le

versioni dei prodotti forniti su licenza dovranno essere aggiornate secondo roadmap del produttore

opportunamente comunicate alla DEC.

16. SPESE, OBBLIGHI, ONERI, RISCHI E RESPONSABILITÀ

L’aggiudicatario esecutore del contratto è tenuto ad eseguire le prestazioni affidate con la massima

diligenza e attenzione ed è responsabile del buon andamento dell’esecuzione del contratto e del

comportamento dei propri dipendenti nell’erogazione dei servizi.

A carico dell’aggiudicatario, e considerate come remunerate dall’importo offerto, saranno tutte le

spese inerenti tutte le prestazioni richieste e necessarie per la buona, corretta e completa esecuzione

del contratto e per tutte le prestazioni strumentali, ulteriori e alle condizioni migliorative eventualmente

offerte, comprese le spese relative a tutti beni da fornire, nonché i materiali, le attrezzature, le

macchine e gli strumenti necessari, le spese di trasferta, trasporto, tutte le spese generali, gli oneri

fiscali, nonché gli oneri derivanti e necessari alla stipula del contratto.




In riferimento all’aggiudicatario, si comproverà l’assolvimento degli obblighi di regolarità contributiva (o

la motivata esenzione) e la regolarità fiscale, anche dopo la stipula del contratto e comunque prima di

ogni pagamento.

Sono a carico dell’aggiudicatario tutti i rischi connessi al trasporto di persone o cose e delle

attrezzature e dei materiali necessari all’esecuzione del contratto.

L’aggiudicatario garantisce che nell’offerta e nell’esecuzione dell’appalto non viola e non violerà diritti

di proprietà industriale e intellettuale ed è unico responsabile di ogni irregolarità, inadempimento o

contenzioso in merito. L’Amministrazione Aggiudicatrice è indenne da ogni pretesa da chiunque

avanzata a tale titolo, sopportando l’aggiudicatario in proprio e in via esclusiva tutte le azioni, gli oneri

e le spese conseguenti.

L’aggiudicatario ha l’obbligo di trattare i dati e le informazioni che entreranno in suo possesso secondo

quanto disposto dal GDPR e D.Lgs. 196/2003 e avrà l’obbligo di mantenere riservati i dati e le

informazioni, ivi comprese quelle che transiteranno per le apparecchiature di elaborazione dati, di cui

verrà in possesso e di non divulgarli in alcun modo e in qualsiasi forma e di non farne oggetto di

utilizzazione a qualsiasi titolo per scopi diversi da quelli strettamente necessari all’esecuzione del

contratto.

L’obbligo di cui sopra sussisterà, altresì, relativamente a tutto il materiale e i dati originari o quelli

predisposti, raccolti o trattati in esecuzione delle attività affidate.

Tale obbligo non riguarderà i dati che siano o divengano di pubblico dominio, nonché le idee, le

metodologie e le esperienze tecniche che l’aggiudicatario svilupperà o realizzerà in esecuzione delle

prestazioni dovute.

L’aggiudicatario è responsabile per l’esatta osservanza da parte dei propri dipendenti, consulenti e

collaboratori, nonché dei propri eventuali subappaltatori e dei dipendenti, consulenti e collaboratori di

questi ultimi, degli obblighi di riservatezza anzidetti.

In caso di inosservanza degli obblighi di riservatezza, è prevista la risoluzione di diritto del contratto,

fermo restando che l’aggiudicatario sarà tenuto a risarcire tutti i danni che dovessero derivare da tale

inosservanza.

L’aggiudicatario potrà citare i termini e riferimenti essenziali del contratto laddove ciò fosse condizione

necessaria per la partecipazione a gare e procedure di affidamento di contratti.




17. VERIFICA DI CONFORMITÀ - COLLAUDO FUNZIONALE E ACCETTAZIONE

La verifica di conformità delle forniture e prestazioni sarà operata nei modi e termini di legge. In

considerazione della complessità dei servizi e delle forniture oggetto del contratto, la verifica di

conformità finale potrà essere prodotta entro un termine di 12 mesi dalla data di conclusione della fase

esecutiva del contratto, incluse eventuali proroghe.

Precisamente, per quanto attiene i rilasci delle forniture software che saranno realizzate nell’ambito

del servizio di manutenzione evolutiva del software applicativo SISaR, le verifiche di conformità

saranno effettuate in ambiente di test entro 30 giorni dal rispettivo rilascio. L’aggiudicatario dovrà

predisporre l’ambiente per i test in ambiente di test e comunicare il “pronti al collaudo”. La DEC e

l’aggiudicatario stabiliranno la data e l’ora del collaudo comunicandolo al RUP. In tale data, alla

presenza degli incaricati per la verifica della DEC e del rappresentante dell'aggiudicatario, si

procederà all’esame della conformità delle forniture e delle prestazioni.

Tutti i prodotti rilasciati sono sottoposti a unit test, no regression test, integration test e system test.

Per quanto riguarda i test utente, questi sono effettuati direttamente da personale di riferimento

dell’Amministrazione Aggiudicatrice su sessioni dedicate nell’ambito delle attività di manutenzione

evolutiva. Per tali sessioni l’aggiudicatario predisporrà dei casi di test specifici che la DEC potrà

ampliare o modificare. Alle sessioni di test utente potranno partecipare rappresentanti dell’ufficio del

RUP e utenti delle Aziende Sanitarie, oltre alla Direzione dell’Esecuzione. Al fine di rappresentare uno

strumento il più possibile “agile” ed utile per l’esecuzione dei test, verrà prodotto, per ciascun oggetto

sviluppato nell’ambito del Progetto, il documento Piano dei Test e il rapporto attestante l’esito

dell’esecuzione dei test.

Per quanto concerne le manutenzioni perfettive, si richiama il processo di verifica di cui al cap. 3.1.4.

Nel caso in cui un prodotto rilasciato non superi in tutto od in parte l'esame di conformità e pertanto

non risulti perfettamente funzionante in ogni parte, l’aggiudicatario è obbligato a provvedere in merito

alla risoluzione delle difformità riscontrate e a stabilire le condizioni di collaudabilità e corretto

funzionamento della fornitura entro 5 giorni, periodo al termine del quale l’Amministrazione

Aggiudicatrice provvederà all’esecuzione di nuovo esame di conformità. Esiti negativi successivi

verranno considerati come errori bloccanti gravi che incideranno nel calcolo dello SLA A1.1-1.

Nel caso di terzo esito negativo, conseguente alle verifiche di conformità e regolare funzionamento,

l’Amministrazione Aggiudicatrice ha facoltà di dichiarare la risoluzione di diritto del contratto.

Per quanto attiene le prestazioni inerenti ai servizi ricorrenti a canone, la cui rendicontazione segue

una cadenza bimensile (Rapporto di erogazione servizi bimestrali), la rispettiva verifica di conformità

sarà effettuata entro 30 giorni dalla presentazione del rapporto mensile di erogazione dei servizi




bimestrale –, trascorsi i quali, in assenza di segnalazione di non conformità ovvero di riscontro, le

prestazioni si potranno considerare accettate.

La verifica di conformità con esito positivo, approvata dal RUP, determina l’accettazione definitiva

delle prestazioni e il diritto al pagamento totale del corrispettivo.

18. VARIAZIONI IN CORSO D’OPERA

L’aggiudicatario non può introdurre variazioni alla fornitura non disposte dall’Amministrazione

Aggiudicatrice; le modifiche non previamente autorizzate non danno titolo a pagamenti o rimborsi di

sorta, ed anzi l’Amministrazione potrà richiederne l’immediata rimozione a spese dell’aggiudicatario,

rivalendosi in caso di eventuale danno causato. L’applicazione di variazioni non richieste è causa di

risoluzione del contratto.

L'aggiudicatario è tenuto viceversa a effettuare le variazioni ordinate dall’Amministrazione

Aggiudicatrice, nelle ipotesi, con i limiti e alle condizioni stabilite dal contratto e dalla legge.

PRESIDÈNTZIA PRESIDENZA

Documents

Transcript of PRESIDÈNTZIA PRESIDENZA