CIG: 7686214073 - CUP: E77H18001780002

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 di integrazione

SISaR 2.0.

CIG: 7686214073 - CUP: E77H18001780002

Allegato 1.A

Capitolato speciale, descrittivo e prestazionale

1. PREMESSA 3

1.1. Il sistema SISaR 4

1.2. ACRONIMI 17

2. OGGETTO DELLA PROCEDURA 19

2.1. Fasi del progetto e durata 20

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

2.3. Linee guida Usabilità 23

2.4. Metodologie di sviluppo software e gestione di progetto 25

2.4.1 Aspetti metodologici specifici relativi alla protezione dei dati personali 26

2.5. Open Data e formato dei dati 27

2.5.1 Formato dei dati 28

3. AREA 1 – SERVIZI DI GESTIONE E MANUTENZIONE 28

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

3.1.1 Manutenzione preventiva 29

3.1.2 Manutenzione adeguativa e adattativa 30

3.1.3 Manutenzione correttiva 34

3.1.4 Manutenzione perfettiva 36

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

3.3. Servizio A1.3: Manutenzione Evolutiva 41

3.4. Servizio A1.4: Servizi Specialistico-Applicativi 46

3.5. Servizio A1.5: Gestione degli ambienti applicativi di test e di produzione 49

3.6. Servizio A1.6: Gestione sistemistico-applicativa 52

3.7. Servizio A1.7: Servizio di Help Desk 56

3.8. Servizio A1.8: Reperibilità H24 mission critical 58

4. AREA 2 – REALIZZAZIONE NUOVA ARCHITETTURA 59

4.1. Servizio A2.1: Sistema Enterprise Service Bus 60

4.1.1 Descrizione della infrastruttura richiesta / servizio 61

4.1.2 Caratteristiche specifiche della componente ESB 62

4.1.3 Caratteristiche specifiche della componente API Gateway 64

4.1.4 Requisiti generici comuni per ESB/API 65

4.1.5 Requisiti di sicurezza comuni per ESB/API 66

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

4.2.1 Migrazione delle attuali integrazioni sul nuovo ESB/API 67

4.2.2 Disaccoppiamento delle macrocomponenti del SISaR 67

5. AREA 3 – SERVIZI DI TRANSIZIONE 75

5.1. Servizio A3.1: Transizione verso il fornitore/i subentrante/i 76

6. AREA 4. SERVIZI TRASVERSALI 79

6.1. Servizio A4.1: Program, Project e Service Management 80

6.2. Servizio A4.2: Formazione e Affiancamento 82

7. PASSAGGIO DI CONSEGNE “IN INGRESSO” E PRESA IN CARICO DALL’ATTUALE GESTORE DEL SISTEMA 84

8. ASPETTI RELATIVI AL GDPR E TRATTAMENTO DEI DATI PERSONALI 88

9. ORGANIZZAZIONE DI PROGETTO 89

10. Strumenti di supporto 94

11. DELIVERABLES 97

12. MODALITÀ DI ESECUZIONE 100

13. SLA – LIVELLI DI SERVIZIO E OBBLIGHI DELL’AGGIUDICATARIO 101

13.1. Metodo di calcolo degli SLA 102

13.2. Manutenzione Correttiva 103

13.3. Manutenzione Preventiva, Adeguativa, Perfettiva 104

13.4. Manutenzione per adeguamenti normativi ordinari 105

13.5. Servizi per il miglioramento delle performance e dell’usabilità 106

13.6. Servizi di Manutenzione Evolutiva 106

13.7. Servizi Specialistico-Applicativi 108

13.8. Gestione ambiente applicativo di test 108

13.9. Gestione ambiente applicativo di produzione 109

13.10. Gestione sistemistico-applicativa 110

13.11. Help Desk 110

13.12. Reperibilità H24 mission critical 112

13.13. Realizzazione nuova infrastruttura interoperabilità 113

13.14. Evoluzione e migrazione su nuova infrastruttura e disaccoppiamento funzionale 113

13.15. Transizione verso il fornitore subentrante 114

13.16. Program/Project/Service Management 114

13.17. Formazione e affiancamento 117

13.18. Livelli di servizio Sicurezza/GDPR 117

14. PENALI 119

14.1. Penali per mancato rispetto degli SLA 120

14.2. Penali per mancato rispetto degli SLA relativi a cronoprogrammi 120

14.3. Tabella sinottica SLA – Penali 121

15. PROPRIETÀ DEL SOFTWARE 131

16. SPESE, OBBLIGHI, ONERI, RISCHI E RESPONSABILITÀ 131

17. VERIFICA DI CONFORMITÀ - COLLAUDO FUNZIONALE E ACCETTAZIONE 133

18. 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\Moduli

AMC

Contabilità Generale

Contabilità Analitica

Controllo di Gestione

Approvvigionamenti: Acquisiti e Contratti

Logistica: Magazzini/Xxxxxxx, Xxxxxxxxx Approvvigionamento, Armadietto di Reparto

Gestione Attrezzature e Manutenzioni

HR

Trattamento Giuridico

Gestione Dotazione Organica

Gestione Economica e Contributiva

Gestione Presenze e Assenze (Rilevazione Presenze)

Gestione Pensioni

Gestione Concorsi e Selezioni

Gestione Fondi

Dichiarazioni 770

Portale del Dipendente (Intranet del Personale SSR)

PD

Protocollo Informatico

Atti Amministrativi

Gestione Documentale

SIO (Ospedaliero)

Anagrafe

ADT e Liste di Attesa

Pronto Soccorso + OBI + Monitor Pronto Soccorso

Order Entry di Prestazioni

Sale Operatorie

Trasfusionale

SRC (ex CRCC) + componente Broker Esami

EMR – 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)

Consultorio

CSS Cartella Socio-Sanitaria

PUA-Punto Unico di Accesso

ADI-Assistenza Domiciliare Integrata

Medicina dello Sport

Medicina Legale

SPRESAL-Servizio Prevenzione e Sicurezza negli ambienti di vita e di Lavoro

SISP-Servizio Igiene e Sanità Pubblica

SIAN-Servizio Igiene degli Alimenti e della Nutrizione

RSA-Gestione attività residenziali e semi-residenziali

Protesica

Portale Prevenzione: Portale Notifica Preliminare dei Cantieri e Portale Amianto

CUP

CUP – SGP

E-Prescription

CUPWEB

Ambulatorio – Cartella Clinica Ambulatoriale

DIR

Strumento ETL: Talend Open Studio

Flussi ETL

Datawarehouse

Strumento di BI: SpagoBI

Report ed Indicatori

EPI (Epidemiologico)

CEDAP-Certificato di Assistenza al Parto

RENCAM-Registro Nominativo elle Cause di Morte

SIDI

Sistema Integrato Debito Informativo

Accesso al Sistema e CDA

Sistema di accesso SSO, tramite CNS, produzione dei documenti sanitari firmabili digitalmente

Integrazioni

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

Integrazioni intra-SISaR

Middleware 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 ed Epidemiologico	Allegato 1.B - Descrizione sistema territoriale – AAP
Sistema Informativo Ospedaliero	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 Debiti Informativi	Allegato 1.G - Descrizione sistema debito informativo
Infrastruttura HW e SOFTWARE di base	Allegato 1.H - Descrizione infrastruttura

MU - MANUALI UTENTE
MODULO	Titolo documento	Nome File
TER-Territoriale
Medicina dello Sport	Allegato 001 – Modulo Medicina dello Sport - 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
Assistenza Domiciliare Integrata	Allegato 003 – Modulo Assistenza Domiciliare - 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_PUA Cartella Socio-Sanitaria - Manuale Utente	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
Medicina Legale e INPS	Allegato 007 – Modulo Medicina Legale e INPS - Manuale Utente	All.007_MU_SISAR_TER_MLG_V.1.0
Punto Unico di Accesso	Allegato 008 – Modulo AAP_PUA Punto unico di Accesso - Manuale Utente	All.008_MU_SISAR_TER_PUA_V.1.0
Residenza Sanitaria Assistenziale	Allegato 009 – Modulo AAP_PUA RSA - Manuale Utente	All.009_MU_SISAR_TER_RSA_V.1.0
Alimenti e Nutrizione	Allegato 011 – Modulo SIAN - Manuale Utente	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 - Manuale Utente	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_C OMM_RL_v.1.0
NPC WEB - ASSL-Spresal e DTL	Allegato 080 – Modulo NPC WEB - Manuale Utente ASSL-Spresal e DTL	All.080_MU_SISaR_AAP_PORTALE_NPCWEB_S PRESAL_ITL_v.1.0
Portale del Cittadino	Allegato 077 – Modulo Portale del Cittadino - Manuale Utente	All.077_MU_SISaR_PORTALE_CITTADINO_v.1.0. doc
EPI - Epidemiologico
Registro Nominativo Cause 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 – Ospedaliero
ADT	Allegato 064 – Modulo ADT - Manuale Utente	All.64_MU_SISAR_SIO_ADT_V.1.1
EMR	Allegato 067 – Modulo EMR - Manuale Utente	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
Pronto Soccorso	Allegato 070 – Modulo Pronto Soccorso - Manuale Utente	All.070_MU_SISAR_SIO_PS_V.1.0
Sale Operatorie	Allegato 071 – Modulo Sale Operatorie - Manuale Utente	All.071_MU_SISAR_SIO_SO_V.1.0
SRC	Allegato 076 – Modulo SRC - Manuale Utente	All.076_MU_SISAR_SRC_v_1.0
ELIOT_TRASF USIONALE	Allegato 082 – Xxxxxx XXXXX_XXXXXXXXXXXXX - Manuale Utente	All.82_MU_SISAR_ELIOT_TRASFUSIONALE_v_1 .0
AMC – Amministrazione e Controllo
Gestione Appalti e Contratti	Allegato 014 – Modulo AMC Gestione Appalti e Contratti - Manuale Utente	All.014_MU_SISAR_AMC_Acquisti_e_Logistica_G estione_Appalti_Contratti_v_1.0
AVCP Legge 190 ATS	Allegato 015 – Modulo AMC AVCP Legge 190 ATS - Manuale Utente	All.015_MU_SISAR_AMC_AVCP_Legge 190_ATS_v_1.0
Automatismo Interazione HR-AMC	Allegato 016 – Modulo AMC Automatismo Interazione HR-AMC - Manuale Utente	All.016_MU_SISAR_AMC_Automatismo_Interazion e_AMC_HR_v_1.0
Avvisi di pagamento	Allegato 017 – Modulo AMC Avvisi di pagamento - Manuale Utente	All.017_MU_SISAR_AMC_Avvisi di pagamento_v_1.0
Cassa Economale	Allegato 018 – Modulo AMC Cassa Economale - Manuale Utente	All.018_MU_SISAR_AMC_Cassa Economale_v_1.0
Cespiti	Allegato 019 – Modulo AMC_Cespiti - Manuale Utente	All.019_MU_SISAR_AMC_Cespiti_v_1.0
Controllo di gestione	Allegato 020 – Modulo AMC Controllo di gestione - Manuale Utente	All.020_MU_SISAR_AMC_Controllo di gestione_v_1.0
AMC_EDF	Allegato 021 – Modulo AMC_EDF - Manuale Utente	All.021_MU_SISAR_AMC_EDF_v_1.0
Fatturazione attiva	Allegato 022 – Modulo AMC Fatturazione attiva - Manuale Utente	All.022_MU_SISAR_AMC_Fatturazione attiva_v_1.0
Gestione Alias	Allegato 023 – Modulo AMC Gestione Alias - Manuale Utente	All.023_MU_SISAR_AMC_Gestione Alias_v_1.0
Gestione armadietti di reparto	Allegato 024 – Modulo AMC Gestione armadietti di reparto - Manuale Utente	All.024_MU_SISAR_AMC_Gestione Armadietti di reparto_v_1.0
Gestione conto deposito	Allegato 025 – Modulo MU AMC Gestione conto deposito - Manuale Utente	All.025_MU_SISAR_AMC_Gestione conto deposito_v_1.0
Gestione contratti	Allegato 026 – Modulo MU AMC Gestione contratti - Manuale Utente	All.026_MU_SISAR_AMC_Gestione Contratti _v_1.0
Gestione contratti centralizzati ATS	Allegato 027 – MU AMC Gestione contratti centralizzati ATS - Manuale Utente	All.027_MU_SISAR_AMC_Gestione contratti centralizzati_ATS_v_1.0
Gestione inventario	Allegato 028 – MU AMC Gestione inventario - Manuale Utente	All.028_MU_SISAR_AMC_Gestione inventario_v_1.0
Gestione manutenzioni ed elettromedicali	Allegato 029 – Modulo AMC Gestione manutenzioni ed elettromedicali - Manuale Utente	All.029_MU_SISAR_AMC_Gestione manutenzioni ed elettromedicali_v_1.0
Gestione ordinativi	Allegato 030 – Modulo AMC Gestione ordinativi - Manuale Utente	All.030_MU_SISAR_AMC_Gestione ordinativi_v_1.0
Gestione parametri ADMINISTRAT OR	Allegato 031 – Modulo AMC Gestione parametri ADMINISTRATOR - Manuale Utente	All.031_MU_SISAR_AMC_Gestione parametri ADMINISTRATOR_v_1.0
Gestione ordini	Allegato 032 – Modulo AMC Gestione ordini - Manuale Utente	All.032_MU_SISAR_AMC_Gestione_ordini_v_1.0

Impostazioni Login	Allegato 033 – Modulo AMC Impostazioni Login - Manuale Utente	All.033_MU_SISAR_AMC_Impostazioni Login_v_1.0
Liquidazione Documenti Workflow	Allegato 034 – Modulo AMC Liquidazione Documenti Workflow - Manuale Utente	All.034_MU_SISAR_AMC_Liquidazione documenti_Workflow_v_1.0
Logistica movimenti di magazzino	Allegato 035 – Modulo AMC Logistica movimenti di magazzino - Manuale Utente	All.035_MU_SISAR_AMC_Logistica_Movimenti di magazzino_v_1.0
Movimenti contabili	Allegato 036 – Modulo AMC Movimenti contabili-- - Manuale Utente	All.036_MU_SISAR_AMC_Movimenti contabili_v_1.0
Operazioni fine esercizio	Allegato 037 – Modulo AMC Operazioni fine esercizio - Manuale Utente	All.037_MU_SISAR_AMC_Operazioni fine esercizio_v_1.0
Gestione progetti	Allegato 038 – Modulo AMC Gestione progetti - Manuale Utente	All.038_MU_SISAR_AMC_Progetti_v_1.0
Report multi- utilità	Allegato 039 – Modulo AMC Report multi-utilità - Manuale Utente	All.039_MU_SISAR_AMC_Report Multi Utilità_v_1.0
Richieste approvvigiona mento Centro di consegna	Allegato 040 – Modulo AMC Richieste approvvigionamento Centro di consegna - Manuale Utente	All.040_MU_SISAR_AMC_Richieste di approvvigionamento centro di consegna_v_1.0
Sistema autorizzativo	Allegato 041 – Modulo AMC Sistema autorizzativo - Manuale Utente	All.041_MU_SISAR_AMC_Sistema Autorizzativo_v_1.0
Storicizzazione avvisi di pagamento	Allegato 042 – Modulo AMC Storicizzazione avvisi di pagamento - Manuale Utente	All.042_MU_SISAR_AMC_Storicizzazione avvisi di pagamento_v_1.0
Workflow Anagrafica farmaci	Allegato 043 – Modulo AMC Workflow Anagrafica farmaci - Manuale Utente	All.043_MU_SISAR_AMC_Workflow_Anagrafica farmaci_v_1.0
Workflow Anagrafica soggetti	Allegato 044 – Modulo AMC Workflow Anagrafica soggetti - Manuale Utente	All.044_MU_SISAR_AMC_Workflow_Anagrafica soggetti_v_1.0
HR – Risorse Umane
HR Denunce	Allegato 056 – Modulo HR Denunce - Manuale Utente	All.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
HR Centralizzato e Giuridico	Allegato 058 – Modulo HR Centralizzato e Giuridico - Manuale Utente	All.058_MU_SISAR_HRCE_Centralizzato_Giuridic o_v1
HR Concorsi e Selezioni	Allegato 059 – Modulo HR Concorsi e Selezioni - Manuale Utente	All.059_MU_SISAR_HRCN_Concorsi_e_Selezioni _V.1.0
HREX Esportazione Dati	Allegato 060 – Modulo HREX Esportazione 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
HRPW Gestione Economica del Personale	Allegato 062 – Modulo HRPW Gestione Economica del Personale - Manuale Utente	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
Portale Dipendente	Allegato 078 – Modulo Portale Dipendente - Manuale Utente	All.078_MU_SISaR_PORTALE_DEL_DIPENDENT E_v.1.0
PD – Protocollo, Atti e Documentale
Atti Amministrativi	Allegato 072 – Modulo Atti Amministrativi - Manuale Utente	All.072_MU_SISAR_PD_Atti_Amministrativi_v_1.0
Protocollo Informatico	Allegato 073 – Modulo Protocollo Informatico - 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 Utente
CUP – Gestore Risorse CUP
Ripartizione Proventi	Allegato 045 – Modulo Ripartizione Proventi - 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 - Libera Professione	Allegato 049 – Modulo CUPWEB - Libera Professione - Manuale Utente	All.049_MU_SISAR_CUP_LIBERA PROFESSIONE_V1.0
CUP- Backoffice	Allegato 050 – Modulo CUP-Backoffice - Manuale Utente	All.050_MU_SISAR_CUP-BACKOFFICE_V.1.0
CUP-Liste D’Attesa	Allegato 051 – Modulo CUP-LDA - Manuale Utente	All.051_MU_SISAR_CUPLDA_V.1.0
CUPWEB configurazione utenze e uffici	Allegato 052 – CUPWEB configurazione utenze e uffici - Manuale Utente	All.052_MU_SISAR_CUPWEB_Configurazione_Ut enzeUffici_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 (Cartella Clinica Ambulatoriale)	Allegato 065 – Modulo Ambulatorio - Manuale Utente	All.65_MU_SISAR_SIO_AMB_V.1.0
DIR – Direzionale
DWSISAR - Sistema direzionale	Allegato 075 – Modulo DWSISAR - Sistema direzionale SISaR - Manuale Utente	All.075_MU_SISaR_DWSISAR - Sistema direzionale SiSaR_v_1.0
SIDI - Sistema Integrato del Debito Informativo
SIDI	Allegato 081 – Modulo SIDI - Manuale Utente	All.081_MU_SISAR_SIDI_Sistema_Integrato_Debit o_Informativo_RAS_v_2.0
Portale documentazione di progetto
Portale documentazion e di progetto	Allegato 199 – Intranet di progetto SISaR - Portale documentazione Manuale Utente	All.199_MU_Intranet_Progetto_v_2.2

MT - MANUALI TECNICI
MODULO	Titolo Documento	Nome File
TER – 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 - Manuale Tecnico	All.127_MT_SISAR_SISP_V.1.0
SPRESAL	Allegato 128 – Modulo SPRESAL -	All.128_MT_SISAR_SPRESAL_1.1

	Manuale Tecnico
ADI	Allegato 129 – Modulo ASSISTENZA DOMICILIARE - Manuale Tecnico	All.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 Cartella Socio-Sanitaria	Allegato 131 – Modulo AAP - CSS Cartella Socio-Sanitaria - Manuale Tecnico	All.131_MT_SISAR_TER_CSS_V.1.1
Medicina Legale	Allegato 132 – Modulo Medicina Legale - Manuale Tecnico	All.132_MT_SISAR_TER_MLE_V.1.2
PUA	Allegato 133 – Modulo PUA - Manuale Tecnico	All.133_MT_SISAR_TER_PUA_V.1.1
RSA	Allegato 134 – Modulo AAP - PUA RSA - Manuale Tecnico	All.134_MT_SISAR_TER_RSA_V.1.1
Portale Notifica Preliminare Cantieri	Allegato 114 – Portale Notifica Preliminare Cantieri - Manuale Tecnico	All.114_MT_SISaR_PORTALE_NPC_v.1.0
Portale del Cittadino	Allegato 115 – Portale del Cittadino - Manuale Tecnico	All.115_MT_SISaR_PORTALE_CITTADINO_v.1.0
EPI – Epidemiologico
CEDAP	Allegato 102 – Modulo Certificato di Assistenza al Parto - Manuale Tecnico	All.102_MT_SISAR_CEDAP_V.1.1
RENCAM	Allegato 103 – Modulo applicativo RENCAM - Manuale Tecnico	All.103_MT_SISAR_TER_RENCAM_V.1.1
SIO – Ospedaliero
ADT - Lista d’attesa e Gestione ricoveri	Allegato 119 – Modulo ADT - Lista d’attesa e Gestione ricoveri - Manuale Tecnico	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 Pronto Soccorso - Manuale Tecnico	All.122_MT_SISAR_PSWEB_V.1.2
Sale Operatorie	Allegato 123 – Modulo SIO - Sale Operatorie - Manuale Tecnico	All.123_MT_SISAR_SOWEB_1.1
Trasfusionale ELIOT	Allegato 099 - Modulo applicativo CTELIOT - Manuale Tecnico	All.099_MT_SISAR_ELIOT_TRASFUSIONALE_v_ 1.0
Eliot SRC - Configuratore	Allegato 100 – Modulo applicativo Eliot SRC - Configuratore - Manuale Tecnico	All.100_MT_SISAR_SRC_SISTEMA_REGIONALE _ORCHESTRAZIONE_ESAMI_v_1.0
Tabelle generalizzate per l’applicativo ELIOT	Allegato101 - Modulo applicativo Eliot Software 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 Controllo
BUDGET	Allegato 083 – Modulo AMCBD - BUDGET - Manuale Tecnico	All.083_MT_SISAR_AMCBD_BUDGET_v_1.0
CENTRALIZZAT O	Allegato 084 – Modulo AMCCE - CENTRALIZZATO - Manuale Tecnico	All.084_MT_SISAR_AMCCE_CENTRALIZZATO_v _1.0
CONTABILITA	Allegato 085 – Modulo AMCCO - CONTABILITA AMC - Manuale Tecnico	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 DI GESTIONE	Allegato 087 – Modulo AMCGE - CONTROLLO DI GESTIONE AMC - Manuale Tecnico	All.087_MT_SISAR_AMCGE_CONTROLLO_DI_G ESTIONE_v_1.0
LOGISTICA	Allegato 088 – Modulo AMCMA - LOGISTICA AMC - Manuale Tecnico	All.088_MT_SISAR_AMCMA_LOGISTICA_v_1.0

ANAGRAFICHE CENTRALIZZAT E	Allegato 089 – Modulo XMPI – ANAGRAFICHE CENTRALIZZATE Manuale Tecnico	All.089_MT_SISAR_XMPI_ANAGRAFICHE_CENT RALIZZATE_v_1.0
ACQUISTI	Allegato 090 – Modulo AMCAQ - ACQUISTI - Manuale Tecnico	All.090_MT_SISAR_AMCAQ_ACQUISTI_v_2.0
HR – Risorse Umane
Candidati	Allegato 104 – Modulo HR Candidati - Manuale Tecnico	All.104_MT_SISAR_HR_Candidati_v_1.0
Concorsi e selezioni	Allegato 105 – Modulo HR Concorsi e selezioni - Manuale Tecnico	All.105_MT_SISAR_HR_Concorsi e selezioni_v.1.0
HR Centralizzato e Giuridico	Allegato 106 – Modulo HR Centralizzato e Giuridico - Manuale Tecnico	All.106_MT_SISAR_HRCE_HRGR_v_1.0
Gestione giuridica del personale. Modulo Concorsi e Selezioni	Allegato 107 – Gestione giuridica del personale. Modulo Concorsi e Selezioni - 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
HREX Esportazione Dati	Allegato 109 – Modulo HREX Esportazione Dati - Manuale Tecnico	All.109_MT_SISAR_HREX_v_1.0
Giuridico e Capitale Umano - Sistema di formazione	Allegato 110 – Modulo Giuridico e Capitale Umano - Sistema di formazione - 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 - Gestione Integrazione	Allegato 113 – Modulo HR Stipendi - Gestione Integrazione - Manuale Tecnico	All.113_MT_SISAR_HRST_v_1.0
Portale del Dipendente	Allegato 116 – Portale del Dipendente - Manuale Tecnico	All.116_MT_SISaR_PORTALE_DEL_DIPENDENT E_v.1.0
PD – Protocollo, Atti e Documentale
Documentale Auriga	Allegato 091 – Modulo Documentale Auriga - Manuale Tecnico	All.091_MT_SISAR_PD_Documentale_v_1.0
Protocollo Informatico	Allegato 092 – Modulo Protocollo Informatico - Manuale Tecnico	All.092_MT_SISAR_PD_Protocollo_Informatico_v_ 1.0
Atti Amministrativi	Allegato 093 – Modulo Atti Amministrativi - Manuale Tecnico	All.093_MT_SISAR_PD_Atti_Amministrativi_v_1.0
CUP – Gestore Risorse CUP
CUPWEB-Cassa Ticket	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 - LIBERA PROFESSIONE	Allegato 096 – MODULO CUPWEB - LIBERA PROFESSIONE Manuale Tecnico	All.096_MT_SISAR_LIPRO_V1.1
SIO – PRODUCER	Allegato 097 – MODULO SIO – PRODUCER - Manuale Tecnico	All.097_MT_SISAR_PRODUCER_1.1
Cartella Clinica Ambulatoriale	Allegato 098 – MODULO Gestione dell’Attività Ambulatoriale - Manuale Tecnico	All.098_MT_SISAR_AMB_V.1.2
DIR – Direzionale
DWSISAR - Sistema direzionale	Allegato 135 - Modulo applicativo DWSISAR - Sistema direzionale SiSaR - Manuale Tecnico	All.135_MT_SISaR_DWSISAR - Sistema direzionale SiSaR_v_1.0

SIDI - Sistema Integrato del Debito Informativo
SIDI	Allegato 117 – Sistema Integrato Debito 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 File
TER - 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 – Xxxxxx ASSISTENZA DOMICILIARE - 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 - Analisi Funzionale	All.142_SISAR_ FUNZIONALE_PUA_v_1.0
RSA	Allegato 144 – Modulo RSA (RESIDENZE SANITARIE ASSISTENZIALI) - Analisi Funzionale	All.144_SISAR_ FUNZIONALE_RSA_v_1.0
SISP	Allegato 145 – Modulo SISP - Analisi Funzionale	All.145_SISAR_ FUNZIONALE_SISP_v_1.0
SPRESAL	Allegato 146 – Modulo TERRITORIALE - SPRESAL - Analisi Funzionale	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
MEDICINA DELLO SPORT	Allegato 149 – Modulo MEDICINA DELLO SPORT - Analisi Funzionale	All.149_SISAR_FUNZIONALE_MEDICINADELLOS PORT_v_1.0
Medicina Legale	Allegato 150 – Modulo MLE (Medicina Legale) - Analisi Funzionale	All.150_SISAR_FUNZIONALE_MLE_v_2.0
EPI – Epidemiologico
RENCAM	Allegato 143 – Modulo RENCAM - Analisi Funzionale	All.143_SISAR_ FUNZIONALE_RENCAM_v_1.0
CEDAP	Allegato 171 – MODULO Certificato di Assistenza al Parto - Analisi Funzionale	All.171_SISAR_ FUNZIONALE_CEDAP_v_1.0
SIO – Ospedaliero
EMR	Allegato 193 – Modulo Cartella Clinica - Analisi Funzionale	All.193_AF_SISAR_EMR_v.1.0
Order Entry	Allegato 194 – Modulo SIO-OEP - Analisi Funzionale	All.194_AF_SISAR_OEP_v.1.0
PRONTO SOCCORSO	Allegato 195 – Modulo SIO - PRONTO SOCCORSO - Analisi Funzionale	All.195_AF_SISAR_PSWEB_v.2.1
SALE OPERATORIE	Allegato 196 – Xxxxxx XXX – SALE OPERATORIE - Analisi Funzionale	All.196_AF_SISAR_SOWEB_v.1.0
ADT - Lista d’attesa e Gestione ricoveri	Allegato 197 – Modulo ADT - Lista d’attesa e Gestione ricoveri - Analisi Funzionale	All.197_AF_SISAR_ADT-LDA_v.1.0

XXXXX	Xxxxxxxx 151 – Xxxxxx XXXXX - Analisi Funzionale	All.151_SISAR_FUNZIONALE_ELIOT_v_1.0
SRC	Allegato 152 – Xxxxxx XXXXX SRC - Analisi Funzionale	All.152_SISAR_FUNZIONALE_SRC_v_1.0
AMC – Amministrazione e Controllo
CONTROLLO DI GESTIONE	Allegato 153 – Modulo AMC - CONTROLLO DI GESTIONE - Analisi Funzionale	All.153_SISAR_ FUNZIONALE_XX.XX_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
CENTRALIZZAT O AMC	Allegato 156 – Modulo AMCCE - CENTRALIZZATO AMC - Analisi Funzionale	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 Umane
RIPRESA – Rilevazione presenze	Allegato 172 – Modulo HR - RIPRESA - Analisi Funzionale	All.172_SISAR_ FUNZIONALE_ HR_RIPRESA_v_1.0
CONTABILITÀ GUARDIA MEDICA	Allegato 173 – Modulo HR - PERSWEB – CONTABILITÀ GUARDIA MEDICA - Analisi Funzionale	All.173_SISAR_ FUNZIONALE_HR_PERSWEB_CONTAB_GUARD _MED_v_1.0
Contabilità Personale Dipendente	Allegato 174 – Modulo HR - PERSEWEB Contabilità Personale Dipendente - Analisi Funzionale	All.174_SISAR_ FUNZIONALE_HR_PERSWEB_CONTAB_PERS_ DIP_v_1.0
GESTIONE GIURIDICA PERSONALE	Allegato 175 – Modulo HR - PERSWEB - GESTIONE GIURIDICA PERSONALE - Analisi Funzionale	All.175_SISAR_FUNZIONALE_HR_PERSWEB_G EST_GIURID_PERS_DIP_v_1.0
Portale del Dipendente	Allegato 176 – MODULO Portale del Dipendente - 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À COLLABORATO RI COORDINATI	Allegato 180 – Modulo PERSWEB - CONTABILITÀ COLLABORATORI COORDINATI Analisi Funzionale	All.180_SISAR_FUNZIONALE_HR_PERSWEB_C OLL_COORD_v_1.0
MEDICINA DEI SERVIZI	Allegato 181 – Modulo HR - PERSWEB - MEDICINA DEI SERVIZI - Analisi Funzionale	All.181_SISAR_FUNZIONALE_HR_PERSWEB_C ONTAB_MED_SERV_v_1.0
SPECIALISTI AMBULATORIA LI	Allegato 182 – HR - PERSWEB CONTABILITÀ SPECIALISTI AMBULATORIALI - Analisi Funzionale	All.182_SISAR_FUNZIONALE_HR_PERSWEB_C ONTAB_SPEC_AMB_v_1.0
STIPENDI	Allegato 183 – Modulo HR - STIPENDI - Analisi Funzionale	All.183_SISAR_FUNZIONALE_HR_STIPENDI_v_1 .0
HR - CENTRALIZZAT O	Allegato 184 – HR - CENTRALIZZATO - Analisi Funzionale	All.184_SISAR_FUNZIONALE_HRCENTRALIZZA TO_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 FO 730 - Analisi Funzionale	All.162_SISAR_ FUNZIONALE_CASSA730_v_1.0
CUPWEB-LISTE D’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
Libera Professione	Allegato 165 – Modulo Libera Professione - Analisi Funzionale	All.165_SISAR_ FUNZIONALE_LIBERA PROFESSIONE_v_1.0
Portale del Cittadino	Allegato 166 – Modulo Portale del Cittadino - Analisi Funzionale	All.166_SISAR_ FUNZIONALE_Portale_del_cittadino_v_1.0
Ripartizione Proventi	Allegato 167 – Modulo Ripartizione Proventi - 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 Clinica Ambulatoriale)	Allegato 170 – Modulo AMBULATORI - Analisi Funzionale	All.170_SISAR_ FUNZIONALE_AMB_v_2.0
PD – Protocollo, Atti e Documentale
ATTI AMMINISTRATI VI	Allegato 187 – MODULO ATTI AMMINISTRATIVI - Analisi Funzionale	All.187_SISAR_FUNZIONALE_ATTI_v_1.0
DOCUMENTAL E - AURIGA	Allegato 188 – MODULO DOCUMENTALE - AURIGA - Analisi Funzionale	All.188_SISAR_FUNZIONALE_DOCUMENTALE_v _1.0
Protocollo Informatico	Allegato 189 – Modulo Protocollo Informatico - Analisi Funzionale	All.189_SISAR_FUNZIONALE_PROTOCOLLO_v_ 1.0
DIR – Direzionale
DWSISAR - Sistema direzionale SiSaR	Allegato 160 – MODULO DWSISAR - Sistema direzionale SiSaR - Analisi Funzionale	All.160_SISAR_FUNZIONALE_DWH_v_1.1
SIDI – Sistema Integrato Debito Informativo
SIDI	Allegato 136 – Modulo SIDI - Analisi Funzionale	All.136_AF_SISAR_SIDI_v.2.0
Integrazioni
Integrazioni SISAR	Allegato 186 – Modulo Integrazioni SISAR - Analisi Funzionale	All.186_SISAR_FUNZIONALE_INTEGRAZIONI_v_ 1.1
Trasversali
JBF FRAMEWORK	Allegato 190 – Modulo JBF FRAMEWORK - Analisi Funzionale	All.190_SISAR_FUNZIONALE_JBF_FRAMEWOR K_v_1.0
JBF	Allegato 191 – Modulo JBF – JBF Analisi Funzionale	All.191_SISAR_FUNZIONALE_JBF_v_1.0
XMPI Anagrafi centralizzate	Allegato 192 – Modulo XMPI Anagrafi centralizzate - Analisi Funzionale	All.192_SISAR_ FUNZIONALE_XMPI_v_1.0
ABF Installer	Allegato 198 – ABF Installer 20.12.00 Manuale 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 Xxxxxx Xxxxxxx Xxxxxxxxx (XXX) xxxxx Xxxxxxx Xxxxxxxx, 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 XXXXX 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 documenti sanitari firmabili digitalmente	Dipartimentale\Centralizzato
Integrazioni con Sistemi Terzi Non SISaR (Fascicolo Sanitario Elettronico, 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
XX.XX.	Aziende Sanitarie
ADI	Assistenza Domiciliare Integrata
AMC	Sistema Amministrativo Contabile
ANAGS	Anagrafe Sanitaria (Assistibili)

ANFFASS	Associazione Nazionale di Famiglie con Persone con Disabilità Intellettiva e/o Relazionale
AO	Azienda Ospedaliera
AOU	Azienda Ospedaliera Universitaria
API	Application Programming Interface
AREUS	Azienda Regionale dell’Emergenza e Urgenza della Sardegna
ASL	Azienda Sanitaria Locale
ASSL	Area Socio Sanitaria Locale
ATS	Azienda per la Tutela della Salute
BMI	Body Mass Index
BPMN	Business Process Model and Notation
CCA	Cartella Clinica Ambulatoriale
CDI	Centri Diurni Integrati
CDI	Cure Domiciliari Integrate (vedere ADI)
CML	Commissione Medico Locale (INPS)
CMS	Commissione Medico Superiore (INPS)
CR	Change Request
CRESSAN	Centro regionale servizi sanitari (area del CSR dedicata alla sanità)
CSR	Centro Servizi Regionale
CUP	Centro Unico di Prenotazione
DBA	Database Administrator
DB	Database
DEC	Direzione dell’esecuzione del contratto
DL	Direzione lavori
DNS	Domain name system
DPO	Data Protection Officer
EA	Enterprise Architecture
EMR	Electronic Medical Record
ENS	Ente Nazionale Sordi
ESB	Enterprise Service Bus
ETL	Extract, Transform, Load
FAD	Formazione a distanza
FSE	Fascicolo Sanitario Elettronico
FTE	Full Time Equivalent
GCC	Gruppo di coordinamento CUP
GDPR	General Data Protection Regulation
GLU	Gruppo di Lavoro per l’Usabilità - Funzione Pubblica
H-Cloud	Infrastruttura cloud regionale dedicata alla sanità
HL7	Health level 7
HR	Human Resources
HW	Hardware
INPS	Istituto Nazionale Previdenza Sociale
Medir	Medici in rete (sistema informativo che realizza l’infrastruttura tecnologica del Fascicolo Sanitario Elettronico)
MMG	Medico di Medicina Generale
MNA	Mini Nutritional Assessment
OE	Order Entry
OSA	Operatore Settore Alimentare
PA	Pubblica Amministrazione
PLS	Pediatra di Libera Scelta
PL/SQL	Procedural Language/Structured Query Language (linguaggio di programmazione per database Oracle)
PRCIF	Piano regionale di controllo ufficiale sulle matrici alimentari, sul commercio e sull’impiego dei prodotti fitosanitari
PRGLA	Programma per la riduzione delle Liste d’attesa

PS-EDS	Patient Summary-Emergency Data Set
PRIC	Piano regionale dei controlli ufficiali
PS	Pronto Soccorso
RAS	Regione Autonoma della Sardegna
RDP	Remote Desktop Protocol
RSA	Residenze sanitarie assistenziali
RTI	Raggruppamento temporaneo di imprese
RTR	Rete Telematica Regionale
SA	Stazione Appaltante
SAL	Stato Avanzamento Lavori
SIA	Sistema Informativo Amministrativo
SIAD	Sistema Informativo Nazionale Assistenza Domiciliare
SIAN	Servizio Igiene degli Alimenti e della Nutrizione
SIDI	Sistema Integrato Debito Informativo
SIO	Sistema Informativo Ospedaliero
SISP	Sistema Informativo Igiene e Sanità Pubblica
SLA	Service Level Agreement – Livelli di servizio
SOA	Service Oriented Architecture
SPRESAL	Servizio Prevenzione e Sicurezza negli Ambienti di Vita e di Lavoro
SRC	Struttura Regionale di Coordinamento
SSN	Servizio Sanitario Nazionale
SSR	Servizio Sanitario Regionale
SUS	System Usability Scale
SW	Software
TOJ	Training on the job
TSO	Team di Supporto Operativo
TT	Trouble Ticketing
UCI	Unione Italiana dei Ciechi e degli Ipovedenti
UML	Unified Modeling Language
UVI	Unità Valutazione Interna
UX	User Experience
VAT	Verbale Attività
VPN	Virtual Private Network – rete privata virtuale
XML	eXtensible Markup Language
XSD	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 disaccoppiamento funzionale	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: < xxxx://xxx.xxxxxxxxxxxxxxxx.xxx.xx/xxx#Xx%00Xxxxxxxxxx >

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 (X.Xxx. 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.

Xxxxxxxx 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à.

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).

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.

L’importo contrattuale per i servizi sopra descritti verrà riconosciuto con valore a corpo unitario ed 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

• Tracciare i test effettuati

• Effettuare Test in ambiente di test SISaR

• Rilascio della patch 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à.

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).

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.

L’importo contrattuale per i servizi sopra descritti verrà riconosciuto con valore a corpo unitario ed 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

• Tracciare i test effettuati

• Effettuare code inspection, tracciare risultati code inspection

• 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

• Effettuare verifiche di funzionamento in ambiente di produzione

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

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.

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.).

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).

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.

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 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

• Tracciare i test effettuati

• Effettuare Test in ambiente di test SISaR

• Effettuare code inspection, tracciare risultati code inspection

• Rilasciare la patch 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 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.

L’importo contrattuale per i servizi sopra descritti verrà riconosciuto con valore a corpo unitario ed 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

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.

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.

Nell’offerta tecnica il concorrente dovrà descrivere le metodologie che intende utilizzare e le modalità 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 attività produce disservizi

• 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.

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.

Nell’offerta tecnica il concorrente dovrà descrivere le metodologie che intende utilizzare e le modalità 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). 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.

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.

Nell’offerta tecnica il concorrente dovrà descrivere le metodologie che intende utilizzare e le modalità 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).

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

XXXxX, 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.

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.

Nell’offerta tecnica il concorrente dovrà descrivere le metodologie che intende utilizzare e le modalità 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).

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.

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.

Nell’offerta tecnica il concorrente dovrà descrivere le metodologie che intende utilizzare e le modalità 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). Il 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.

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.

Nell’offerta tecnica il concorrente dovrà descrivere le metodologie che intende utilizzare e le modalità 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).

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 (x.xx. SOAP, JMS) e comunicare al service provider attraverso un altro protocollo (x.xx. 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 XX0, XXXXX, xxx.. Xx 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 della piattaforma.

• 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 disaccoppiamento funzionale

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.

Nell’offerta tecnica il concorrente dovrà descrivere le metodologie che intende utilizzare e le modalità 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).

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 [XXXXX]

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.

Livello Regionale

Sistema Terze Parti

Sistema Terze Parti

Sistema Terze Parti

Livello Aziendale

Sistema Terze Parti

Sistema Terze Parti

Sistema Terze Parti

SISaR - Nodo Aziendale

Moduli dipartimentali

Enterprise Serv ice Bus (ESB) [Aziendale]

Enterprise Serv ice Bus (ESB) [Regionale]

SISaR - Nodo Regionale

Moduli centralizzati

Moduli centralizzati

Moduli centralizzati

Moduli dipartimentale

Moduli dipartimentale

Figura 1 Panoramica di alto livello sulle integrazioni

erze

rze

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

Livello Aziendale

SISaR - Nodo Aziendale

XMPI

Lista Attesa

ADTWEB

PSWEB

OEPR

SOWEB

Sistemi Dipartimentali Terze Parti

XXXXX

CCA

EMR

ETL Flussi

Repository Documentale

Enterprise Serv ice Bus (ESB) [Aziendale]

ADI

PUA

SISP

SPRESAL

Cartella Consultori

RSA/Hospice

CEDAP

Medicina dello Sport

Medicina Legale

Protesica

SIAN

Altri sistemi

AP

RIS/PACS

LIS

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.

L’importo contrattuale per tutto l’insieme dei servizi sopra descritti verrà riconosciuto con valore a 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 XXXXX 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 XXXXX e il LIS/Xxxxxxx sia realizzato tramite ESB;

- che i flussi massivi di dati da XXXXX a SRC siano governati da ESB;

- che l’interscambio di dati tra XXXXX 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 in GG/U per Sistema per l’attività di supporto alla Migrazione Dati nel caso di sostituzione del Sistema	Effort minimi in GG/U per l’attività di Trasferimento delle Competenze per ciascun sistema in caso di mantenimento dello stesso
AMC – Amministrazione e Controllo	Contabilità, Acquisti e Contratti, Logistica (Magazzini, Richieste di Approvvigionamento, Armadietto di Reparto), Gestione Attrezzature e Manutenzioni / Cespiti	152	120
HR – Risorse Umane	Trattamento Giuridico, Dotazione Organica, Gestione Economica e Contributiva, Rilevazione Presenze	174	120
PD – Protocollo, Atti e Documentale	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 Presidio Ospedaliero in cui è in uso)
	Prescrizione Elettronica
SIO - Trasfusionale	Trasfusionale	140	90
	SRC (ex CRCC)
AAP – Attività Assistenziali	CSS	80	80
	Consultorio
	PUA
	ADI
	RSA
	Protesica
AAP – Attività di Prevenzione	Medicina dello Sport	70	70
	Medicina Legale
	SPRESAL
	SISP
	SIAN
CUP – Gestore Risorse	Ambulatorio	110	110

	CUPWEB
EPI – Epidemiologico	CEDAP	10	10
	RENCAM
Sistema Integrato del Debito 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.

Nell’offerta tecnica il concorrente dovrà descrivere le metodologie che intende utilizzare e le modalità 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). 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.

Nell’offerta tecnica il concorrente dovrà descrivere le metodologie che intende utilizzare e le modalità 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). 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ì.

L’importo contrattuale per i servizi sopra descritti verrà riconosciuto con valore a corpo unitario ed 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:

Codice Indicatore	Descrizione Indicatore	Descrizione	Rilevazione
FOR	Grado di soddisfazione	A conclusione di ciascuna sessione di formazione viene	Aggiornato con verifica trimestrale

	medio degli utenti	rilevato il grado di soddisfazione medio dei partecipanti. Liv. 1 – Scarso Liv. 2 – Insufficiente Liv. 3 - Sufficiente Liv. 4 - Buono Liv. 5 - Ottimo
		A conclusione di ciascuna sessione di affiancamento, viene rilevato il grado di soddisfazione medio degli utenti rispetto alla totalità di affiancamento nel trimestre.
AFF	Grado di soddisfazione medio degli utenti	Liv. 1 – Scarso Liv. 2 – Insufficiente	Aggiornato con verifica trimestrale
		Liv. 3 - Sufficiente
		Liv. 4 - Buono
		Liv. 5 - Ottimo

Detta rilevazione del livello di soddisfazione degli utenti non avrà effetto ai fini della determinazione di eventuali penali per tale servizio.

Nell’offerta tecnica il concorrente dovrà descrivere le metodologie che intende utilizzare e le modalità 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). Il 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’ATTUALE GESTORE 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
Moduli Effort in GG/U x Trasferimento delle Competenze

AMC – Amministrazione e Controllo	Contabilità, Acquisti e Contratti, Logistica (Xxxxxxxxx, Richieste di Approvvigionamento, Armadietto di Reparto), Gestione Attrezzature e Manutenzioni / Cespiti	120
HR – Risorse Umane	Trattamento Giuridico, Dotazione Organica, Gestione Economica 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 Presidio Ospedaliero in cui è in uso)
	Prescrizione Elettronica
SIO - Trasfusionale	Trasfusionale	90
	SRC (ex CRCC)
AAP – Attività Xxxxxxxxxxxxx	Xxxxxxxxxxx	00
	XXX
	XXX
	XXX
	Protesica
AAP – Attività di Prevenzione	Medicina dello Sport	70
	Medicina Legale
	SPRESAL
	SISP
	SIAN
	Portale Amianto e NPC WEB
CUP – Gestore Risorse	Ambulatorio	110
	CUPWEB
EPI – Epidemiologico	CEDAP	10
	RENCAM
Sistema Integrato del Debito Informativo	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 “X. Xxxxxx”

• 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 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, 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 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 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 aziendale, e dovrà essere specificato nell’offerta tecnica.

• 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 aziendale, e dovrà essere specificato nell’offerta tecnica.

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 “X. Xxxxxx”

• 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 x XXX 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	Deliverable
AREA 1 - Gestione
Manutenzione correttiva	Registro Manutenzione Correttiva
	Documentazione tecnica di analisi e design, note Operative e manuali utente aggiornati
	Check 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
	Piano dei Test/Rapporto Esecuzione Test
	Note Operative e manuali utente aggiornati
	Check List e Verbale di Installazione Ambiente di Test
	Check List e Verbale di Installazione Ambiente di Produzione
	Documentazione tecnica (sia funzionale che architetturale), manualistica, diagrammi UML, User Exeperience Design
Manutenzione adeguativa e adattativa	Piano della manutenzione adeguativa e adattativa con paragrafo distinto dedicato alla manutenzione ordinaria per adeguamenti normativi e aggiornamento trimestrale dello stesso
	Piano dei Test/Rapporto Esecuzione Test
	Note Operative e manuali utente aggiornati
	Check List e Verbale di Installazione Ambiente di Test
	Check List e Verbale di Installazione Ambiente di Produzione
	Documentazione tecnica (sia funzionale che architetturale), manualistica, diagrammi UML, User Exeperience Design
	In 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
	Note Operative e manuali utente aggiornati
	Check List e Verbale di Installazione Ambiente di Test
	Check List e Verbale di Installazione Ambiente di Produzione
	Documentazione tecnica (sia funzionale che architetturale), manualistica, diagrammi UML, User Exeperience Design
Manutenzione evolutiva	Piano della manutenzione evolutiva e aggiornamento mensile dello stesso
	Per ciascuna CR: - 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
	Check List e Verbale di Installazione Ambiente di Test
	Check List e Verbale di Installazione Ambiente di Produzione
	Note Operative e manuali utente aggiornati
Miglioramento delle performance e dell’usabilità	Piano per il miglioramento delle performance e della user experience e aggiornamento trimestrale dello stesso
	Gantt complessivo con mappatura delle risorse impiegate per profilo professionale utilizzato aggiornato
	Check List e Verbale di Installazione Ambiente di Test
	Check List e Verbale di Installazione Ambiente di Produzione
	Piano dei Test/No regression Test/Rapporto Esecuzione Test
	Note Operative e manuali utente aggiornati
	Analisi Funzionale/Analisi dei requisiti/Specifica architetturale delle soluzioni sw/Diagrammi UML, User Experience Design
Servizi Specialistico-Applicativi	Report segnalazioni registrate su JIRA> Relazione sullo Stato Avanzamento Lavori
Gestione dell’Ambiente Applicativo di Test	Check List e Verbale di Installazione Ambiente di Test
	Piano dei Test/Rapporto Esecuzione Test
	No-regression Test
Gestione dell’Ambiente Applicativo di Produzione	Check List e Verbale di Installazione Ambiente di Produzione
	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’Amministrazione Aggiudicatrice) su tutte le integrazioni che insistono sull’integratore SpagiC\nuovo integratore 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 numero inferiore a quanto atteso (soglia da definirsi in base alla media)
	Relazioni mensili sulle verifiche di qualità eseguite su moduli, integrazioni e aggiornamento dei dati del Direzionale.
Servizio di Help Desk	Report segnalazioni registrate sul sistema di trouble ticketing, all’interno dei rapporti bimestrali sui servizi erogati
Servizio di Reperibilità H24 Mission- Critical	Report segnalazioni registrate sul sistema di trouble ticketing, all’interno dei rapporti bimestrali sui servizi erogati
AREA 2 - Infrastruttura di interoperabilità ESB/API