ATS Sardegna

La Legge Regionale 27 luglio 2016, n. 17 ha modificato l'assetto istituzionale del Servizio sanitario regionale della Sardegna, istituendo l'Azienda per la Tutela della Salute.

L'ATS nasce dalla fusione per incorporazione delle sette ASL nell'azienda incorporante di Sassari.

Ci sono una Azienda e otto aree socio-sanitarie, corrispondenti ai territori delle vecchie ASL. Ci sarà anche l’Area Metropolitana di Cagliari, contestualmente all'attuazione della riforma degli Enti Locali. Con ATS e ASSL, avremo i Distretti, che verranno definiti per numero e ambiti territoriali.

L'ATS, sulla base degli atti di indirizzo deliberati dalla Giunta regionale e delle direttive dell'Assessorato competente in materia di sanità, svolge le funzioni di:

programmazione aziendale e gestione complessiva dell'erogazione dei servizi sanitari e socio-sanitari; omogeneizzazione e armonizzazione dei processi gestionali nel territorio regionale in coordinamento con

l'attività delle altre aziende sanitarie;

accentramento, per quanto di competenza di tutte le aziende sanitarie della Sardegna, dei processi di aggregazione della domanda di beni e servizi e di approvvigionamento degli stessi;

gestione accentrata, secondo gli indirizzi della Giunta regionale e nel rispetto delle disposizioni di cui all'articolo 18, comma 1, della legge regionale n. 10 del 2006 per quanto attiene le aziende ospedaliero-universitarie, per tutte le aziende sanitarie della Sardegna, delle procedure concorsuali e selettive, del trattamento economico del personale, dei magazzini e della relativa logistica, delle reti informatiche e delle tecnologie dell'informazione e della comunicazione, delle tecnologie sanitarie e della valutazione dell'impatto delle stesse;

gestione accentrata, secondo gli indirizzi della Giunta regionale, per tutte le aziende sanitarie della Sardegna, delle procedure di gara per la progettazione, realizzazione, manutenzione, alienazione, concessione e locazione degli immobili costituenti patrimonio delle stesse;

definizione degli accordi con le strutture pubbliche ed equiparate e stipula dei contratti con quelle private e con i professionisti accreditati, ai sensi dell'articolo 8 della legge regionale n. 10 del 2006, in coerenza con la programmazione territoriale di cui all'articolo 4, comma 5, lettera a);

accentramento delle procedure di organizzazione dei percorsi di formazione ECM.

La Ats è impegnata in un profondo processo di riorganizzazione, razionalizzazione e centralizzazione: sono infatti in corso dei percorsi di riorganizzazione complessiva della Sanità regionale, di riorganizzazione e razionalizzazione dei presidi ospedalieri, di revisione dei processi di presa in carico dei pazienti, centralizzazione dei processi amministrativi e di acquisti e di quelli clinico-sanitari. Il tutto per raggiungere un importate obiettivo: rimettere il Paziente al centro dei processi assistenziali, di cura e prevenzione, con la certezza della sostenibilità finanziaria del sistema.

R.T. I. Almaviva S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

In questo contesto l’innovazione digitale è una leva strategica per l’Ats, che sta affrontando un cambiamento epocale e una profonda trasformazione dei processi di erogazione dei propri servizi sanitari. Una trasformazione che parte dall’oggi, con il progressivo miglioramento del supporto alla gestione dei servizi al cittadino-paziente, e che contemporaneamente guarda già al futuro.

Nell’ambito del Piano Sanitario Triennale 2018-2020 l’ATS ha posto un particolare focus sui seguenti obiettivi:

- migliorare l’efficienza organizzativa dell’assistenza ospedaliera;

- definire e governare le reti di cura,

- migliorare la continuità delle cure tra ospedale e territorio;

In tale ambito, che vede da un lato una profonda riorganizzazione dei diversi servizi attraverso modelli che privilegiano la cooperazione e la multidisciplinarietà e dall’altro la necessità di portare a fattor comune le singole esperienze di eccellenza presenti nelle ex ASL, nel documento ‘Pianificazione dei servizi ICT dell’Azienda di Tutela della Salute della Regione Autonoma della Sardegna per il triennio 2018-2020’ è stato previsto, tra gli altri, il progetto strategico ‘Modello di interoperabilità’.

Questo progetto prevede in particolare tre moduli, logicamente e strutturalmente connessi:

- Enterprise Service Bus – middleware

- Integrazioni ASSL

- Integrazioni ASSL – SISaR

La presente proposta progettuale è finalizzata a rispondere alle esigenze espresse nel Piano dei Fabbisogni e in particolare ai primi due moduli succitati.

Lo sviluppo e la gestione dei servizi di interoperabilità basati sulla infrastruttura immateriale dell’ESB Aziendale prescelto da ATS risulta essere abilitante per i progetti di razionalizzazione dei sistemi informative sanitari aziendali, con particolare riferimento, ad esempio, al Sistema Informativo dei Laboratori e alla

razionalizzazione dei processi di Prenotazione e Erogazione delle prestazioni specialistiche ambulatoriali.

Il presente documento costituisce un aggiornamento del Progetto dei Fabbisogni 1.3 del 06/08/2020, il quale è parte integrante del Contratto Esecutivo CIG derivato 758704753F.

Si ripercorre nel seguito le evoluzioni progettuali.

La versione 1.1 del Progetto dei Fabbisogni conteneva unicamente la riallocazione dei termini temporali del contratto senza variazioni economiche, e tale versione del Progetto dei Fabbisogni è stata successivamente contrattualizzata con un Addendum al Contratto Esecutivo.

A seguito delle note ATS, nella quale si evidenzia il fabbisogno di riallocazione dei termini temporali della scadenza del contratto in oggetto e la necessità di inserire nel progetto stesso alcune varianti, veniva emessa in data 03/04/2020 la versione 1.2 del Progetto dei Fabbisogni.

R.T. I. Almaviva S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

In tale versione 1.2 del Progetto dei Fabbisogni venivano definite le varianti introdotte rispetto alla versione 1.0, che conteneva i dettagli progettuali, e veniva aggiornato il cronoprogramma delle attività, lasciando invariato l’impegno economico, in quanto le varianti previste si compensavano e non comportavano variazioni in aumento o diminuzione dell’importo economico previsto inizialmente.

Il Progetto dei Fabbisogni v 1.2 non è stato oggetto di contratto e la ATS Sardegna ha espresso l’esigenza di una ulteriore variante in aumento, ovvero l’integrazione del sistema regionale di diabetologia, e una variante in diminuzione, ovvero la installazione del Picasso Centrale, eseguito direttamente da ATS per ragioni di urgenza.

Nella versione 1.3 del Progetto dei Fabbisogni venivano definite le varianti introdotte rispetto alle versioni precedenti, veniva aggiornato il cronoprogramma delle attività e incrementato l’impegno finanziario.

Il presente documento costituisce il Progetto dei Fabbisogni per i servizi richiesti dall’Amministrazione ATS Sardegna, esso riporta la proposta tecnico ed economica da implementare presso l’Amministrazione sulla base delle richieste contenute nel Piano dei Fabbisogni secondo le modalità tecniche ed i listini previsti nel Contratto Quadro.

1.2. Scopo

Scopo del documento è documentare e quantificare i servizi richiesti dall’Amministrazione. Si compone di:

◼ Organizzazione del Contratto

◼ Progetto di Attuazione

◼ Modalità di presentazione e approvazione degli stati di avanzamento mensili

◼ Piano di Attuazione

◼ Data di Attivazione

1.3. Campo di applicazione

Il documento si applica al progetto SPC lotto 3. In particolare, ai seguenti servizi:

◼ Realizzazione interfacce web services

◼ Realizzazione client per la fruizione dei servizi

◼ Orchestrazione

1.4. Assunzioni

Non applicabile.

R.T. I. Xxxxxxxx S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

1.5. Riferimenti

Identificativo	Titolo/Descrizione
Contratto Quadro del 31/03/2017 e relativi Allegati	Contratto Quadro del 31/03/2017 relativo all’Appalto dei servizi di interoperabilità per i dati e di cooperazione applicativa (lotto 3) in favore delle PA.
Allegato 5A alla lettera d’invito	Capitolato Tecnico Parte Generale
Allegato 5B alla lettera d’invito	Capitolato Tecnico Lotto 3
Piano dei Fabbisogni	SPCL3-ATS-ESB-PianoFabbisogni v 3_6
Progetto dei Fabbisogni 1.0	SPCL3-ATS_ESB-ProgettoFabbisogni v1.0 del 5/07/2018
Progetto dei Fabbisogni 1.1	SPCL3-ATS_ESB-ProgettoFabbisogni v1.1 del 12/07/2019
Progetto dei Fabbisogni 1.2 (non contrattualizzato)	SPCL3-ATS_ESB-ProgettoFabbisogni v1.2 del 03/04/2020
Progetto dei Fabbisogni 1.3	SPCL3-ATS_ESB-ProgettoFabbisogni v1.3 del 06/08/2020
Contratto Esecutivo	Contratto Esecutivo CIG Derivato758704753F

1.6. Acronimi e glossario

Definizione / Acronimo	Descrizione
Consip	Consip S.p.a.
RTI	Raggruppamento Temporaneo d’Impresa
SPC	Sistema Pubblico di Connettività
ATS	Azienda Tutela della Salute
ASSL	Azienda Socio Sanitaria Locale
ESB	Enterprise Service Bus

R.T. I. Xxxxxxxx S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

2. ORGANIZZAZIONE DEL CONTRATTO ESECUTIVO

Il RTI si avvale di un modello organizzativo di Cooperazione, che ha come obiettivo quello di soddisfare le richieste di Cooperazione delle Amministrazioni in maniera coordinata e integrata sia a livello di singolo Contratto Esecutivo sia a livello di Contratto Quadro.

Per il Contratto Esecutivo si identificano:

◼ il Responsabile del Contratto Esecutivo: Xxxxxx Xx Xxxx

◼ il Responsabile delle funzioni di Project e Risk Management e di Quality Management specifiche per il CE: Xxxxxxxx Xxxxxxxx

Centri Servizi

La figura seguente rappresenta l’organizzazione prevista per l’esecuzione del contratto.

Responsabile dei Centri Servizi

Supporto Analisi

Orchestrazione

Supporto Memorizzazione

Web services/Client

Responsabile Big Data

Responsabile Open Data

Responsabile Coop. App.

Qualità

Project e Risk

Management

Responsabile Contratto Es.

Piattaforme «a-a-s»

BIG Data «a-a-s»

SPAQRL end point

Porta di dominio

Responsabile C.Q.

Figura 1: Organizzazione del Contratto

R.T. I. Xxxxxxxx S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

La tabella seguente riporta i nominativi/ruoli dell’organizzazione previsti per i servizi contrattuali erogati.

Ruolo

Nome

Cognome

Riferimenti

Responsabile Centro

Servizi

Xxxxxxxx

Xxxxxx

x.xxxxxx@xxxxxxxx.xx

Responsabile Cooperazione

Applicativa

Xxxxxxxxxxxx

Xxxxxxxxxxx

x.xxxxxxxxxxx@xxxxxxxx.xx

R.T. I. Almaviva S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

3. PROGETTO DI ATTUAZIONE

E’ stata individuata dall’Amministrazione in PICASSO, una soluzione multipiattaforma, verticale per la sanità e fortemente orientata agli standard di settore (HL7 ed IHE). Tale soluzione è già stata acquisita dalla Amministrazione e risulta oggi funzionante in un ambito limitato (ASSL Sassari).

Nei paragrafi seguenti, sono descritte le modalità operative per l’attivazione della piattaforma abilitante e interoperabile e le personalizzazioni richieste nel Piano dei Fabbisogni attraverso le due macro esigenze “Realizzare un sistema federato di ESB su tutta l’ATS” e “Migrare tutte le integrazioni esistenti su ESB federato”.

I paragrafi successivi, sino al 3.3 escluso, sono quelli definiti nel Progetto dei Fabbisogni 1.0. Per una compiuta lettura vanno integrati con le varianti descritte nel paragrafo 3.3.

3.1. Realizzazione del sistema federato di ESB

La piattaforma Picasso verrà estesa a ciascuna delle 8 ASSL, raccordate ad un’istanza centrale in grado di “federare” il sistema per garantire le seguenti funzionalità:

Disporre di un punto centrale di monitoraggio di tutte le integrazioni sull’intera ATS, che permetta:

⚫ La visualizzazione di tutte le integrazioni;

⚫ L’analisi di tutte le situazioni di allarme;

⚫ L’analisi statistica di tutti gli impianti e di tutti i flussi;

Disporre di un punto centrale di interfaccia con i sistemi Regionali che permetta:

⚫ L’intercettazione di tutti i punti di integrazione con i sistemi regionali;

⚫ Il monitoraggio e la gestione degli allarmi nelle integrazioni operanti a livello regionale;

R.T. I. Almaviva S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

Lo schema di funzionamento è illustrato nella figura seguente:

Figura 2: schema di funzionamento

Funzioni dell’ESB locale:

colloquio con l’ESB Centrale;

governo di tutte le integrazioni locali;

invio referti e documenti a ESB Centrale tramite CDR Galileo per FSE MEDIR;

Funzioni dell’ESB Centrale:

Colloquio con ESB locali;

governo di tutte le integrazioni con componenti regionali;

interoperabilità tra applicativi del medesimo set (LIS, RIS), anche se ubicati su CED diversi; alimentazione centralizzata del FSE MEDIR;

R.T. I. Almaviva S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

colloquio con ESB regionale (una volta che sarà disponibile, ai sensi della strategia di evoluzione del SiSaR, di cui alla Delibera della Giunta Regionale N. 2/13 del 16/01/2018; nel frattempo è previsto il colloquio con i middleware esistenti lato Sistemi Regionali); l’architettura di ESB locali non contrasta con una possibile futura implementazione delle strategie di consolidamento e razionalizzazione dei Data Center delle 8 ASSL, dal momento che tale passaggio sarà probabilmente successivo al presente progetto, beneficiando, peraltro della relativa razionalizzazione introdotta.

3.1.1. Personalizzazioni della soluzione PICASSO - ESB

La soluzione proposta a supporto della gestione delle integrazioni e messaggistica è un Enterprise Service Bus (ESB) nel seguito denominato PICASSO-ESB. PICASSO-ESB va oltre la definizione di middleware di integrazione includendo funzionalità proprie di un Framework progettato specificatamente per rendere interoperabili sistemi informativi in ambito clinico-sanitario, accelerando e facilitando lo sviluppo di canali di integrazione. Consente di gestire l’intero ciclo di vita del software di integrazione, dalla sua specifica, progettazione e realizzazione alla sua esecuzione e gestione operativa. Le caratteristiche principali che caratterizzano la soluzione:

Consente la generazione automatica delle integrazioni a partire dalla specifica del contesto di integrazione; questa caratteristica riduce sensibilmente i tempi di sviluppo.

Incentiva il riuso di servizi di integrazione esistenti salvaguardando gli investimenti.

Può essere configurato in Cluster scalabili di due o più nodi, consentendo quindi performance dinamiche

all’aumentare del numero di integrazioni gestite.

Più istanze di XXXXXXX-ESB possono essere federate in modo gerarchico e gestite da una singola istanza master.

Dispone di strumenti evoluti di Message Asset Management (MAM) per la gestione e il monitoraggio dei sistemi.

R.T. I. Almaviva S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

Figura 3: Gestione Integrazioni e Messaggistica

Riguardo alle principali componenti funzionali riportate nel diagramma, PICASSO-ESB è in grado di: garantire l'interoperabilità di sistemi da integrare in conformità al paradigma SOA (Service-Oriented

Architecture) tramite l’utilizzo di Web Service veicolando informazioni nel formato XML; l'interoperabilità viene garantita nel rispetto della sicurezza della comunicazione, della continuità e delle performance

adottare e gestire, attraverso opportuni connettori, gli ulteriori principali standard di comunicazione di seguito riportati e garanzia per la copertura di integrazioni dei flussi o applicativi:

⚫ MLLP (Minimum Lower Layer Protocol) su TCP/IP

⚫ REST (Representational State Transfer)

⚫ accessi in lettura/scrittura a tabelle di frontiera di database relazionali (RDBMS)

⚫ deposito/prelievo di file su file system o via FTP

⚫ SMTP per la trasmissione, POP3 o IMAP per la ricezione di email

⚫ custom/proprietario

adottare e gestire formati standard di messaggi e tra questi quelli richiesti dal capitolato:

⚫ HL7 v2.x sia in formalismo XML che pipe&hat (incluso HL7 MDM)

⚫ HL7 v3 (incluso CDA e CDA-R2 che contengono informazione strutturata o encoded Base64)

⚫ FHIR® (Fast Healthcare Interoperability Resources)

⚫ DICOM per la gestione del medical imaging (immagini di sistemi radiologici)

⚫ custom o proprietari

R.T. I. Almaviva S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

⚫ gestire messaggi in ingresso e uscita non appena questi vengono generati e comunicati, garantendo la consegna ai destinatari con regole di instradamento configurabili o basate sul contenuto dei messaggi; la gestione del routing dei messaggi può avvenire sia in modalità sincrona che asinrona, mantenendo la compliance con i profili standard IHE (Integrating the Healthcare Enterprise).

XXXXXXX-ESB può essere visto come un insieme di strumenti e servizi a valore aggiunto disponibili sopra un Application Server e su un Execution Server Open Source.

Come evidenziato nell’architettura, PICASSO-ESB necessita di un ESB di trasporto che ha lo scopo di fornire un layer (bus) di comunicazione uniforme tra i servizi, in modo coerente con i principi SOA, agendo sia come registro di servizi sia come unico punto centralizzato di gestione.

I requisiti della piattaforma PICASSO-ESB per l’integrazione dei servizi sono i seguenti:

- Interoperabilità: permettere ai diversi sotto-sistemi di interagire, anche in presenza di standard non convenzionali e/o piattaforme legacy;

- Integrazione: consentire l’integrazione dei sistemi nel rispetto della sicurezza e della coerenza dei dati tra fonti eterogenee, con il supporto di diverse modalità di trasporto: File transfer, Shared database, Remote procedure invocation e Messaging;

- Robustezza: come lo stack (collante) che aggrega l'infrastruttura modulare e risponde in termine di stabilità e scalabilità, anche in situazioni di alto traffico ed in contesti mission critical.

La soluzione assicura diversi vantaggi:

- costituisce la dorsale di comunicazione di tutti i sistemi afferenti a PICASSO-ESB; contribuisce alla gestione delle logiche del carico, della sicurezza e della disponibilità dei servizi;

- agisce da strato di mediazione enterprise grazie al quale i servizi messi a disposizione dal provider sono fruibili dal consumer;

- fornisce un punto di espansione sicuro verso eventuali sistemi esterni e altri sistemi di IT;

- permette di standardizzare le modalità operative grazie alla condivisione dei protocolli comunicativi e all’alta eterogeneità dei formati nello scambio dei dati (tra cui AJAX, RPC- CORBA/RMI, FTP, http/s, imap/s, jdbc, JMS, POP3, SMTP, XMPP, REST/json); fornisce in maniera intrinseca servizi di orchestrazione, sicurezza, messaggistica, routing intelligente e trasformazione, agendo come una

dorsale attraverso la quale viaggiano servizi software e componenti applicativi; permette l’analisi dei

servizi pubblicati al fine di monitorarne lo stato.

Il modulo PICASSO-ESB include dei tools di Message Asset Management con cui gli Amministratori possono gestire il patrimonio di messaggi in transito sulla piattaforma oggetto dell'offerta, questi forniscono servizi di:

- Monitoraggio: consente di analizzare in dettaglio via Web il comportamento del sistema, delle applicazioni integrate, delle interazioni implementate ed il corrispondente flusso dei messaggi.

- Alerting: la componente esegue un monitoraggio continuo delle risorse di sistema e delle componenti di integrazione. In caso di malfunzionamenti invia email di allarme al centro di assistenza e, se

richiesto, a personale dell’Ente utente presso il quale XXXXXXX-ESB è istallato.

R.T. I. Almaviva S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

- Reportistica: componente predisposta per generare ed inviare periodicamente (con frequenza

configurabile) dei report statistici (configurabili) relativi all’operatività complessiva del sistema e delle

principali integrazioni.

- Message History: acquisisce e gestisce l’universo degli eventi e dei messaggi transitati su PICASSO- ESB. Per ciascun evento viene mantenuto un record che contiene l’identità dell’applicazione mittente, il formato di ingresso del messaggio, il time stamp di ingresso, il formato del messaggio in uscita, il

time stamp del messaggio in uscita e l’identificativo della/e applicazioni destinatarie del messaggio.

Figura 4: Monitoraggio integrazioni

3.1.2. Personalizzazioni della soluzione PICASSO - MS

XXXXXXX MS (Multi Site) è la configurazione di XXXXXXX predisposta per la gestione di una federazione di

PICASSO ESB e, normalmente, è utilizzato per fornire supporto alla gestione della interoperabilità nell’ambito

di una Federazione di Aziende (o, come nel caso specifico, di Aree della stessa Azienda), quando lo scopo dell’integrazione, come nel caso di un Fascicolo Sanitario Elettronico, coinvolge più strutture sanitarie distribuite facenti parte di Enti sovra Aziendali, come Aree Vaste e Regioni.

Nello specifico XXXXXXX MS è composto dalle seguenti componenti: XXXXXXX ESB

R.T. I. Xxxxxxxx S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

Sistema per la Gestione della Federazione, il quale include le due componenti Repository Multi Site e Monitor Multi Site.

3.1.3. Monitor Multi Site

Questa funzionalità è stata espressamente progettata per consentire a Enti sovra Aziendali, come Aree Vaste e Regioni, di realizzare e gestire un punto unico di monitoraggio di tutte le Aree controllate.

Le principali funzioni del Monitor Multi Site (Monitor MS) sono:

- Gestione degli allarmi: consente di visualizzare sulla console del Monitor MS gli allarmi relativi alle installazioni controllate. Per lo stato di allarme viene fornita sia una visione sintetica (stato di

funzionamento complessivo dell’installazione) che una visione di dettaglio sulle singole situazioni di allarme. Le installazioni controllate (tramite la componente Watchdog di XXXXXXX ESB) comunicano sia l’instaurarsi di situazioni di allarme che la loro risoluzione, in modo che Monitor MS sia in grado di fornire una visione aggiornata dello stato reale. Monitor MS offre anche funzioni di Trable Ticket Management, che consentono di assegnare ad un operatore un ticket relativo ad un allarme e seguirne lo stato di lavorazione. Gli allarmi rilevati da XXXXXXX Watchdog e visualizzati da Monitor MS sono sia di tipo sistemistico (istanza non operativa, spazio disco o DB in esaurimento, ecc.) che di tipo funzionale sulle integrazioni gestite (assenza di messaggi per un periodo eccedente una soglia determinata, superamento di soglia sulla percentuale di errori di trasmissione, impossibilità di consegnare un messaggio, ecc.)

- Produzione di report statistici: Monitor MS raccoglie in un proprio Datamart informazioni statistiche sulle istanze controllate e consente di produrre report che mettono a confronto l’operatività delle diverse istanze. I report possono essere generati su richiesta dell’operatore da consolle, oppure

automaticamente, ad intervalli regolari prefissati (giorno, settimana, mese) ed inviati via email a liste di destinatari.

- Gestione di messaggi remoti: consente di ricercare e presentare messaggi transitati su un’installazione

remota. I messaggi possono essere cercati su un XXXXXXX ESB remoto in base a diversi criteri che

includono l’applicazione mittente, l’applicazione destinataria, il tipo di messaggio e alcuni campi chiave contenuti nel messaggio stesso. Ad esempio può essere fatta una ricerca di un referto inviato dal laboratorio di analisi al Fascicolo Sanitario per un paziente con un certo codice fiscale. Si può quindi verificare se il referto è stato inviato da laboratorio, se è stato consegnato al Fascicolo e in caso affermativo si può visualizzare il messaggio di ricevuta. Tutte queste operazioni sono disponibili dalla console del Monitor MS senza che l’operatore debba accedere all’installazione remota. Questo tipo di funzionalità consentono a enti come ad esempio Amministrazioni Regionali che istituiscono Help Desk centrali per il proprio Fascicolo Sanitario di ridurre in modo significativo i costi di esercizio e di rispondere in modo preciso e rapido alle richieste dell’utenza.

R.T. I. Xxxxxxxx S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

La macro architettura del Monitor MS è schematizzata nella figura che segue:

Figura 5: Monitor MS

Per le comunicazioni dalle istanze di XXXXXXX ESB al Monitor MS sono supportati due protocolli di comunicazione:

SMTP: meno efficiente, ma che non richiede specifiche configurazioni di rete

http: in questo caso le comunicazioni avvengono attraverso l’invocazione di Web services, che devono essere consentite dalle configurazioni della rete.

Per le comunicazioni da Monitor MS alle istanze è possibile usare solo il protocollo http(s). La figura che segue mostra un esempio di console Monitor MS in operatività.

R.T. I. Xxxxxxxx S.p.A/ Almawave S.r.l/ Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

Figura 6: Console Monitor MS

3.2. Migrazione integrazioni

Sarà effettuato il porting delle integrazioni presenti nell’ATS e mediate dal sistema SILUS-Galileo:

a livello ASSL sotto la regia dell’ESB locale;

a livello ATS sotto la regia dell’ESB Centrale.

Le integrazioni locali da migrare sono riportate nella seguente tabella:

ADT PS		CUP RIS	OE RIS	LIS GEPADIAL	LIS Eurotouch	LIS SIT	LIS Kardia	GAL Margh.3	TAO EXT	SCR AP	SCR AnagS	SCR LIS	SCR RIS	LIS PS	TOTALE
Sassari	x	x	x	x	x	x				x	x		x	x	11
Olbia	x		x			x	x	x			x	x		x	7
Nuoro	x					x			x		x			x	6
Lanusei	x					x			x		x			x	5
Oristano	x			x		x			x		x		x	x	8
Sanluri	x	x	x			x			x		x			x	8
Carbonia	x		x			x			x		x			x	6
Cagliari	x								x		x		x	x	6

Totale	8	2	4	2	1	7	1	1	6	1	1	1	3	8	47

Upgrade da JCaps	5	2	4	1	1	4	1	1	2	0	0	0	0	4	25
Nuove	3	0	0	1	0	3	0	0	4	1	1	1	3	4	21

Tabella 1: Integrazioni Locali

Come si evince dalla tabella, saranno migrate 26 integrazioni dall’applicativo JCaps, verranno create 21 nuove integrazioni.

R.T. I. Xxxxxxxx S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

Le integrazioni centrali da migrare sono le seguenti:

- Integrazione Screening- AnagS;

- Integrazione MEDIR;

- Integrazione MFP (SERD) (Solo ASSL Olbia, in fase di estensione da parte di SardegnaIT);

- Integrazione AVACS (Anagrafe vaccinale) – AnagS.

Upgrade da JCaps

Per le venticinque integrazioni presenti sull’applicativo JCaps, verrà effettuato uno studio dei flussi. Una volta completa l’analisi, ogni singolo flusso verrà riprodotto all’interno di XXXXXXX.

Nuove Integrazioni

Le ventuno integrazioni non veicolate tramite l’applicativo JCaps, sono realizzate nella modalità punto-punto mediante: protocollo HL7, tabelle di frontiera e polling su cartelle condivise. Le integrazioni verranno realizzate ex-novo seguendo la documentazione fornita dai vari applicativi.

3.2.1. Migrazione integrazione locale

ADT/PS

SISaR AREAS Ospedaliera è il sistema di registrazione degli eventi di ADT (accettazione, prericovero, dimissione, trasferimento, ...) dei Paziente all'interno dei Reparti e del Pronto Soccorso.

Per ogni evento il sistema SISaR produce un messaggio ADT riportante l'identificazione del Paziente (che comprende il codice XMPI locale del paziente stesso) e le informazioni relative all'evento (p.e.: Xxxxxxxx, Reparto, nosologico, ...).

SISaR si occupa inoltre della produzione degli eventi ADT di aggiornamento (p.e.: eventi di aggiornamento

anagrafico, eventi di merge, etc…).

Tutti gli eventi ADT vengono processati dal connettore HL7 di SISar in modo da essere inoltrati all'Order Entry Galileo.

A seconda della configurazione presente nell’impianto, i flussi varranno migrati da JCaps a XXXXXXX. Negli

impianti dove il flusso è gestito tramite metodo punto-punto, verrà realizzato un flusso ex-novo su XXXXXXX.

CUP-RIS

L’integrazione CUP-RIS è presente in 3 ASSL:

Sassari, con RIS “Risolution” (in fase di migrazione a “Suitestensa”); Sanluri, con RIS “Elektra” (in via di sostituzione con Suitestensa); Carbonia, con RIS “Elektra”.

R.T. I. Xxxxxxxx S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

L'integrazione CUP-RIS (fra i CUPWeb i citati RIS) consente il passaggio degli eventi di prenotazione ed accesso alla Radiologia effettuati sul sistema SISaR CUPWeb.

L'integrazione prevede inoltre l'arricchimento delle informazioni gestite da CUPWeb con il codice XMPI locale del Paziente.

Attualmente tutte le integrazioni sono monodirezionali e realizzate sulla vecchia piattaforma CUP SGP, mediate tabelle di frontiera. JCaps, per costruire il messaggio HL7 da inviare al protocollo RIS, utilizza:

Le tabelle di frontiera esposte dal CUP (CUPSGP) che contengono le informazioni di prenotazione/accesso; Il Servizio di Censimento Anagrafico SISaR che restituisce, per ogni Paziente, il codice XMPI locale.

Su Xxxxxxx l’integrazione sarà di tipo sincrono. Il CUP invia un messaggio HL7 tramite un Web Service, una

volta che XXXXXXX riceve il messaggio converte quest’ultimo da OML ad ADT il quale viene inoltrato al Servizio

di Censimento Anagrafico SISaR.

Il Servizio di Censimento Anagrafico SISaR risponde con un messaggio HL7 di tipo ADT che contiene l’id locale. L’id locale viene aggiunto al messaggio HL7 inviato precedentemente dal CUP, il messaggio modificato viene

inoltrato al RIS e Xxxxxxx. La risposta del RIS viene inviata al CUP.

OE-RIS

L'integrazione OE-RIS implementa i flussi di:

invio ordini inseriti sull'OrderEntry Galileo alla Radiologia; ricezione messaggi di avanzamento di stato degli ordini emessi;

ricezione dei Referti di Radiologia per la registrazione sul Clinical Data Repository Galileo.

Inoltre Xxxxxxx invoca il visualizzatore immagini DICOM messo a disposizione dall’Amministrazione in modo da consentire, agli operatori di Reparto/Pronto Soccorso, l'accesso contestuale a tali informazioni per il Paziente selezionato.

Attualmente l'integrazione è attiva sugli Impianti di Sassari, Sanluri (1) e Cagliari e sugli impianti di Olbia e Carbonia con i prodotti RIS dell’Amministrazione.

Per l’integrazione Galileo-RIS sono presenti 3 flussi veicolati attualmente su JCaps.

Galileo → RIS, messaggi di tipo ORM; RIS → Galileo, messaggi di tipo MDM; RIS → Galileo, messaggi di tipo ORM;

I flussi verranno migrati da JCaps a XXXXXXX.

LIS - GEPADIAL

DNLab/Galileo–Gepadial (Cartella Dialisi): flussi basati sull’acquisizione analisi di laboratorio, invio referti su

CDR Galileo (solo ASSL Sassari) e allineamento anagrafico.

R.T. I. Xxxxxxxx S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

Come le successive integrazioni alle Cartelle Specialistiche, tale integrazione è stata resa disponibile al fine di:

Moderare le informazioni alle stesse anagrafiche sui Dipartimentali;

Evitare l'inserimento manuale delle informazioni (risultati analisi) già disponibili fra il Laboratorio ed il Clinical Data Repository;

Sull’impianto di Sassari, Galileo invia i risultati di Laboratorio a Gepadial tramite JCaps. Gepadial invia a Xxxxxxx i documenti delle visite tramite un canale punto-punto.

Xxxxxxx mette a disposizione di Xxxxxxxx la vista delle anagrafiche centralizzate, sulla quale quest’ultimo

preleva le informazioni inerenti ai pazienti.

L’impianto di Oristano, Xxxxxxx invia i risultati di Laboratorio a Gepadial tramite una istanza di Xxxxxxx 3.7.9.

L’impianto di Cagliari, Galileo invia i risultati di Laboratorio a Gepadial utilizzando la tecnica punto-punto. Sugli impianti di Cagliari e Sassari verranno creati i flussi ex-novo all’interno dell’applicativo PICASSO.

Nell’impianto di Oristano il flusso presente su PICASSO 3.7.9 verrà migrato sulla macchina ove vi è installato XXXXXXX aggiornato all’ultima versione.

LIS - EUROTOUCH

DNLab/Galileo-MyStar Connect (Cartella Diabetologica): acquisizione risultati di laboratorio e allineamento anagrafico.

Il flusso attualmente è veicolato in parte su JCaps e in parte con tecnica punto-punto. Su XXXXXXX sarà presente un nuovo canale verso MyStar per veicolare i messaggi ADT provenienti dal SISaR. Verrà creato un nuovo dbworker per la ricezione da parte di Xxxxxxx dei messaggi relativi ai pazienti diabetologici che vengono arruolati su MyStar.

XXXXXXX veicola le notifiche dei risultati di DNLab da Xxxxxxx a Mystar relativi ai pazienti diabetologici per cui è presente un episodio aperto del reparto SS-SERVIZIO DI DIABETOLOGIA.

LIS - SIT

Trasfusionale Eliot – DNLab e Trasfusionale Emonet – DNLab.

Emonet (Sassari, Sanluri, Carbonia): Emonet inserisce gli ordini su DNLab richiamando procedure SQL. I risultati vengono esposti sulle tabelle di frontiera di DNLab a cui Emonet accede.

Xxxxx (Olbia, Nuoro, Lanusei, Oristano): flusso bidirezionale punto-punto, tramite messaggi HL7.

Tutti i flussi sono attualmente veicolati tramite tecnica punto-punto o tabelle di frontiera, per ogni impianto PICASSO si occuperà di veicolare i relativi flussi.

R.T. I. Xxxxxxxx S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

LIS – KARDIA

L'integrazione LIS-Cartella Cardiologica di Emodinamica realizza il conferimento dei referti al Clinical Data Repository Galileo.

Integrazione gestita punto-punto tra i due applicativi per quanto concerne i messaggi di tipo referto, i quali vengono inviati da Kardia verso Galileo.

XXXXXXX si occuperà di gestire i messaggi di tipo ADT e MDM, con la creazioni di flussi ex-novo.

GALILEO-MARGHERITA 3

Galileo-Cartella Terapia intensiva - Aggiornamenti anagrafici ed eventi di tipologia ADT, attualmente veicolati tramite JCaps.

XXXXXXX si occuperà di gestire i messaggi di tipo ADT, con la creazioni di flussi ex-novo.

XXX EXT

LIS-Sistemi esperti Terapia Anticoagulante Orale – a seguito dell’inserimento delle richieste INR su LIS, l’integrazione invia i risultati ai Sistemi esperti per il calcolo della terapia.

Nell’impianto di Nuoro i risultati dell’INR prodotti dai POCT vengono inseriti direttamente su Galileo, che si occupa di esporli al Sistema Esperto Siemens Prometeo tramite tabelle di frontiera. Prometeo deposita i referti all’interno di una cartella condivisa a cui accede Galileo.

Negli impianti di Oristano e Sanluri tramite il middleware HALIA, che funge da concentratore, i risultati degli esami INR prodotti dai POCT, vengono inviati tramite messaggi HL7 al LIS, che a sua volta si occupa di inoltrarli via HL7 al sistema esperto di produzione delle terapie anticoagulanti Orali.

Nell’impianto di Cagliari i risultati dell’INR lavorati in laboratorio vengono inviati direttamente in HL7 a Xxxxxxx

e a Prometeo.

Negli impianti di Carbonia e Lanusei le integrazioni verranno realizzate ex-novo seguendo la documentazione fornita dai vari applicativi.

A seconda del presidio verranno creati i flussi di integrazione per leggere: documenti presenti su cartelle condivise, tabelle di frontiera etc. etc. Gli scambi di messaggi veicolati da XXXXXXX saranno effettuati con lo standard HL7.

SCR - AP

Screening Arianna – Anatomia Patologica ASSL Sassari. Il flusso gestisce i seguenti canali:

SCR-AP: Richiesta

SCR-AP: Cancellazione Richiesta SCR-AP: Modifica Richiesta

AP-SCR: Invio risultato

R.T. I. Xxxxxxxx S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

Attualmente il flusso è realizzato con tecnologia punto-punto; verrà quindi realizzato ex-novo.

SCR - ANAGS

AnagS è il sistema regionale di scelta e revoca dei MMG e PLS. Il suo Database degli assistiti ha la funzione di Anagrafe centralizzata regionale.

Con l’obiettivo di condividere le variazioni anagrafiche, il sistema AnagS produce giornalmente un flusso XML che viene prelevato ed elaborato per l’applicazione degli aggiornamenti sul DB anagrafico dello Screening (LHA). Tali aggiornamenti vengono poi estesi alle 8 istanze dello Screening Arianna (LHA locali), installati presso le 8 ASSL.

L’ESB ATS si occuperà di elaborare il file XML prodotto da AnagS producendo un flusso HL7 che verrà inviato allo Screening. Qualora l’elaborazione non potesse avvenire a causa dell’indisponibilità del file, Xxxxxxx elaborerà un messaggio di Warning sull’anomalia riscontrata, in modo tale che il file possa essere rielaborato.

SCR - LIS

Screening Sangue Occulto – LIS DNLab per esami sangue occulto, attualmente integrato tramite tecnica punto-punto.

Per l’integrazione tra Screening – DNLab verranno realizzati i seguenti flussi: Invio ordini da Screening verso il DNLab;

Ritorno risultati da LIS DNLab verso Screening.

SCR - RIS

I canali realizzati sono i seguenti:

SCR-RIS: Accettazione pazienti RIS-SCR: eseguito

RIS-SCR: prima lettura (No Oristano) RIS-SCR: seconda lettura (No Oristano)

Le integrazioni sono state realizzate tramite tecnica punto-punto. Esse verranno realizzate ex novo su Xxxxxxx.

Galileo – Pronto Soccorso SISaR

Galileo-PSWeb, flusso erogato dal Laboratorio al Pronto Soccorso.

A seconda della configurazione presente nell’impianto, i flussi varranno migrati da JCaps a XXXXXXX. Negli impianti dove il flusso è gestito tramite metodologia punto-punto, verrà realizzato un flusso ex-novo su PICASSO.

R.T. I. Xxxxxxxx S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

3.2.2. Migrazione integrazione centrale

Le integrazioni centrali da migrare sono le seguenti:

Integrazione Screening- AnagS; Integrazione MEDIR;

Integrazione MFP (SERD) (Solo ASSL Olbia, in fase di estensione da parte di SardegnaIT); Integrazione AVACS (Anagrafe vaccinale) – AnagS

SCR - ANAGS

AnagS è il sistema regionale di scelta e revoca dei MMG e PLS. Il suo Database degli assistiti ha la funzione di Anagrafe centralizzata regionale.

MEDIR

Le integrazioni FSE-MEDIR garantiscono la spedizione dei documenti clinici prodotti da vari applicativi al Fascicolo Sanitario Regionale. Tra di essi, il LIS riveste un’importanza strategica, soprattutto per la quantità di referti prodotti.

Tutte le integrazioni sono state realizzate secondo una logica punto-punto, in cui gli applicativi utilizzano una interfaccia messa a disposizione da MEDIR per la spedizione dei documenti. L’ESB Centrale diverrà l’interlocutore del FSE, mentre negli applicativi locali (a livello di ASSL), conferiranno i documenti all’ESB locale. L’integrazione di tutta la rete dei Laboratori dell’ATS avverrà quindi su un canale unico, in luogo degli attuali 8.

Lo schema di funzionamento è rappresentato nella figura seguente:

R.T. I. Xxxxxxxx S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

Figura 7: Integrazione ESB – MEDIR

MFP SER.D.

Il progetto regionale Ser.D. prevede una installazione unica regionale dell’applicativo mFp. L’installazione di

mFp è multi aziendale, con una istanza per ciascuna delle 8 ASSL, a loro volta organizzate in più sedi.

I flussi di integrazione informatizzati sono i seguenti:

Notifica nuova anagrafica (mFp vs. Galileo ASSL); Notifica degli esami eseguiti;

Notifica dei risultati degli esami.

Al momento l’integrazione risulta in produzione sul solo sito pilota, l’ASSL di Olbia, ma è stata realizzata e testata anche nelle altre 7 ASSL. Si attende che SardegnaIT provveda all’avviamento in produzione in tali siti.

AVACS (Anagrafe vaccinale) - AnagS

L’ESB ATS elabora il file XML prodotto da AnagS producendo un flusso HL7 che viene inviato al gateway di integrazione AVACS. Qualora l’elaborazione non potesse avvenire a causa dell’indisponibilità del file, Xxxxxxx elaborerà un messaggio di Warning che avvertirà dell’anomalia riscontrata, in modo tale che il file possa essere rielaborato.

R.T. I. Xxxxxxxx S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

3.3. Varianti introdotte

Al fine di mantenere la coerenza dei documenti progettuali, nel seguito vengono dettagliate le varianti introdotte che modificano, integrano e variano le descrizioni dei paragrafi precedenti.

Da rilevare che le varianti descritte dal paragrafo 3.3.1 al paragrafo 3.3.7 erano già previste nella versione 1.2 del Progetto dei Fabbisogni, mentre nella presente versione sono stati aggiunti i punti 3.3.8 e 3.3.9.

3.3.1. Varianti di nomenclatura

Nel progetto originario sono presenti imprecisione di nomenclatura di alcune componenti. Vengono adottate le seguenti varianti:

ASSL	INTEGRAZIONE	AZIONE	NOME CORRETTO	NOTE
OL	LIS – Kardia	CORREZIONE NOME	Kardia - Galileo	Variazione già presente alla documentazione e applicata ai piani di test.
SS	LIS – Gepadial	CORREZIONE NOME	Galileo – Gepadial	Variazione già presente alla documentazione e applicata ai piani di test.
SS	LIS –Eurotouch	CORREZIONE NOME	Galileo – SDC	SDC è l’abbreviazione di Smart Digital Clinic
OR	LIS – Gepadial	CORREZIONE NOME	Galileo – Gepadial	Variazione già presente alla documentazione e applicata ai piani di test.
OL	ADT-PS	CORREZIONE NOME	Flusso ADT	Variazione già presente alla documentazione e applicata ai piani di test.
OR	ADT-PS	CORREZIONE NOME	Flusso ADT	Variazione già presente alla documentazione e applicata ai piani di test.
SA	ADT-PS	CORREZIONE NOME	Flusso ADT	Variazione già presente alla documentazione e applicata ai piani di test.
SS	ADT-PS	CORREZIONE NOME	Flusso ADT	Variazione già presente alla documentazione e applicata ai piani di test.
CA	ADT-PS	CORREZIONE NOME	Flusso ADT	Variazione già presente alla documentazione e applicata ai piani di test.
CI	ADT-PS	CORREZIONE NOME	Flusso ADT	Variazione già presente alla documentazione e applicata ai piani di test.

R.T. I. Almaviva S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

ADT-PS

CORREZIONE NOME

Flusso ADT

Variazione già presente alla documentazione e applicata ai

piani di test.

ADT-PS

CORREZIONE NOME

Flusso ADT

Variazione già presente alla documentazione e applicata ai

piani di test.

LIS- Gepadial

CORREZIONE NOME

Galileo - Gepadial

Variazione già presente alla documentazione e applicata ai

piani di test.

3.3.2. Integrazioni ricomprese in altri sottosistemi

Nel seguito sono indicate le integrazioni ricomprese in altri sottosistemi, per cui le attività di migrazione vengono svolte in un ambito unitario e non è necessario uno specifico modulo applicativo e/o specifiche attività:

ASSL

INTEGRAZIONE

AZIONE

SPECIFICAZIONE

Canali

Galileo –

Margherita3

Non sono richieste attività apposite.

Attività di migrazione già inclusa nella migrazione

dell’integrazione ADT-PS

(rinominata in Flusso ADT)

3.3.3. Integrazioni da non effettuare

Nel seguito sono indicate le integrazioni previste nel progetto originario ma non realmente presenti sul campo in quanto dismesse o mai realizzate, e integrazioni realizzate in modalità fuori standard a causa della mancata evoluzione del sottosistema applicativo, per cui non verranno aggiornate e/o non daranno adito ad attività

nell’ambito del presente progetto:

ASSL

INTEGRAZIONE

AZIONE

SPECIFICAZIONE / COMMENTI

Canali

SCR – LIS

Integrazione dismessa ad Aprile 2019,

da eliminare

Il cliente finale ha deciso di comprare/inserire uno strumento dedicato alla ricerca sangue occulto. Prima della migrazione, il cliente aveva

richiesto di poter eseguire la ricerca del sangue

R.T. I. Almaviva S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

		dal piano delle attività	occulto sugli strumenti di chimica clinica. In seguito è stato inserito nelle dotazioni di laboratorio uno strumento dedicato alla ricerca del sangue occulto per lo screening. Attualmente non gli occorre più l’integrazione con gli strumenti di chimica clinica.
SS	LIS –SIT (Emonet)	Attuale integrazione fuori standard.	È fortemente sconsigliato intervenire sull’attuale integrazione in quanto non ci sono i presupposti per realizzare una architettura standard.	2
CI	LIS –SIT (Emonet)	Attuale integrazione fuori standard.	È fortemente sconsigliato intervenire sull’attuale integrazione in quanto non ci sono i presupposti per realizzare una architettura standard.	2
SA	LIS –SIT (Emonet)	Attuale integrazione fuori standard.	È fortemente sconsigliato intervenire sull’attuale integrazione in quanto non ci sono i presupposti per realizzare una architettura standard.	2
CI	TAO – EXT	Integrazione non presente, da eliminare dal piano delle attività	Il servizio TAO non è stato attivato.	2
LA	TAO – EXT	Integrazione non presente, da eliminare dal piano delle attività	Il servizio TAO è gestito dal trasfusionale e non vi è integrazione con il LIS.	2
NU	TAO – EXT	Attuale integrazione fuori standard HL7, da eliminare dal piano delle attività	Attuale integrazione realizzata attraverso un sistema di file transfert, lontano dagli standard HL7 quindi non sicuro farla passare per un integratore.	2

3.3.4. Integrazioni richieste in corso d’opera

Nel corso del progetto sono state richieste dalla Stazione Appaltante, per ragioni operative urgenti, le seguenti integrazioni che si sommano a quelle previste dal progetto:

ASSL

INTEGRAZIONE

AZIONE

SPECIFICAZIONE

CANALI

R.T. I. Almaviva S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

SS	Flusso ADT	OTTIMIZZAZIONE	Come richiesto dal DEC si è provveduto a separare il canale ADT da quello APC.	1
NU	Flusso ADT	OTTIMIZZAZIONE	Come richiesto dal DEC si è provveduto a separare il canale ADT da quello APC.	1
LA	Flusso ADT	Nuova Integrazione con Xxxxxxxxxx 3	A seguito della richiesta del DEC, si può integrare l’applicativo Margherita 3 con l’attuale flusso ADT.	1
NU	OE - RIS	Nuova Integrazione	A seguito della richiesta del DEC della realizzazione del nuovo flusso di integrazione	3

3.3.5. Integrazioni rilevate sul campo ma non presenti nel Progetto

Nella tabella sottostante sono riportate le integrazioni non presenti nei documenti progettuali precedenti ma in realtà esistenti, per cui sono state previste, nel presente documento, le nuove attività di migrazione rispetto a quanto previsto nel progetto dei fabbisogni 1.0 e 1.1.

ASSL	INTEGRAZIONE	AZIONE	SPECIFICAZIONE	Canali
NU	LIS - GALILEO	Nuova integrazione da prevedere	Rilevata l’integrazione per i referti inviati da Dnlab verso Galileo. Da non confondere con integrazione LIS PS in cui viene trasferito l’erogato di PS	1
SS	LIS - GALILEO	Nuova integrazione da prevedere	Rilevata l’integrazione per i referti inviati da Dnlab verso Galileo. Da non confondere con integrazione LIS PS in cui viene trasferito l’erogato di PS	1
LA	LIS - GALILEO	Nuova integrazione da prevedere	Rilevata l’integrazione per i referti inviati da Dnlab verso Galileo. Da non confondere con integrazione LIS PS in cui viene trasferito l’erogato di PS	1
OR	LIS - GALILEO	Nuova integrazione da prevedere	Rilevata l’integrazione per i referti inviati da Dnlab verso Galileo. Da non confondere con integrazione LIS PS in cui viene trasferito l’erogato di PS	1
CI	LIS - GALILEO	Nuova integrazione da prevedere	Rilevata l’integrazione per i referti inviati da Dnlab verso Galileo. Da non confondere con integrazione LIS PS in cui viene trasferito l’erogato di PS	1
SA	LIS - GALILEO	Nuova integrazione da prevedere	Rilevata l’integrazione per i referti inviati da Dnlab verso Galileo. Da non confondere con	1

R.T. I. Almaviva S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

			integrazione LIS PS in cui viene trasferito l’erogato di PS
CA	LIS - GALILEO	Nuova integrazione da prevedere	Rilevata l’integrazione per i referti inviati da Dnlab verso Galileo. Da non confondere con integrazione LIS PS in cui viene trasferito l’erogato di PS	1
OL	LIS - GALILEO	Nuova integrazione da prevedere	Rilevata l’integrazione per i referti inviati da Dnlab verso Galileo. Da non confondere con integrazione LIS PS in cui viene trasferito l’erogato di PS	1
OL	PSWEB - LIS	Nuova integrazione da prevedere	Emersa durante l’analisi di JCaps, il PSWEB inserisce ordini all’interno del LIS	1

3.3.6. Nuove integrazioni

Nel corso delle attività sono emerse nuove integrazioni non previste, la cui attivazione è necessaria per

l’ottimizzazione dei flussi:

ASSL	INTEGRAZIONE	AZIONE	SPECIFICAZIONE	CANALI
OL	Flusso ADT	OTTIMIZZAZIONE	Come per gli impianti di SS e NU è utile la separazione dei flussi. Questa operazione inoltre consente la standardizzazione degli impianti.	1
LA	Flusso ADT	OTTIMIZZAZIONE	Come per gli impianti di SS e NU è utile la separazione dei flussi. Questa operazione inoltre consente la standardizzazione degli impianti.	1
OR	Flusso ADT	OTTIMIZZAZIONE	Come per gli impianti di SS e NU è utile la separazione dei flussi. Questo operazione inoltre consente la standardizzazione degli impianti.	1
SA	Flusso ADT	OTTIMIZZAZIONE	Come per gli impianti di SS e NU è utile la separazione dei flussi. Questa operazione inoltre consente la standardizzazione degli impianti.	1
CI	Flusso ADT	OTTIMIZZAZIONE	Come per gli impianti di SS e NU è utile la separazione dei flussi. Questa operazione inoltre consente la standardizzazione degli impianti.	1
CA	Flusso ADT	OTTIMIZZAZIONE	Come per gli impianti di SS e NU è utile la separazione dei flussi. Questa operazione inoltre consente la standardizzazione degli impianti.	1

R.T. I. Almaviva S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

3.3.7. Modifiche alle integrazioni previste

Per quanto concerne l’integrazione SCR-RIS per gli impianti di Cagliari, Sassari e Oristano, verrà effettuato il nuovo indirizzamento a seguito del progetto di centralizzazione di SCR in corso. Sarà possibile effettuare una configurazione mista indirizzando il flusso parte verso la componente centralizzata e parte direttamente verso gli impianti non ancora aggiornati.

3.3.8. Integrazione con il Sistema Regionale di Diabetologia

Nel seguito viene descritta la nuova integrazione con il Sistema Regionale di Diabetologia.

La descrizione che segue inquadra l’intera problematica di interoperabilità sottesa dal progetto complessivo, che vede 34 Centri Diabetologici tra loro interconnessi con i laboratori di analisi e con la anagrafe regionale.

La componente prevista nel presente progetto non prevede le interconnessioni verso i sistemi Galileo e DNLab e le implementazioni presso i singoli Centri Diabetologici, oggetto di separata attività da parte della Amministrazione.

Viene pertanto prevista la componente di interoperabilità che comprende lo sviluppo e implementazione dei canali di integrazione per gli 8 ESB periferici e il ESB centrale. Da rilevare che quanto implementato per l’ESB di Sassari verso il sistema di diabetologia in logica dipartimentale e già in produzione dovrà essere riaggiornato in funzione della nuova architettura a livello regionale.

3.3.8.1. Integrazione con Sistema Regionale di Diabetologia

Nel seguito viene descritta l’analisi delle integrazioni tra i sistemi SDC-Galileo, per gli impianti ATS, tramite l’ESB PICASSO.

L’analisi fornirà i dettagli sugli attori in gioco nel flusso, messaggistica HL7 (versione utilizzata e tipologie di messaggi) nonché, informazioni sulle operazioni di filtraggio dei messaggi e di modifica degli stessi (laddove presenti).

Per l’analisi delle integrazioni dei flussi su XXXXXXX, seguiranno paragrafi di dettaglio circa le specifiche per ogni singolo canale: attori in gioco, filtri adottati, trasformazioni operate sui messaggi, versione HL7, tipologie di messaggi HL7 in gioco e router implementati.

3.3.8.2. Analisi realizzazione nuovo flusso su XXXXXXX

La figura mostra lo schema generale della nuova integrazione su XXXXXXX.

R.T. I. Almaviva S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

L’implementazione realizzata su XXXXXXX prevede la realizzazione di 2 canali sul sistema centrale e 16 sui locali (due per ogni impianto ATS). Per i canali relativi ai sistemi locali, verranno descritti a titolo esemplificativo i due canali relativi ad un singolo impianto, in quanto le integrazioni risultano analoghe per tutte aziende ospedaliere.

Figura 1 Flussi su Picasso centrale

R.T. I. Almaviva S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

Figura 2 Flussi su Picasso locale

R.T. I. Almaviva S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

3.3.8.3. Implementazione canale 1 PICASSO Centrale

Tipologia di integrazione

In termini di comunicazione dei messaggi HL7, il canale utilizza una modalità Asincrona. Questo significa che alla ricezione di un messaggio ADT da parte dell’applicativo SDC, Xxxxxxx invierà subito un ACK di risposta, per poi inviare successivamente il messaggio a uno dei destinatari basandosi sul contenuto del messaggio.

Il canale inoltre, implementa un tipo di comunicazione uno a molti.

Router

Il router utilizzato in questo canale è di tipo multiplo, il che permette l’invio di un singolo messaggio dal mittente a un destinatario. La selezione dell’impianto di destinazione avverrà tramite l’identificazione del reparto presente nel messaggio ADT.

Modifiche alla messaggistica HL7

Il canale implementato è di tipo Pass-Through, dunque non verrà effettuata alcuna modifica alla messaggistica

R.T. I. Almaviva S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

3.3.8.4. Implementazione canale 2 Picasso centrale

3.3.8.4.1. Tipologia di integrazione

In termini di comunicazione dei messaggi HL7, il canale utilizza una modalità Asincrona. Questo significa che alla ricezione di un messaggio OUL da parte dell’applicativo ESB Locale, XXXXXXX Centrale invierà subito un ACK di risposta, per poi inviare successivamente il messaggio all’unico destinatario previsto: SDC.

Il canale implementa un tipo di comunicazione uno ad uno.

3.3.8.4.2. Router

Il router utilizzato in questo canale è di tipo singolo.

3.3.8.4.3. Modifiche alla messaggistica HL7

Il canale implementato è di tipo Pass-Through, dunque non verrà effettuata alcuna modifica alla messaggistica.

R.T. I. Almaviva S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

3.3.8.5. Implementazione canale 3 Picasso Locale

3.3.8.5.1. Tipologia di integrazione

In termini di comunicazione dei messaggi HL7, il canale utilizza una modalità asincrono. Questo significa che alla ricezione di un messaggio ADT, da parte del ESB CENTRALE, XXXXXXX invierà subito il messaggio ai destinatari previsti (XMPI e Xxxxxxx), tramite la logica descritta in seguito.

In particolare, all’applicativo XMPI Xxxxxxx invierà un messaggio di tipo ADT^A28 contenente le informazioni essenziali per permettere l’arruolamento del paziente e rispondere con un messaggio di tipo ADT^A28 contenente il codice XMPI locale del paziente.

In seguito, il router si occuperà di invocare il canale dell’applicativo Galileo, inviandogli il messaggio originale con il codice XMPI appena ottenuto dal servizio di censimento anagrafico.

Il canale inoltre, implementa un tipo di comunicazione uno a molti.

3.3.8.5.2. Router

Il router utilizzato in questo canale è di tipo multiplo, custom Java.

3.3.8.5.3. Modifiche alla messaggistica HL7

I messaggi inviati dall’applicativo XMPI e Xxxxxxx, subiscono una trasformazione XSL. La trasformazione è applicata a tutti i messaggi in ingresso.

R.T. I. Almaviva S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

3.3.8.6. Implementazione canale 4 Picasso Locale

3.3.8.6.1. Tipologia di integrazione

In termini di comunicazione dei messaggi HL7, il canale utilizza una modalità Asincrona. Questo significa che alla ricezione di un messaggio OUL da parte dell’applicativo Xxxxxxx, XXXXXXX invierà subito un ACK di risposta, per poi inviare successivamente il messaggio al destinatario previsto: ESB Centrale.

Il canale implementa un tipo di comunicazione uno ad uno.

3.3.8.6.2. Router

Il router utilizzato in questo canale è di tipo singolo.

3.3.8.6.3. Modifiche alla messaggistica HL7

Il canale implementato è di tipo Pass-Through, dunque non verrà effettuata alcuna modifica alla messaggistica.

3.3.9. Stralcio Deploy ESB centrale inserita nella presente versione 1.3 del Progetto Lo sviluppo e la implementazione del ESB Centrale non comprenderà il deploy on premise sui sistemi di ATS Sardegna, in quanto questo verrà effettuato in urgenza da ATS stessa.

3.4. Quadro riassuntivo dei servizi e valorizzazioni delle varianti

Il quadro originario dei servizi descritto nel Progetto dei Fabbisogni 1.0 e dei costi associati era il seguente:

R.T. I. Almaviva S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

Le varianti in aumento e diminuzione descritte dal paragrafo 3.3.1 al paragrafo 3.3.7, già previste nella versione 1.2 del Progetto dei Fabbisogni, si compensano tra loro e non comportano un aumento o diminuzione dei servi previsti.

La variante in aumento descritta al punto 3.3.8 Integrazione Sistema Regionale Diabetologia comporta un maggior onore di servizi come sotto quantificato:

	Servizio	Tipologia di erogazione	Metrica di pricing	Modalità di erogazione	Modalità di consuntivazio ne	Periodicità di consuntivazion e	Prezzo unitario offerto (€)	quantità necessarie	valore economico
L3,S3,1	Analisi dettaglio integrazioni	ESB Periferici na	FP	Progettuale	A corpo	na	140,00	12	39.000,00 € 1.680,00 €
L3.S4.2	Sviluppo integrazioni	na	ervizio orchestrat	Progettuale	A corpo	na	4.000,00	8	32.000,00 €
L3.S3.1	Sviluppo integrazioni	na	FP	Progettuale	A corpo	na	140,00	28	3.920,00 €
L3.S3.1	Test Integrazioni	na	FP	Progettuale	A corpo	na	140,00	10	1.400,00 €
L3.S2.1	Analisi dettaglio integrazioni	ESB Centrale na	operation	Progettuale	A corpo	na	3.000,00	1	9.000,00 € 3.000,00 €
L3.S2.1	Sviluppo integrazioni	na	operation	Progettuale	A corpo	na	3.000,00	1	3.000,00 €
L3.S2.1	Test Integrazioni	na	operation	Progettuale	A corpo	na	3.000,00	1	3.000,00 €

La variante descritta al paragrafo 3.3.9. Stralcio Deploy ESB centrale comporta una diminuzione dei servizi come sotto quantificato:

Servizio

Tipologia di erogazione

Metrica di pricing

Modalità di erogazione

Modalità di consuntivazione

Periodicità di consuntivazione

Prezzo unitario offerto (€)

quantità necessarie

valore economico

L3.S4.2

Installazione ESB Centrale

servizio orchestrato

Progettuale

A corpo

4000

€ 16.000,0

Si riporta di seguito la tabella aggiornata con il dettaglio degli importi per servizio. I costi unitari dei servizi previsti risultano allineati rispetto all’aggiornamento entrato in vigore il 01/06/2020. I costi indicati si intendono IVA esclusa:

R.T. I. Almaviva S.p.A/ Almawave S.r.l/ Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

Lotto 3

ATS - ESB

€

697.000,00

Cod. Serv.

Nome Servizio

Tipolog ia di erogazi one

Metrica di pricing

Modalità di erogazio ne

Modalit à di consunt

ivazio

Periodi cità di consun tivazio

Prezzo unitario offerto

(€)

quantità necessarie

valore economico

L3.S2

Realizzazione interfacce web services

€

69.000,0

L3.S2.1

Sviluppo singola operation comprensivo di 12 mesi di garanzia

operation

rogettual

A corpo

€

3.000,00

€

69.000,0

L3.S3

Realizzazione client per la fruizione dei servizi

€

112.000,0

L3.S3.1

Sviluppo singolo FP comprensivo di 12 mesi di garanzia

rogettual

A corpo

€

140,00

800

€

112.000,0

L3.S4

Orchestrazione

€

516.000,0

L3.S4.2

Orchestrazione singolo servizio (orchestrazione di 10 o più serviz

io orches

rogettual

A corpo

€

4.000,00

129

€

516.000,0

3.5. Impegno delle risorse professionali

Su richiesta dell’Amministrazione e in relazione alle attività da svolgere, il mix professionale impegnato nella attività potrà variare rispetto a quanto previsto nel contratto quadro.

3.6. Indirizzo di dispiegamento dei servizi

Il Centro Servizi del RTI può essere considerato a tutti gli effetti un Data Center “virtuale” ed è costituito dalle

sedi che le aziende del RTI hanno attivato per la erogazione di tutti i servizi previsti dall’Accordo quadro SPC.

Il Centro Servizi è organizzato su 4 sedi (cfr. tabella seguente) dislocate sul territorio italiano: tre della mandataria Almaviva che ospitano sia il personale sia l’infrastruttura dedicata alle Amministrazioni contraenti, una di Xxxxx che prevede la presenza del solo personale.

Sede	Azienda RTI	Data Center	Indirizzo	Mq totali
Casal Boccone	Almaviva	√	xxx xx Xxxxx Xxxxxxx 000/000 - Xxxx	34.800
Scalo Prenestino	Almaviva	√	xxx xxxxx Xxxxx Xxxxxxxxxx 00 - Xxxx	11.200
Missaglia	Almaviva	√	xxx Xxxxxxxxx 00 - Xxxxxx	10.800
Xxxx	Xxxxx		xxx Xxxxxxx Xxxx 00 - Xxxx	2.600

I servizi oggetto del presente Progetto saranno erogati secondo le modalità previste dal Contratto Quadro, mentre saranno erogati dal Centro Servizi i Servizi Trasversali a supporto, qui di seguito elencati:

◼ Sistema di Controllo dei livelli di Servizio (SLAM);

◼ Portale di Governo della Fornitura (PGF);

◼ Help Desk (HD).

In particolare l’infrastruttura di Help Desk sarà ospitata nel Centro Servizi, mentre il personale di I livello opererà da postazioni presenti presso una sede del Gruppo AlmavivA e il personale di II livello opererà da postazioni presenti presso le sedi del RTI.

Vanno inoltre ricordati i Servizi di gestione necessari al buon funzionamento del Centro Servizi:

R.T. I. Almaviva S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

◼ Gestione della sicurezza dei Data Center, consiste messa in opera delle misure di tipo fisico, logico ed organizzativo atte ad assicurare in corso d’opera il mantenimento dei livelli di sicurezza coerenti con le politiche e con gli impegni assunti nei contratti e formalizzati nelle specifiche di servizio/configurazioni di servizio.

◼ Monitoraggio e controllo dei sistemi e della rete, consiste nell’utilizzo dell’infrastruttura hardware e software di base a supporto delle verifiche sulla disponibilità delle risorse dell’ambiente elaborativi e della rete e successivi controlli sui Log.

◼ Gestione dei Backup dei sistemi del Centro Servizi, consiste nell’utilizzo della infrastruttura a supporto

della applicazione delle politiche di backup e nel salvataggio in ambienti sicuri dei supporti utilizzati.

3.7. Modalità di esecuzione del collaudo dei servizi

I servizi oggetto del presente Contratto Esecutivo saranno sottoposti ad un collaudo “sul campo” da parte dell’Amministrazione.

Tale attività coinciderà con l’esecuzione del collaudo del primo progetto previsto nel Piano di Attuazione per

ciascun servizio.

R.T. I. Almaviva S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

4. MODALITÀ DI PRESENTAZIONE E APPROVAZIONE DEGLI STATI DI AVANZAMENTO

4.1. Gestione dei SAL

Gli stati di avanzamento mensili costituiscono lo strumento mediante il quale il RTI tiene informata

l’Amministrazione su tutte le attività che costituiscono il provisioning dei servizi da erogare (dal sopralluogo fino al collaudo finale e la relativa migrazione) e, successivamente, sullo stato di funzionamento e la qualità dei servizi stessi.

A tale scopo il Fornitore ed il RTI attivano un servizio di project management consistente nella pianificazione, gestione e verifica delle attività mirate al completamento del progetto.

Il project manager del Fornitore si confronterà con il responsabile di progetto nominato dall’Amministrazione

per la definizione ed esecuzione delle attività.

I report saranno prodotti con cadenza concordata con la Amministrazione e consegnati all’Amministrazione

secondo una modalità di comunicazione definita tra RTI ed Amministrazione.

4.2. Report di Stato di Avanzamento

Per quanto concerne le attività legate all'implementazione dei servizi, il flusso comunicativo può essere sintetizzato come segue:

◼ il project manager del RTI invia, mediante E-mail, il report SAL all’Amministrazione;

◼ l’Amministrazione, nella persona del suo responsabile di progetto, analizza, congiuntamente con il project manager del fornitore, la situazione di avanzamento, le eventuali modifiche rispetto al piano operativo previsto e le contromisure che il fornitore intende mettere in atto per recuperare gli eventuali ritardi verificatisi.

◼ Il responsabile dell’Amministrazione approva il report mediante comunicazione e-mail verso il fornitore.

Il report di Stato di Avanzamento contiene le seguenti informazioni:

◼ Avanzamento/Rispetto dei tempi previsti nel piano di attivazione;

◼ Eventuali ripianificazioni;

◼ Esito Tracking sui rischi;

◼ Esito dei test interni;

◼ Esito collaudi effettuati;

R.T. I. Xxxxxxxx S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

◼ Change emersi nel periodo;

◼ Azioni correttive/preventive applicate;

◼ Varie ed eventuali.

Tutti gli stati di avanzamento sono soggetti ad approvazione da parte dell’Amministrazione.

Nella fase di erogazione dei servizi il RTI manterrà la produzione mensile del SAL, orientati più a definire

l’andamento della erogazione, in termini di:

◼ Indicazioni su possibili problemi o anomalie eventualmente verificatisi;

◼ Proposte di modifiche/aggiornamenti da apportare;

◼ Proposte eventuali ottimizzazioni/migliorie da apportare all’organizzazione dei processi definiti;

◼ Varie ed eventuali.

Tali informazioni posso essere fornite utilizzando il template SPCL3-TMP-SALMensile-1.0.

R.T. I. Xxxxxxxx S.p.A/ Almawave S.r.l/ Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

5. PIANO DI ATTUAZIONE

5.1. Piano di Lavoro

Il piano di lavoro si sviluppa secondo quanto riportato nello schema seguente:

distribuzione dell'impegno nel tempo

2018

2019

2020

2021

Nome attività

Gennaio

Febbraio

Marzo

Aprile

Maggio

Giugno

Luglio

Agosto

Settebre

Ottobre

Novembre

Dicembre

Xxxxxxx

Xxxxxxxx

Xxxxx

Xxxxxx

Giugno

Luglio

Agosto

Settebre

Ottobre

Novembre

Dicembre

Gennaio

Febbraio

Marzo

Aprile

Maggio

Giugno

Luglio

Agosto

Settebre

Ottobre

Novembre

Dicembre

Gennaio

Febbraio

Xxxxx

Xxxxxx

Giugno

ATS ESB

Predisposizione Piattaforma

Sviluppo Integrazioni e primo rilascio

Completamento Piattaforma

Tuning Piattaforma

Le attività saranno concluse entro il 30/06/2021, fermo restando l’impegno a concluderle entro prima possibile.

5.2. Gestione della Sicurezza

Il documento SPCL3-SEC-Documento Programmatico sulla Sicurezza (DPS)-3.0.docx è il riferimento alle politiche di sicurezza implementate dal RTI per SPC lotto 3.

Relativamente agli specifici progetti sviluppati nell’ambito dei servizi richiesti dall’Amministrazione, sarà

implementato nel progetto il profilo di sicurezza per la riservatezza dei dati nonché le misure per soddisfarlo.

5.3. Piano di Qualità

Il documento SPCL3-GEN-PianoQualitaGenerale-2.2.docx è il piano di qualità di riferimento per il presente progetto.

R.T. I. Xxxxxxxx S.p.A/ Almawave S.r.l/

Indra Italia S.p.A/Pwc Public Sector S.r.l.

Sistema Pubblico di Connettività LOTTO 3

Progetto dei Fabbisogni

SPCL3-ATS_ESB-ProgettoFabbisogni v1.4

6. DATA DI ATTIVAZIONE

La data di attivazione dei servizi contrattualizzati è il 01/11/2018, come da verbale condiviso con

l’Amministrazione.

Document Metadata

Table of Contents

ATS Sardegna

Document Metadata