Contract
Capitolato tecnico e d’oneri Servizi ICT e di supporto organizzativo e operativo per la gestione del ciclo di vita dei sistemi informativi dell’Ecosistema Pagamenti della Regione Lazio |
CAPITOLATO TECNICO
Servizi ICT e di supporto organizzativo e operativo per la gestione del ciclo di vita dei sistemi informativi dell’Ecosistema Pagamenti della Regione Lazio
CIG: 9034923E4F
INDICE
4 Oggetto, durata e luogo di esecuzione 9
4.1 Oggetto e durata dell’appalto 9
4.2 Modalità di Erogazione dei Servizi 10
4.3 Luogo di Esecuzione dei Servizi 12
5.2 Dagli Accordi di Pagamento centralizzati all’Ecosistema Pagamenti: evoluzioni normative, organizzative e tecnologiche 14
5.3 Contesto Tecnologico e Applicativo 21
5.6 I processi di pagamento 30
5.7 Sistemi applicativi coinvolti 32
6 Descrizione dei servizi oggetto dell’appalto 35
6.1 Servizi di supporto organizzativo 35
6.1.1 ID SOC - Consulenza specialistica in continuità 35
6.1.2 ID SOE - Consulenza specialistica per le evoluzioni dei sistemi e il supporto ad altre Direzioni 37
6.1.3 ID SOP - Supporto alla revisione dei processi e Process Mining 38
6.1.4 ID SOG - Governance di progetto e PMO 39
6.2 Servizi di supporto operativo 40
6.2.1 ID SCM - Change Management 40
6.2.2 ID SAB – Servizi di assistenza e backend 40
6.2.3 ID SPP Supporto ai processi di pagamento 42
6.3 Servizi ICT e sviluppo Software 43
6.3.1 ID MSW - Manutenzione Evolutiva 44
6.3.2 ID GAP - Gestione del portafoglio applicativo – Gestione Applicativi e Basi Dati 44
6.3.3 ID SSW Sviluppo Software 49
6.4 Riepilogo delle giornate uomo e Team Mix per i Servizi Richiesti 55
7 Focus sul progetto di reingegnerizzazione: requisiti 60
7.1 Architettura funzionale Ecosistema Pagamenti 60
7.1.1 Dettaglio funzionalità soluzione Obiettivo 63
7.1.1.1 Enterprise Application Services 63
7.1.1.1.1 Identity Access Management 63
7.1.1.1.2 Logging/Audit Trail 67
7.1.1.1.3 Eventi/Messaggi Applicativi 69
7.1.1.1.4 File/Doc Repository 72
7.1.1.2 Core Functional Services 73
7.1.1.2.2 Case Management tool 76
7.1.1.2.3 Business Rules Riconciliazione 2.0 e Pagamenti 2.0 103
7.1.1.2.4 Reportistica 107
7.1.1.2.5 Ordini 109
7.1.1.3 Integration Services 110
7.1.1.3.1 Integrazione con Provider di servizi di posta elettronica 110
7.1.1.3.2 Flussi Prestazioni Sanitarie 110
7.1.1.3.3 Flussi di Fatturazione e Pagamento 111
7.1.1.3.4 Interazioni con il cittadino 112
7.1.1.3.5 Integrazione con PCC 113
7.2 Architettura tecnologica dell’Ecosistema Pagamenti 116
7.2.1 Componenti software e applicative 116
7.3 Fasi realizzative del progetto di reingegnerizzazione 127
8 Requisiti e Competenze Generali per l’Erogazione dei Servizi 134
8.1 Obblighi dell’Appaltatore 134
8.2 Requisiti Minimi dei Servizi Realizzativi 134
8.3 Requisiti di Sicurezza della Fornitura 139
8.4 Requisiti di Usabilità e Accessibilità 140
8.5 Requisiti Architetturali 140
8.6 Requisiti per i Container 142
8.7 Competenze Funzionali, metodologiche, applicative e tecnologiche 143
8.7.5 Competenze Funzionali e Tematiche 143
8.7.6 Competenze Metodologiche 144
8.8 Competenze Applicative 144
8.9 Competenze Tecnologiche 145
8.10 Attività Propedeutiche all’Erogazione dei Servizi 146
8.11 Attività di Fine Fornitura - Trasferimento di Know How 148
8.12 Requisiti di Qualità della Fornitura 149
8.12.4 Piano di Qualità 150
8.13 Orario di Erogazione dei Servizi 151
8.14 Strumenti a Supporto dell’Operatività della Fornitura 152
8.15 Modalità di Erogazione 152
8.16 Assenza di Virus 153
8.16.1 Verifiche di Conformità 153
8.17 Monitoraggio 155
8.18 Azioni Contrattuali 156
8.18.4 Rilievi 157
8.18.5 Indici di Prestazione 157
8.19 Strumenti a Supporto della Fornitura 157
1 INTRODUZIONE
La presente procedura di gara volta all’acquisizione dei “Servizi ICT e di supporto organizzativo e operativo per la gestione del ciclo di vita dei sistemi informativi dell’Ecosistema Pagamenti della Regione Lazio” è indetta e gestita in nome e per conto della Regione Lazio da LAZIOcrea S.p.A.
Nei successivi capitoli sarà descritto il contesto, l’oggetto e le caratteristiche complessive dell’appalto con il dettaglio dei prodotti e servizi richiesti e i relativi livelli di servizio che l’Appaltatore DEVE garantire nell’esecuzione dell’appalto.
Le indicazioni contenute nel presente Capitolato Tecnico e nelle relative appendici rappresentano i requisiti minimi che devono essere obbligatoriamente soddisfatti per l’affidamento dei servizi, fermo restando quanto specificato nel Disciplinare in tema di
valutazione delle offerte e di attribuzione dei punteggi.
Gli allegati al presente Capitolato Tecnico e relative appendici, che ne costituiscono parte integrante e sostanziale, sono i seguenti documenti:
• Appendice_1:Profili_professionali;
• Appendice_2:Indicatori_di_qualità;
• ALLEGATO 1 - CONTESTO TECNOLOGICO - SIPA
• ALLEGATO 2 - CONTESTO TECNOLOGICO – VES
• ALLEGATO 3 - CONTESTO TECNOLOGICO – BRIDGE
• ALLEGATO 4 - CONTESTO TECNOLOGICO – MOR
• ALLEGATO 5 - CONTESTO TECNOLOGICO - BM
2 DEFINIZIONI
Nel seguito del presente Capitolato d’Oneri, con il termine:
• “Bando di gara” o “Bando”, si intende l’Avviso spedito all’Ufficio Pubblicazioni Ufficiali dell’Unione Europea e pubblicato secondo legge, allo scopo di diffondere l’intenzione di affidare, mediante gara, le attività oggetto del presente appalto;
• “Capitolato Tecnico e d’Oneri” o “Capitolato”, si intende il presente documento che contiene tutte le informazioni tecniche relative alle condizioni, alle modalità ed ai termini per l’esecuzione delle attività oggetto del presente appalto;
• “Schema di contratto”: si intende il documento che contiene le clausole legali relative a termini
di esecuzione, obblighi, oneri dell’appaltatore, modalità di pagamento e condizioni, modalità e termini per l’esecuzione delle attività oggetto dell’appalto;
• “Disciplinare di gara”, si intende il documento che contiene tutte le informazioni relative alle condizioni ed alle modalità di redazione e di presentazione delle offerte, ai criteri di
aggiudicazione, alle cause di esclusione e di decadenza, nonché agli obblighi dell’Aggiudicatario per la stipula del contratto di appalto;
• “Atti di gara”, si intende l’insieme dei documenti di cui sopra (Bando – Capitolato Tecnico e
d’Oneri – Disciplinare di gara- Schema di contratto);
• “Informazioni complementari”, si intendono le informazioni e i chiarimenti forniti dalla Società Appaltante ai sensi di quanto previsto dal Disciplinare di gara;
• “Società Appaltante”, si intende la LAZIOcrea S.p.A.;
• “Aggiudicatario”, si intende il soggetto che, al termine della procedura di gara, è risultato Aggiudicatario del presente appalto;
• “Appaltatore”, si intende il soggetto che, essendo risultato Aggiudicatario del presente appalto, ha stipulato il contratto con la Società Appaltante;
• “R.O.E.”, si intende un raggruppamento di operatori economici, costituito o costituendo ai sensi dell’art. 48 del D. Lgs. n. 50/2016, che ha presentato un’offerta per concorrere all’aggiudicazione del presente appalto;
• “Parti”, si intendono, congiuntamente, la Società Appaltante e l’Appaltatore;
• “Utente”, si intende qualsiasi soggetto utilizzatore del Sistema oggetto del presente appalto;
• “Riuso”, si intende il processo delineato dal CAD (art. 69) con il quale una amministrazione
distribuisce («mettere a riuso») un software di cui ha titolarità in Open Source, a favore di altre amministrazioni che possano utilizzarlo («prendere a riuso»). Tutto il software a riuso è OpenSource.
Nel presente documento sono utilizzati i termini chiave “DEVE”, “NON DEVE”, OBBLIGATORIO”,
con i quali si definiscono elementi, requisiti, specifiche, condizioni che devono essere obbligatoriamente implementati/soddisfatti, fermo restando quanto specificato nel Disciplinare di
gara in tema di esclusione dalla procedura di gara e nel seguito del presente documento in tema di verifiche e di penali e/o di risoluzione-recesso.
3 SIGLE E ACRONIMI
AASS | Aziende Sanitarie |
AGID | Agenzia per l'Italia Digitale |
CA | Certificate Authority |
CRL | Certificate Revocation List |
X.X.xx | Decreto Legislativo |
DCA | Decreto Commissario ad Acta |
DCROnline | Sistema Distinta Contabile Riepilogativa |
DDT | Documento di Trasporto |
DGR | Delibera di Giunta Regionale |
DM | Decreto Ministeriale |
DURC | Documento Unico di Regolarità Contributiva |
ESIPA | Ecosistema Pagamenti |
MEF | Ministero Economia e Finanze |
MOR | Modulo Ordini Regionale |
NSO | Nodo Smistamento Ordini |
OPI | Ordinativo Pagamento Informatico |
PA | Pubblica Amministrazione |
PAC | Piano Attuativo della Certificabilità |
PCC | Piattaforma Certificazione Crediti |
RGS | Ragioneria Generale dello Stato |
SDI | Sistema di Interscambio |
SIOPE+ | Sistema Informativo sulle Operazioni degli Enti Pubblici |
SIPA | Sistema Pagamenti |
SIRIPA | Sistema Informativo Regionale Integrato Procedimenti Amministrativi |
SOGEI | Società Generale d'Informatica S.p.A. |
SPID | Sistema Pubblico di Identità Digitale |
SSR | Sistema Sanitario Regionale |
UE | Unione Europea |
24/7 | 24 ore su 24, 7 giorni su 7, 365 giorni all’anno. |
BRIDGE | Piattaforma di Intermediazione regionale verso SIOPE+ |
4 OGGETTO, DURATA E LUOGO DI ESECUZIONE
4.1 Oggetto e durata dell’appalto
Il presente appalto ha ad oggetto i servizi di presa in carico (Subentro), trasferimento di know how, supporto organizzativo e operativo, analisi e progettazione, sviluppo applicativo, manutenzione, gestione applicativi e delle base dati dei Sistemi Informativi dell’Ecosistema
Pagamenti della Regione Lazio, di seguito elencati e meglio dettagliati nel prosieguo.
I servizi oggetto del presente appalto sono suddivisi nei seguenti ambiti:
• Servizi di Supporto Organizzativo
ID SOC - Consulenza specialistica in continuità
ID SOE - Consulenza specialistica per le evoluzioni dei sistemi e il supporto ad altre Direzioni
ID SOP - Supporto alla revisione dei processi e Process Mining ID SOG - Governance di progetto e PMO
• Supporto Operativo
ID SCM Change Management ID SAB Assistenza e backend
ID SPP Supporto ai processi di pagamento
• Servizi ICT e sviluppo Software ID MSW Manutenzione Evolutiva
ID GAP Gestione del portafoglio applicativo – Gestione Applicativi e Basi Dati
ID SSW Sviluppo Software.
La durata del presente appalto decorre dalla data di avvio dell'esecuzione del contratto (Kick off), ferma la facoltà, ai sensi dell’art. 32 del D. Lgs. n. 50/16, di procedere all’avvio delle prestazioni nelle more del perfezionamento di tutti gli atti amministrativi necessari, e termina dopo 36 (trentasei) mesi dall’avvenuta presa in carico dei sistemi informatici facenti parte
dell’Ecosistema Pagamenti e delle attività di supporto organizzativo e operativo.
La data di avvio dell'esecuzione del contratto sarà comunicata all’Appaltatore dal Direttore dell'esecuzione nominato dalla Società Appaltante, fermo restando che l’avvio dell’esecuzione
dovrà avvenire entro e non oltre 15 (quindici) giorni naturali e consecutivi dalla data di stipula del contratto tra l’Appaltatore e la Società Appaltante, salvo diverso accordo scritto tra le Parti.
In ogni caso, il Direttore dell’Esecuzione sulla base delle disposizioni del RUP, dopo che il contratto è divenuto efficace, dà avvio all’esecuzione della prestazione, fornendo all’esecutore
tutte le istruzioni e direttive necessarie e redigendo apposito verbale firmato anche dall’esecutore, di avvio dell'esecuzione del contratto, ai sensi di quanto previsto dall'art. 19 del
D.M. 7 marzo 2018 n. 49 recante «Approvazione delle linee guida sulle modalità di svolgimento
delle funzioni del direttore dei lavori e del direttore dell’esecuzione».
In considerazione di quanto sopra, la durata del presente appalto non potrà essere tacitamente prorogata o rinnovata.
La durata del contratto in corso di esecuzione potrà essere modificata per il tempo necessario
alla conclusione delle procedure necessarie per l’individuazione di un nuovo contraente, ai sensi dell’art. 106, comma 11 del D. Lgs. n. 50/2016. In tal caso il contraente è tenuto all’esecuzione delle prestazioni oggetto del contratto agli stessi, o più favorevoli, prezzi, patti e condizioni.
4.2 Modalità di Erogazione dei Servizi
I servizi oggetto del presente appalto DOVRANNO essere erogati in modalità a corpo e a misura, come di seguito meglio precisato. Fermo restando quanto previsto nell’art. 59, comma 5 bis del D. Lgs. n. 50/2016, che prevede che per le prestazioni a corpo il prezzo offerto rimane
fisso e non può variare in aumento o in diminuzione, secondo la qualità e la quantità effettiva dei servizi eseguiti, mentre per le prestazioni a misura il prezzo convenuto può variare, in aumento o in diminuzione, secondo la quantità effettiva dei servizi eseguiti, si precisa quanto segue.
Nella modalità a corpo la responsabilità del risultato è affidata all’Appaltatore, il quale organizza le proprie risorse professionali, tecniche e metodologiche per soddisfare le richieste: tipico esempio è l’affidamento di un obiettivo di sviluppo in cui la Società Appaltante fornisce gli
elementi generali della “soluzione TO BE” in termini di macro esigenze da realizzare/modificare,
utenza coinvolta, contesto tecnologico e applicativo di partenza e vincoli di spesa/tecnologia (il contesto AS IS, nuovi adempimenti legati a leggi e normative, ecc.). L’Appaltatore declina i
requisiti funzionali e non funzionali e l’analisi d’impatto, disegna la soluzione (progettazione
esecutiva) e definisce tutti gli elementi del piano di lavoro, il dettaglio dei prodotti, tutti i costi in giornate uomo, fornendo tutti gli elementi per oggettivare la proposta e i relativi costi.
Con l’approvazione del piano di lavoro da parte della Società Appaltante, l’Appaltatore ne è responsabile, e, pertanto, non potrà richiedere maggiori costi a fronte di ritardi nella consegna
(errata valutazione dei tempi o errata allocazione delle risorse o incompetenza delle risorse, difettosità eccessiva del software realizzato, o mancata comprensione dei requisiti utenti, introduzione di nuove normative nazionali e/o regionali, ecc.), o per rimediare ad un livello di qualità insufficiente, o rimediare a buchi di analisi o insufficiente attività di testing, ecc.
Per tutti i servizi che saranno erogati a misura, sulla base di una richiesta della Società Appaltante, l’Appaltatore DOVRÀ presentare un apposito Piano delle attività (PAI), che DOVRÀ essere approvato formalmente dalla Società Appaltante.
Laddove il PAI non venga ritenuto adeguato ad insindacabile giudizio della Società Appaltante, l’Appaltatore DOVRÀ ripresentarlo. Per gli indicatori di qualità della fornitura relativa alla definizione del PAI, si rimanda a quanto indicato negli indicatori di qualità in Appendice 2.
In ciascun Piano delle attività, l’Appaltatore DOVRÀ indicare:
• il numero delle risorse da utilizzare, suddivise per profilo professionale;
• il numero di giornate/uomo da impiegare, per ciascuna risorsa da utilizzare;
• l’importo complessivo;
• la descrizione delle attività da realizzare;
• le tempistiche di realizzazione e gli output/deliverable previsti;
• il piano dei test e collaudo (ove applicabile).
Con riferimento alle attività pianificate e approvate dalla Società Appaltante, al termine dell’esecuzione dell’attività richiesta, l’Appaltatore DOVRÀ presentare un Rapporto di riepilogo delle attività effettivamente erogate, che verranno valutate dalla Società Appaltante attraverso
uno o più degli indicatori di qualità previsti dalla fornitura.
Resta inteso che, in ogni caso, la Società Appaltante riconoscerà e autorizzerà il pagamento delle sole attività effettivamente svolte e che abbiano avuto quale risultato la corretta esecuzione di quanto approvato dalla stessa nel Piano delle attività.
Nel caso in cui la valutazione delle attività non soddisfi gli obiettivi richiesti, l’attività oggetto della valutazione non può essere considerata conclusa e l’Appaltatore DOVRÀ mettere in atto, senza alcun onere a carico della Società Appaltante tutte le possibili azioni correttive al fine di
ottenere il raggiungimento degli obiettivi richiesti e quindi la corretta esecuzione e conclusione dell’attività.
La Società Appaltante procederà al pagamento e allo scorporo (dal monte di giornate/persona destinate al servizio) delle sole giornate/persona indicate nei Piani delle attività preventivamente approvati dalla Società Appaltante stessa.
Fermo restando quanto sopra, la Società Appaltante si riserva l’insindacabile facoltà di utilizzare in tutto o in parte le giornate/persona messe a disposizione dall’Appaltatore e nessun compenso sarà riconosciuto/dovuto dall’Appaltatore per le giornate/persona eventualmente non utilizzate.
4.3 Luogo di Esecuzione dei Servizi
I servizi oggetto del presente Capitolato Tecnico DOVRANNO essere erogati presso le sedi dell’Appaltatore e/o della Società Appaltante e/o della Regione Lazio, sulla base delle necessità operative che saranno indicate dalla Società Appaltante.
5 CONTESTO
LAZIOcrea S.p.A. affianca la Regione Lazio nelle attività tecnico-amministrative, offrendo servizi di gestione e organizzazione delle attività di interesse regionale ed in particolare:
• presta servizi di elaborazione, predisposizione, archiviazione e controllo dei documenti per la gestione dei piani operativi regionali e dei programmi operativi co-finanziati dall’Unione Europea;
• lavora alla realizzazione del sistema informativo regionale, contribuendo alla semplificazione e digitalizzazione dei processi interni della Regione Lazio e allo sviluppo di soluzioni capaci di ridurre i costi della spesa pubblica;
• realizza progetti infrastrutturali di rete e di servizi sul territorio, svolgendo un ruolo di coordinamento per i progetti di e-government e assicurando l’erogazione di servizi essenziali, dall’emergenza sanitaria alla protezione civile;
• supporta la Regione Lazio nella definizione delle strategie di crescita digitale, progettando e realizzando le attività connesse all’agenda digitale, e-government e open government per offrire servizi ad alto contenuto tecnologico per cittadini e imprese.
• opera a supporto della Regione Lazio nell’ambito della gestione centralizzata dei pagamenti ai fornitori delle Aziende Sanitarie e Ospedaliere regionali
Il modello strategico di evoluzione delle infrastrutture e dei servizi IT forniti da LAZIOcrea S.p.A. a Regione Lazio nel corso di questi ultimi anni si sta adeguando al modello strategico individuato dal Piano Triennale della Pubblica Amministrazione per la trasformazione digitale del Paese, che prevede macro ambiti di intervento relativi alla modernizzazione applicativa e al
cloud, alla connettività, all’interoperabilità, alle piattaforme e ai dati della PA, alla sicurezza, agli
ecosistemi e all’accesso ai servizi.
L’oggetto del presente appalto si riferisce all’ambito specifico della centralizzazione dei pagamenti ai fornitori del SSR i cui dettagli sono descritti nei paragrafi successivi.
L’Appaltatore fornirà i servizi richiesti, secondo le modalità e alle condizioni espresse nel presente Capitolato Tecnico.
I sistemi informativi rientrano tra le risorse indispensabili per il perseguimento degli obiettivi regionali, rappresentano lo strumento attraverso cui rendere ulteriormente efficiente il modello strategico e di governance per monitorare le attività svolte dalle diverse articolazioni e ai diversi livelli del SSR, ponendole in rapporto sia con le risorse impiegate per la loro realizzazione sia con gli esiti di salute prodotti. Le informazioni, la loro disponibilità e la loro circolarità
rappresenteranno, inoltre, una risorsa straordinaria, e al tempo stesso indispensabile, per affrontare la trasformazione del SSR verso una visione di trasversalità di processi amministrativi, contabili e sanitari.
5.2 Dagli Accordi di Pagamento centralizzati all’Ecosistema Pagamenti: evoluzioni normative, organizzative e tecnologiche
Il percorso legislativo in tema di Pagamenti e Fatturazione Elettronica parte dalla Legge 244 del 24 dicembre 2007 (Finanziaria 2008). Attraverso tale norma, si impone ai fornitori di relazionarsi con la Pubblica Amministrazione (PA) esclusivamente inviando fatture in formato elettronico attraverso un sistema centrale che ha la funzione di nodo centralizzato per il dispatching delle fatture verso la PA.
La Regione Lazio, con deliberazione della Giunta Regionale n.689/2008, ha approvato la sottoscrizione di specifici accordi con i soggetti che intrattengono rapporti con il Sistema Sanitario Regionale (SSR) al fine di gestire, secondo procedure uniformi, i crediti commerciali oggetto di fatturazione a decorrere dal 01 gennaio 2009. È stato quindi avviato il progetto
“Sistema Accordo Pagamenti”, all’interno del piano di attività volte alla razionalizzazione degli
acquisti e l’ottimizzazione dei processi di pagamento in grado di consentire un controllo dei tempi di liquidazione e di garantire puntualità, trasparenza ed omogeneità nel pagamento dei
fornitori del SSR. Il progetto si è attuato nelle seguenti fasi:
• Fase 1: Avvio degli Accordi di Pagamento con possibilità di adesione da parte di tutti i soggetti che intrattengono rapporti di fornitura con il SSR;
• Fase 2: Introduzione di una Piattaforma SIPA (Sistema Pagamenti), integrata con i sistemi gestionali delle Aziende Sanitarie, finalizzata alla gestione e al monitoraggio dell’intero ciclo passivo mediante la digitalizzazione delle fatture e la loro trasmissione alle Aziende del SSR. LAZIOcrea, in qualità di Società totalmente partecipata dalla
Regione Lazio e operante nei confronti della stessa secondo le modalità dell’in-house providing, ad oggi gestisce il SIPA, così come previsto dall’attuale Contratto Quadro di servizi con la Regione Lazio;
• Fase 3: Diffusione e divulgazione dei nuovi processi di gestione del ciclo passivo a tutte le Aziende Sanitarie e i Fornitori del Sistema Sanitario Regionale aderenti agli Accordi di Pagamento.
In questo modo la Regione Lazio ha reso esecutive nuove modalità di pagamento per mezzo del Sistema Pagamenti ed ha imposto la sottoscrizione di specifici accordi tra fornitori e gli enti del Servizio Sanitario regionale, vincolando il pagamento delle fatture dei fornitori del SSR alla condivisione di procedure uniformi, con l’obiettivo di razionalizzazione della spesa sanitaria
regionale, in termini di riduzione degli interessi per le somme dovute, del contenzioso e del
contenimento del numero di giorni necessari ad effettuare i pagamenti dei crediti oggetto di fatturazione.
Per consentire lo scambio di dati tra i vari soggetti che si interfacciano con il Sistema Pagamenti sono stati attivati protocolli di colloquio con i sistemi gestionali delle Aziende basati su servizi web deputati alle distinte fasi del ciclo passivo per l’acquisto dei beni e servizi sanitari delle
Aziende Sanitarie Regionali. In particolare, le predette interazioni fra sistemi riguardano:
• Trasmissione delle Fatture
• Gestione degli ordini: le Aziende Sanitarie/Ospedaliere trasmettono gli ordini elettronici dei farmaci attraverso il Sistema Regionale, il quale è integrato con la piattaforma Dafne (xxxxx://xxx.xxxxx.xx.xxx.xxx/), provider delle case farmaceutiche consorziate;
• Documenti di trasporto (DDT);
• Carichi di magazzino.
Nell’aprile 2013, con Decreto n. 55/2013, il MEF pubblica il “Regolamento in materia di emissione, trasmissione e ricevimento della fattura elettronica da applicarsi alle amministrazioni pubbliche ai sensi dell'articolo 1, commi da 209 a 213, della legge 24 dicembre 2007, n. 244” che recepisce la Legge del 2007.
Il succitato Decreto definisce il formato della fattura elettronica, le regole tecniche relative alle modalità di emissione, trasmissione e ricevimento della stessa attraverso il Sistema di Interscambio (SDI) gestito dall'Agenzia delle Entrate, che è il sistema informatico in grado di ricevere le fatture sotto forma di file con le caratteristiche della FatturaPA, effettuare controlli sui file ricevuti, inoltrare le fatture alle Amministrazioni destinatarie.
La normativa prevede inoltre che le Pubbliche Amministrazioni possano costituirsi come intermediari nei confronti di altre Pubbliche Amministrazioni o nei confronti degli Operatori Economici offrendo servizi per la trasmissione, la conservazione e l'archiviazione della fattura elettronica.
Per rispettare la scadenza del 31/03/2015 sancita del suddetto Decreto 55/2013 che prevedeva la ricezione delle fatture indirizzate alla Pubblica Amministrazione unicamente dal Sistema di Interscambio, Regione Lazio, per mezzo della società LAZIOcrea, ha evoluto il “Sistema
Accordo Pagamenti” in un sistema informatico denominato “Fatturazione Elettronica e Sistema
Pagamenti del SSR”: la Regione Lazio, in qualità di intermediario, garantisce esclusivamente il servizio di trasmissione/ricezione del file FatturaPA da/verso il Sistema di Interscambio (SDI).
Pertanto con l'entrata in vigore della legge sulla fatturazione elettronica, il sistema informatico regionale si è integrato con il SDI dell’Agenzia delle Entrate avendo quindi il ruolo di intermediario per le Aziende Sanitarie della Regione Lazio.
A fronte di ciò, tutti i documenti contabili immessi nei confronti delle Aziende Sanitarie della Regione Lazio esclusivamente nel formato "FatturaPA", dovranno essere accettati e veicolati dal SDI verso il Sistema Pagamenti che provvederà al conseguente invio alle Aziende Sanitarie.
Parallelamente è stato realizzato un servizio di intermediazione sia per la fatturazione attiva che per la fatturazione passiva rivolto ad altre pubbliche amministrazioni del territorio, enti locali e società partecipate (“Sistema HUB”): Tale servizio è rivolto ad Enti e Società controllate dalla
Regione Lazio e firmatarie dell’”Accordo di servizio per la fatturazione elettronica” ed è
finalizzato alla trasmissione, conservazione a norma e archiviazione della fattura elettronica.
Il servizio è finalizzato a creare un canale tramite il quale è stato realizzato il servizio di intermediazione che viene offerto sia per la fatturazione attiva che per la fatturazione passiva secondo le seguenti caratteristiche:
• Fatturazione Attiva: predisposizione di documenti contabili in formato fatturaPA;
• Fatturazione Passiva: ricezione di documenti contabili elettronici indirizzati al codice IPA della PA.
Il sistema, inoltre, intermedia anche le fatture passive con committente Regione Lazio attraverso il riconoscimento del codice IPA inserito nella fattura e le trasmette direttamente al sistema di bilancio S.I.R.I.P.A. - Sistema Informativo Regionale Integrato Procedimenti Amministrativi.
Con l’obiettivo di automatizzare il monitoraggio dei pagamenti e degli incassi delle PA e, in particolare, dei tempi di pagamento dei debiti commerciali, l’art. 1, comma 533, della legge 11 dicembre 2016, n. 232, ha reso obbligatorio l’utilizzo degli ordinativi elettronici, «[...]emessi secondo lo standard Ordinativo Informatico emanato dall'Agenzia per l'Italia digitale[...]», e
trasmessi alla Banca Tesoriera per il tramite della piattaforma SIOPE+. Quest’ultima, attualmente gestita dalla Ragioneria Generale dello Stato e dalla Banca d’Italia, intermedia tutti gli ordinativi di incasso e pagamento emessi e integra le informazioni rilevate con quelle delle
fatture passive registrate dalla Piattaforma dei Crediti Commerciali (PCC).
LAZIOcrea, nell’ambito dei servizi offerti di supporto alla Regione Lazio nella definizione delle
strategie di crescita digitale, rende disponibile una interfaccia informatica (c.d. BRIDGE) in grado di recepire dai sistemi gestionali delle Aziende Sanitarie il mandato in formato OPI firmato digitalmente dalle Aziende stesse ed inviarlo a Banca d’Italia per effettuare il pagamento del
debito secondo le disposizioni di cui alla normativa sul SIOPE+.
Il Decreto del Commissario ad Acta n. U00289 del 7 luglio 2017, avente ad oggetto “Definizione delle nuove procedure di pagamento per le diverse categorie di creditori delle Aziende del SSR, a partire dal 1° gennaio 2018”, definisce un nuovo processo di pagamento di tutte le fatture elettroniche gestite sul Sistema di Fatturazione Elettronica e Pagamenti, necessario alla
restituzione della funzione di pagamento alle Aziende Sanitarie, come previsto dal Programma Operativo 2016-2018.
In seguito alle criticità emerse durante la fase di sperimentazione del nuovo processo di pagamento in merito all’attuazione completa da parte di tutte le Aziende Sanitarie, avviata dal 1 ottobre 2017, è stato modificato e integrato il nuovo processo di pagamento, demandando a
LAZIOcrea la funzione di pagamento centralizzato per conto delle Aziende Sanitarie, in qualità di soggetto delegato esclusivamente al pagamento, senza accollo del debito e pertanto non potrà essere oggetto di procedure esecutive da parte di eventuali creditori del SSR, delle fatture elettroniche gestite sul Sistema Pagamenti.
Il Decreto del Commissionario ad Acta n. U00504 del 5 dicembre 2017 stabilisce:
• di demandare alla Direzione Regionale Salute e Politiche Sociali l’approvazione dello schema di convenzione, da sottoscrivere tra la Regione Lazio, i Direttori
Generali/Commissari Straordinari delle Aziende Sanitarie e LAZIOcrea, per la regolamentazione, dal 1° gennaio 2018, del nuovo processo di pagamento delle diverse categorie di creditori del SSR, così come articolato nell’allegato al presente
provvedimento, che ne forma parte integrante e sostanziale;
• di demandare alle Aziende Sanitarie il compito di implementare i flussi informativi, facendo riferimento alle disposizioni di cui al DCA n. 289/2017, al fine di prendere in carico la funzione dei pagamenti con l’entrata in vigore del SIOPE+ (dal 1° ottobre 2018);
• di demandare a LAZIOcrea anche la funzione di pagamento centralizzato per conto delle Aziende Sanitarie in relazione ai crediti derivanti dall’assistenza farmaceutica convenzionata, quale soggetto delegato esclusivamente al pagamento senza accollo di
debito, sulla base di un analogo processo di pagamento da definire con successiva determinazione dirigenziale;
• di affidare alla Direzione Regionale Salute e Integrazione Socio-Sanitaria e alla Direzione Regionale Programmazione Economica, Bilancio, Demanio e Patrimonio, ognuna per quanto di rispettiva competenza, la supervisione dell’intero processo, al fine di garantire il mantenimento dei tempi e i vantaggi fino ad oggi ottenuti, in termini di ulteriore
riduzione dei tempi di liquidazione e pagamento di cui alle disposizioni vigenti;
• di aggiornare le procedure dei PAC sulla base del processo di pagamento così come articolato nel presente Decreto e nel suo allegato tecnico.
Successivamente, il Decreto del Commissario ad Acta n. U00307 del 29 agosto del 2018 che modifica e integra il precedente Decreto del Commissario ad Acta n. U00504 del 5 dicembre stabilisce:
• di demandare a LAZIOcrea la funzione di ente pagatore, per conto delle Aziende Sanitarie, in qualità di soggetto delegato esclusivamente al pagamento, senza accollo del debito, prevedendo una graduale centralizzazione delle singole voci di pagamento secondo il seguente percorso:
• a partire dal 1° ottobre 2018 LAZIOcrea proseguirà come soggetto delegato al pagamento, senza accollo del debito, limitatamente alla parte di imponibile delle fatture elettroniche gestite attraverso il Sistema Pagamenti e dei debiti di natura non commerciale gestiti attraverso il Sistema DCROnline, estendendo, oltre il 30 settembre 2018, il termine previsto nel Decreto del Commissario ad Acta n. U000504 del 5 dicembre 2017: alla data tale attività è in corso;
• di demandare alle Aziende Sanitarie, nelle more della delega a LAZIOcrea di tutti i restanti pagamenti non gestiti attraverso il Sistema Pagamenti e il Sistema DCROnline, il compito di implementare i flussi informativi necessari al rispetto delle diposizioni previste dalla normativa sul SIOPE+, la cui entrata in vigore per le Aziende Sanitarie è prevista dal 1 ottobre 2018: alla data tale attività è in corso. Dal mese di gennaio 2019 le AASS verranno integrate tramite servizi;
• di rendere obbligatorio l’utilizzo da parte delle Aziende Sanitarie, a partire dal 1° ottobre 2018, dell’interfaccia informatica BRIDGE predisposta da LAZIOcrea in grado di recepire dai sistemi gestionali delle Aziende Sanitarie il mandato OPI firmato digitalmente dalle
Aziende stesse ed inviarlo a Banca d’Italia per effettuare il pagamento del debito di cui al punto che precede nonché di acquisire gli esiti ed il giornale di cassa;
• di prevedere che LAZIOcrea, in considerazione della conferma e dell’ampliamento delle
funzioni attribuite, si doti di una struttura dimensionalmente idonea, con risorse distinte rispetto a quelle assegnate alla Direzione Regionale Salute ed Integrazione Socio- Sanitaria, per assicurare la corretta e tempestiva esecuzione dei pagamenti di cui al presente Decreto. Tale struttura dovrà essere operativa un mese prima dell’ampliamento
delle funzioni delegate a LAZIOcrea relativamente ai controlli previsti dall’Art. 48-bis del
D.P.R n. 602 del 29 settembre 1973 e dal D.M. 24 ottobre 2007;
• di demandare alla Direzione Regionale Salute ed Integrazione Socio-Sanitaria l'approvazione delle adeguate modifiche allo schema di convenzione in base a quanto previsto dal presente Decreto, da sottoscrivere tra la Regione Lazio, i Direttori Generali/Commissari Straordinari delle Aziende Sanitarie e LAZIOcrea, per la regolamentazione, dal 1° ottobre 2018, del processo di pagamento delle diverse categorie di creditori del SSR;
• di demandare alla Direzione Regionale Salute e Integrazione Socio-Sanitaria, la supervisione dell’intero processo, al fine di garantire il mantenimento dei tempi e i
vantaggi fino ad oggi ottenuti, in termini di ulteriore riduzione dei tempi di liquidazione e pagamento di cui alle disposizioni vigenti.
Infine, la Legge di Bilancio 2018 ha stabilito che tutti gli ordini di acquisto della pubblica amministrazione dovranno essere effettuati esclusivamente in formato elettronico e trasmessi per il tramite del Nodo di Smistamento degli Ordini (NSO). Per gli Enti del SSN, l’obbligo decorre
dal 01/02/2020.
Con Decreto del Ministero dell’Economia e delle Finanze del 7 dicembre 2018 (di seguito DM), successivamente modificato e integrato dal DM del 27 dicembre 2019, sono state dettate le
disposizioni in materia di ordinazione elettronica. È stato, di conseguenza, introdotto il sistema per la validazione e la trasmissione dei documenti elettronici attestante l’esecuzione degli acquisti di beni e servizi della PA denominato Nodo Smistamento Ordini (di seguito, NSO) gestito dal Ministero dell’Economia e Finanze.
In tal senso, è stata stabilita l’obbligatorietà dell’emissione e trasmissione dei documenti attestanti l’ordinazione dei beni degli Enti del SSN (anche attraverso l’utilizzo di intermediari)
effettuata esclusivamente in formato elettronico per il tramite del NSO a partire dal 1° febbraio 2020 e dal 1° gennaio 2021 per l’ordinazione dei servizi, così come previsto dal DM del 27 dicembre 2019.
Con il DCA n. U00035 del 14/02/2020, avente ad oggetto le “Attuazioni disposizioni di cui al Decreto del Ministero dell’Economia e delle Finanze del 7 dicembre 2018, così come modificato e integrato dal Decreto del Ministero dell’Economia e delle Finanze del 27 dicembre 2019”, sono state recepite nell’ambito del SSR le disposizioni di cui ai precedenti decreti ministeriali, e sono
state emanate le “Indicazioni Operative Regionali” in riferimento alle modalità di emissione,
trasmissione e gestione degli ordini che gli Enti del SSR del Lazio devono adottare in ottemperanza a quanto dettato dalle Regole tecniche (V. 4.5) pubblicate dal MEF.
Pertanto, gli ordini di acquisto emessi dagli Enti del SSR transitano per il Modulo Ordini Regionale (di seguito, MOR) con la gestione tecnica di LAZIOcrea Spa. Il MOR, in qualità di trasmittente per conto delle Aziende Sanitarie, procede all’invio degli stessi al NSO. Gli ordini
sono poi recapitati ai fornitori dal NSO stesso.
È evidente come il panorama normativo sopra descritto abbia portato ad un modello che vede la Regione Lazio con un ruolo centrale di governance di tutto il ciclo passivo del SSR e che questi cambiamenti abbiamo necessariamente implicato un ripensamento dell’assetto
organizzativo della Regione stessa, di LAZIOcrea che ha assunto un ruolo di supporto non solo
tecnico ma anche organizzativo e delle Aziende Sanitarie.
Infatti, con l’incarico ricevuto con Determinazione 17636 del 27/12/2018 con la quale la Regione Lazio finanzia le attività di mantenimento e evoluzione del Sistema Pagamenti e Fatturazione
Elettronica a la realizzazione del Progetto per le attività di supporto tecnico e consulenza
specialistica per l'evoluzione dell'Ecosistema Pagamenti della Regione Lazio (SANPAE), LAZIOcrea ha proseguito con le sue funzioni di soggetto delegato al pagamento dei crediti dei fornitori del SSR e ha avviato un percorso di evoluzione dei servizi e dei sistemi informatici a supporto del ciclo passivo del SSR costituendo l’attuale Ecosistema Pagamenti. Dalle
rappresentazioni che seguono è possibile individuare il posizionamento iniziale del solo Sistema
Accordo Pagamenti del 2009 e dell’attuale dell’Ecosistema rispetto agli interlocutori nazionali
e locali e che ne determinano la complessità sia in termini di servizi richiesti e offerti sia in termini di sistemi informatici:
Figura 1: Sistema Accordo Pagamenti nel 2009
Figura 2: Ecosistema Pagamenti nel 2020
5.3 Contesto Tecnologico e Applicativo
Dal punto di vista applicativo, attualmente l’Ecosistema Pagamenti è composto dai seguenti sistemi che sono descritti più in dettaglio negli allegati al presente Capitolato:
1. Modulo Ordini Regionale: piattaforma di intermediazione in trasmissione e ricezione degli ordini degli enti del SSR;
2. Cruscotto Ordini Regionale: cruscotto di monitoraggio degli ordini elettronici del SSR;
3. Fatturazione Elettronica Regionale: sistema di smistamento delle fatture elettroniche della Regione Lazio integrato con il Sistema di Bilancio Regionale;
4. Sistema Pagamenti e Fatturazione Elettronica del SSR: sistema di intermediazione della fatturazione elettronica attiva e passiva delle AASS, dei pagamenti dei fornitori del SSR integrato con il SDI e con i Sistemi Gestionali delle Aziende Sanitarie;
5. Modulo Mandati di Pagamento Regionali: banca dati dei mandati di pagamento centralizzati dell SSR (2009-2018)
6. Sistema delle verifiche automatiche dei pagamenti;
7. Piattaforma di Intermediazione Ordinativi di Pagamento Informatici (BRIDGE SIOPE+);
8. Sistema di ticketing OTRS
Dal punto di vista tecnologico, una delle attività strategiche effettuate tra il 2019 e il 2020 è la reingegnerizzazione tecnica e architetturale del Sistema Pagamenti e Fatturazione Elettronica (SIPA) che, per le sue funzioni, è centrale all’interno dell’Ecosistema e che sarà oggetto di
sviluppo, in esecuzione del presente appalto, come dettagliato nel Capitolo 7.
Nel suddetto Capitolo quindi verranno illustrate le attività di sviluppo necessarie per evolvere il SIPA secondo un nuovo modello architetturale e tecnologico con un alto grado di modularità che prevede la separazione delle funzioni “Core Functional Services”, “Enterprise Application
Services” e “Integration Services”. L’attuale architettura “monolitica” DOVRA’ essere evoluta al
fine di supportare la forte domanda di nuove funzionalità provenienti dall’interno del contesto regionale (es. nuovi accordi/contratti, nuove tipologie di fornitori che sottoscrivono la Disciplina
Uniforme, ecc.) e dal contesto esterno (NSO, SDI, SIOPE+, SPID, APP-IO, ecc.). In particolare, saranno indicate le seguenti attività:
• Analisi dei primi interventi tecnologici e funzionali in linea con i principi di modularità del nuovo Ecosistema Pagamenti ed orientati alla transizione verso la nuova soluzione architetturale;
• Modello target dell’architettura funzionale e tecnologica della soluzione;
• Modalità di esecuzione della transizione dal Sistema Pagamenti all’Ecosistema Pagamenti e valutazione dei rischi di progetto;
• Competenze funzionali, tecnologiche, applicative delle figure professionali coinvolte per l’esecuzione del progetto.
Legenda: perimetro territoriale di competenza della normativa |
(N) – Quadro normativo contesto nazionale |
(R) – Quadro normativo contesto regionale |
Regio Decreto n. 2440 del 18 novembre 1923, art. 69, c. 1 e 3, cosi come integrato e modificato dal Codice degli Appalti Decreti Legislativo n. 163 del 12 aprile 2006 e s.m.i.(N)
Il decreto prevede che le cessioni di credito della P.A. debbano essere notificate all’ente e debbano risultare da atto pubblico o da scrittura privata autenticata da un notaio. Inoltre, con l’emanazione del 163/2006 le cessioni di crediti derivanti da contratti di appalto/concessione/concorso di progettazione sono efficaci e opponibili alle stazioni
appaltanti qualora queste non le rifiutino con comunicazione da notificarsi al cedente e al cessionario entro quarantacinque giorni dalla notifica della cessione.
D.L. 35/2013, introdotto dall’articolo 27 del D.L. 66/2014. (N)
Il comma 1 introduce la possibilità, per i fornitori, di immettere sulla piattaforma i dati relativi alle fatture emesse nei confronti delle P.A. a decorrere dal 1° luglio 2014 (fase di invio).
Questa procedura resta valida solo per le fatture cartacee, emesse anteriormente all’entrata in
vigore dell’obbligo di fatturazione elettronica verso la P.A., o per documenti equivalenti che non costituiscono fattura1.
Il comma 2 prevede che le P.A. immettano sulla piattaforma la data ed altre informazioni relative alle fatture pervenute (fase di ricezione), nonché alcuni dati derivanti dalla loro registrazione sui rispettivi sistemi contabili, indicando gli importi liquidati, quelli sospesi e quelli non liquidabili (fase di contabilizzazione).
Il comma 3 prevede che, per le fatture elettroniche, trasmesse mediante il sistema di interscambio (SDI), i dati di ciascuna fattura e le informazioni relative all’invio e alla ricezione siano acquisiti dalla piattaforma automaticamente senza necessità di ulteriori adempimenti
oltre a quelli previsti dal D.M. 55/2013.
Il comma 4 prevede che le P.A., entro il giorno 15 di ciascun mese, comunichino le fatture per le quali sia stato superato il termine di scadenza del pagamento senza che lo stesso sia stato disposto (fase di comunicazione dei debiti scaduti).
Il comma 5 ribadisce l’obbligo, già esistente, di rilevare tempestivamente sul sistema PCC
l’avvenuto pagamento della fattura (fase di pagamento).
Il comma 6 prevede che i tracciati dei dati necessari per alimentare la piattaforma siano conformi a quelli previsti dalle norme sulla fattura elettronica.
Il comma 7 prevede che i dati acquisiti nei modi descritti nei commi precedenti siano completamente utilizzabili sia per rilasciare le certificazioni dei crediti che per produrre report, indicatori, ecc., a beneficio delle P.A., dei fornitori, e di tutti gli altri soggetti coinvolti nel processo, ciascuno per le informazioni di rispettiva pertinenza.
Inoltre, l’articolo 7-bis del D.L. 35/2013, introdotto con il comma 1 dell’articolo 27 del D.L. 66/2014, stabilisce che siano puntualmente rilevate sul sistema PCC le operazioni sottoelencate:
• invio della fattura da parte del creditore;
• ricezione della fattura da parte della pubblica amministrazione (P.A.);
1 Si tratta di documenti di tipo analogico (esempio note di debito emesse da onlus non titolari di partita IVA).
• contabilizzazione della fattura da parte della P.A., con indicazione dell’importo liquidato, sospeso e/o non liquidabile;
• eventuale comunicazione dei debiti scaduti da parte della P.A., entro il giorno 15 del mese successivo alla scadenza;
• eventuale certificazione dei crediti da parte della P.A. su istanza del creditore, ex articolo 9, commi 3-bis e 3-ter, del D.L. 185/2008 e articolo 12, comma 11-quinquies, del D.L. 16/2012;
• eventuale anticipazione e/o cessione dei crediti certificati ad una Banca o ad un intermediario finanziario abilitato;
• eventuale compensazione dei crediti certificati con somme dovute agli agenti della riscossione a seguito di iscrizione a ruolo, ex articolo 28-quater del DPR 602/1973, ovvero con somme dovute in base a istituti definitori della pretesa tributaria o istituti deflativi del contenzioso tributario, ex articolo 28-quinquies del DPR 602/1973;
• pagamento della fattura da parte della P.A.
l processo nelle sue varie fasi richiede diversi adempimenti, sia da parte dei creditori che delle
P.A. debitrici, che consistono nell’immissione sulla piattaforma elettronica di quantità anche rilevanti di informazioni.
DPR n. 602 del 29 settembre 1973, art. 48-bis, come modificato dalla legge di stabilità n. 222 del 29 novembre 2007 e dalla legge di stabilità n. 205 del 27 dicembre 2017 (N)
La normativa ha stabilito che a decorrere dalla data di entrata in vigore di apposito regolamento del MEF, le pubbliche amministrazioni e le società a prevalente partecipazione pubblica, prima di effettuare a qualunque titolo il pagamento di un importo superiore a 10.000 euro (dal 1 marzo 2018 superiore a 5.000 euro – Legge di stabilità 2018), devono verificare, tramite Equitalia SPA
(Oggi Agenzia Entrate Riscossione), se il beneficiario è inadempiente all’obbligo di versamento
derivante dalla notifica di una o più cartelle di pagamento per un ammontare complessivo pari almeno a tale importo, e in caso affermativo non procedono al pagamento.
Decreto Legislativo n. 502 del 30 dicembre 1992 (N)
La normativa stabilisce che a seguito dell’assegnazione del budget, le strutture private accreditate che erogano prestazioni con onere a carico del Servizio Sanitario Nazionale sottoscrivono l’accordo contrattuale previsto all’art. 8 quinquies del D. Lgs. 502/1992 e s.m.i.
Decreto Ministeriale del 24 ottobre 2007 (DURC) (N)
La normativa stabilisce che deve essere effettuato dalle stazioni appaltanti per ciò che concerne gli appalti pubblici di lavori, servizi e forniture (contratti a titolo oneroso stipulati per iscritto tra una stazione appaltante o un ente aggiudicatore, e uno o più operatori economici, avente per oggetto l'esecuzione di lavori, la fornitura di prodotti, la prestazione di servizi) il controllo della
regolarità contributiva di ciascun operatore economico, ovvero qualsivoglia soggetto, persona fisica o persona giuridica, che sia tenuta all’obbligo di iscrizione nei confronti degli enti previdenziali e delle casse edili.
Deliberazione della Giunta Regionale 689/2008 (R)
La Regione Lazio ha approvato la sottoscrizione di specifici accordi con i soggetti che intrattengono rapporti con il SSR al fine di gestire, secondo procedure uniformi, i crediti commerciali oggetto di fatturazione a decorrere dal 01 gennaio 2009. Tali accordi potranno essere applicati alla totalità dei crediti relativi a fatture emesse a partire dal giorno di sottoscrizione dell'accordo stesso derivanti da rapporti di fornitura già in corso o da nuovi rapporti di fornitura che saranno stipulati tra fornitori e XX.XX..
Deliberazione della Giunta Regionale 813/2008 (R)
La delibera integra la D.G.R. n. 689 del 26 settembre 2008, estendendo le modalità di fatturazione, liquidazione e pagamento, definite in tale delibera, alle Case di cura provvisoriamente accreditate nelle varie tipologie di prestazioni erogate comprese le case di cura ex pio istituto.
Deliberazione della Giunta Regionale 58/2010 (R)
La delibera prevede l’integrazione della D.G.R. n. 813 del 7 novembre 2008, estendendo le
modalità di fatturazione, liquidazione e pagamento, definite in tale delibera, alle strutture erogatrici di prestazioni ex art. 26 per fatture emesse a partire dal 1 gennaio 2010 relative a prestazioni di competenza 2010.
Legge n. 136 del 13 agosto 2010 (N)
La normativa prevede un “Piano straordinario contro le mafie, nonché delega al Governo in materia di normativa antimafia”. In particolare, prevede specifiche disposizioni in tema di
tracciabilità dei flussi finanziari per contrastare la criminalità organizzata e le infiltrazioni nelle commesse pubbliche.
Deliberazione della Giunta Regionale 358/2011 (R)
La delibera definisce le modalità di fatturazione, liquidazione e pagamento alle strutture private accreditate che erogano prestazioni di specialistica ambulatoriale, dialisi e risonanza magnetica. Decreto del Ministero dell’Economia e delle Finanze del 23 maggio 2012 (N)
La normativa prevede l’istituzione della Piattaforma di Certificazione dei Crediti Commerciali (PCC) che a partire dal 1° luglio 2014 il sistema ha assunto, quindi, la funzione di piattaforma per il monitoraggio dei debiti commerciali della PA e dei relativi tempi di pagamento.
Decreto Legislativo n. 192 del 9 novembre 2012 (N)
Con tale decreto vengono introdotte “Modifiche al decreto legislativo 9 ottobre 2002, n. 231, per l'integrale recepimento della direttiva 2011/7/UE relativa alla lotta contro i ritardi di pagamento nelle transazioni commerciali”.
Decreto del Commissionario ad Acta n. U00351 del 27 novembre 2012 (R)
Il decreto definisce la continuità all’Accordo Pagamenti anche per l’anno 2013, al fine di garantire
regolarità, puntualità, trasparenza ed omogeneità di trattamento delle varie categorie di soggetti che intrattengono rapporti con il Sistema Sanitario Regionale.
Decreto Legislativo n. 33 del 14 marzo 2013 (N)
Tale decreto definisce l’indicatore dei tempi di pagamento: tra gli strumenti introdotti per monitorare i tempi di pagamento da parte delle PA al fine di scongiurare la procedura di infrazione definita dall’Unione Europea sopra indicata il legislatore con il D.Lgs. n. 33/2013,
all’art. 33, ha introdotto l’obbligo per le amministrazioni di pubblicare, con cadenza annuale, un
indicatore dei propri tempi medi di pagamento relativi agli acquisti di beni, servizi e forniture, denominato “Indicatore di tempestività dei pagamenti”.
Decreto del Commissionario ad Acta n. U00501 del 23 dicembre 2013 (R)
Il decreto definisce la continuità all’Accordo Pagamenti anche per l’anno 2014/2015, al fine di
garantire regolarità, puntualità, trasparenza ed omogeneità di trattamento delle varie categorie di soggetti che intrattengono rapporti con il Sistema Sanitario Regionale.
Decreto Legislativo n. 66 del 24 aprile 2014 (N)
Tale decreto ha regolamentato l’iter di avvio dell’obbligo di fatturazione elettronica per tutte le imprese e i professionisti nei confronti della Pubblica Amministrazione, a partire dal 31 marzo
2015, attraverso il SDI gestito da SOGEI.
Decreto del Commissionario ad Acta n. U00130 del 31 Marzo 2015 (R)
Il decreto definisce l’adeguamento dell'Accordo Pagamenti tra gli Enti del Sistema Sanitario Regionale e le varie categorie di soggetti che intrattengono rapporti con il Sistema Sanitario Regionale alla normativa vigente.
Decreto Ministeriale n. 55 del 3 aprile 2015 (N)
Con tale decreto sono state individuate le regole tecniche e le linee guida per la gestione dei processi di fatturazione elettronica verso la Pubblica Amministrazione, introducendo una serie di disposizioni in materia di emissione, trasmissione e ricevimento della fattura elettronica,
attraverso il Sistema di interscambio. Le disposizioni del suddetto decreto si applicano nei riguardi delle Amministrazioni dello Stato e degli Enti pubblici nazionali, a partire dal 6 giugno 2014.
Decreto del Commissionario ad Acta n. U00308 del 3 luglio 2015 (R)
Il decreto introduce la Disciplina Uniforme delle modalità di fatturazione e di pagamento. Decreto del Commissionario ad Acta n. U00523 del 5 novembre 2015 (R)
Il decreto stabilisce la proroga e il rinnovo dell'Accordo Pagamenti fino al 31/12/2017. Legge n. 232 dell’11 dicembre 2016, art.1, comma 533 (N)
Al fine di favorire il monitoraggio del ciclo completo delle entrate e delle spese, le
amministrazioni pubbliche ordinano gli incassi e i pagamenti al proprio tesoriere o cassiere esclusivamente attraverso ordinativi informatici emessi secondo lo standard Ordinativo Informatico emanato dall'Agenzia per l'Italia digitale (AGID), per il tramite dell'infrastruttura della banca dati SIOPE gestita dalla Banca d'Italia nell'ambito del servizio di tesoreria statale.
Decreto del Commissionario ad Acta n. U00289 del 7 luglio 2017 (R)
Tale decreto definisce un nuovo processo di pagamento di tutte le fatture elettroniche gestite sul SIPA, necessario alla restituzione della funzione di pagamento alle XX.XX., a partire dal 1 gennaio 2018.
Decreto del Commissionario ad Acta n. U00504 del 5 dicembre 2017 (R)
Tale decreto modifica e integra il XXX x.X00000, delegando a LAZIOcrea la funzione di pagamento centralizzato per conto delle XX.XX. in relazione ai crediti derivanti dall’assistenza farmaceutica convenzionata (DCR online). Attribuisce inoltre alla Direzione Regionale Salute e
Politiche Sociali e alla Direzione Regionale Programmazione Economica, Bilancio, Demanio e Patrimonio, ognuna per quanto di rispettiva competenza, la supervisione dell’intero processo.
Decreto del Commissionario ad Acta n. U00307 del 29 agosto del 2018 (R)
Tale decreto modifica e integra il DCA n.U002504 rendendo obbligatorio l’utilizzo da parte delle XX.XX., a partire dal 1° ottobre 2018, dell’interfaccia informatica c.d. Bridge/SIOPE+ predisposta da LAZIOcrea e demanda alle XX.XX., per tutti i restanti pagamenti non gestiti
attraverso il SIPA e il Sistema DCROnline, il compito di implementare i flussi informativi necessari al rispetto delle diposizioni previste dalla normativa sul SIOPE+.
Legge di Bilancio 2018 – Legge n. 205 del 27 dicembre 2017(N)
Tale normativa stabilisce che gli ordini di acquisto della pubblica amministrazione dovranno essere effettuati esclusivamente in formato elettronico e trasmessi per il tramite del Nodo di
Smistamento degli Ordini (NSO). Per gli enti del SSN è previsto che il sistema entri in esercizio nel 2018, l’uso sarà successivamente esteso ad altri settori della pubblica amministrazione.
Decreto Legislativo n. 101 del 10 agosto 2018 (N)
Il presente decreto stabilisce le disposizioni per l'adeguamento della normativa nazionale alle disposizioni del regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio, del 27 aprile 2016, relativo alla protezione delle persone fisiche con riguardo al trattamento dei dati personali, nonché alla libera circolazione di tali dati e che abroga la direttiva 95/46/CE (regolamento generale sulla protezione dei dati - GDPR).
Decreto del Commissionario ad Acta n. U00247 del 2 Luglio 2019 (R)
Il decreto riguarda l’approvazione delle modifiche alla Disciplina uniforme delle modalità di fatturazione e di pagamento dei crediti vantati nei confronti delle Aziende Sanitarie Locali, Aziende Ospedaliere, Aziende Ospedaliere Universitarie, IRCCS Pubblici, dell’Azienda ARES 118 e della Fondazione Policlinico Tor Vergata - ex DCA n. U00032 del 30 gennaio 2017.
Decreto del Commissario ad Acta n. 81/2020 e recepito con DGR n. 406/2020
Piano di riorganizzazione, riqualificazione e sviluppo del Servizio Sanitario Regionale 2019- 2021”;
Decreto del Commissario ad Acta n. U00035 del 14/02/2020
Attuazione disposizioni di cui al Decreto del Ministero dell'Economia e delle Finanze del 7 dicembre 2018 così come modificato e integrato dal Decreto del Ministero dell'Economia e delle Finanze del 27 dicembre 2019 – Nodo di Smistamento degli Ordini (NSO);
Delibera di Giunta Regionale n. 799 del 10/11/2020
Attuazione della nuova procedura di pagamento per le diverse categorie di creditori delle Aziende del SSR secondo le modalità previste dal DCA n. U000307/2018.
I soggetti che hanno maggiore interesse e che sono coinvolti nei processi del ciclo passivo supportati dell’Ecosistema Pagamenti sono principalmente i seguenti:
• LAZIOcrea: è una Società totalmente partecipata dalla Regione Lazio, ente strumentale della stessa e operante secondo le modalità dell’In-House providing, che ad oggi gestisce l’ ESIPA, a cui è stata estesa, oltre il 30 settembre 2018, la funzione di
pagamento centralizzato, in nome e per conto delle AASS, delle fatture immesse sul SIPA da parte delle diverse categorie di creditori, in qualità di soggetto delegato
esclusivamente al pagamento senza accollo del debito (il patrimonio di LAZIOcrea rimane distinto, autonomo e separato sia da quello delle ASL sia da quello della Regione e, pertanto, non potrà essere oggetto di procedure esecutive da parte di eventuali creditori del SSR);
• Aziende Sanitarie: sono gli unici soggetti giuridici titolari del debito nei confronti dei creditori del SSR; le AASS hanno la competenza esclusiva nell’attestare che il credito derivante da fatture emesse nei loro confronti sia certo, liquido ed esigibile, in quanto
sono gli unici soggetti giuridici che possono verificare e accertare la correttezza formale e sostanziale delle fatture risultante:
▪ dalla conformità delle prestazioni sanitarie erogate al titolo di autorizzazione e accreditamento, nel rispetto della normativa vigente;
▪ dal rispetto dei livelli di assorbimento dei budget assegnati alle strutture private accreditate;
▪ dalla coerenza tra i beni, i servizi e le prestazioni ricevute e fatturate rispetto a quelle richieste e ordinate.
Le AASS accertano, altresì, la regolarità amministrativo-contabile delle fatture stesse in base alla normativa vigente. Pertanto, in quanto enti dotati di propria autonomia giuridica, patrimoniale e amministrativa, sono gli unici soggetti legittimati passivamente in sede di eventuali giudizi promossi dai creditori del SSR;
• Regione Lazio - Direzione Regionale Salute e Integrazione Socio-Sanitaria, Area Risorse Economico-Finanziarie: monitora e fornisce supporto tecnico alle AASS, effettuando le verifiche di carattere formale, per conto delle stesse AASS, necessarie a garantire un corretto e omogeneo pagamento, attraverso l'utilizzo delle funzionalità e dei dati disponibili sul SIPA, unicamente allo scopo di continuare a garantire una gestione efficiente, razionale e uniforme del processo in termini di rispetto dei tempi, delle
modalità e dei costi di gestione. Effettua la predisposizione dei mandati di pagamento per l’invio delle rimesse a LAZIOcrea, senza assumere alcun impegno, né diretto né
indiretto o a titolo di garanzia, sull’esistenza, liquidazione e pagamento dei crediti delle
AASS;
• Regione Lazio – Direzione Regionale Programmazione Economica, Bilancio, Demanio e Patrimonio: garantisce il tempestivo trasferimento delle risorse a LAZIOcrea, quale ente
strumentale delegato esclusivamente al pagamento, in base alle richieste ricevute dall’Area Risorse Economico-Finanziarie;
• Creditori del SSR: i soggetti che forniscono beni o prestano servizi a favore delle AASS ovvero i soggetti giuridici assoggettati all’obbligo di autorizzazione per l’esercizio di
attività sanitaria nonché all’obbligo di accreditamento per l’erogazione di prestazioni
sanitarie a favore di terzi beneficiari in nome e per conto e con onere a carico del Servizio Sanitario Regionale (SSR);
• Altri interlocutori: Banca d’Italia, Banca Tesoriera, Ragioneria Generale delle Stato, AGID.
Dal punto di vista organizzativo, la struttura preposta al processo di pagamenti che DOVRA’ essere garantita dall’Appaltatore è di seguito rappresentata:
Figura 3: Struttura di supporto ai pagamenti
Di seguito, è illustrato l’attuale processo di pagamento: per ogni tranche mensile di pagamento a favore delle diverse tipologie di Fornitore, il ciclo totale può essere rappresentato nelle figure
seguenti che descrivono tempi, ruoli e azioni.
Figura 4: Processo pagamenti a dicembre 2020
Figura 5: Esempio Cronoprogramma processo pagamenti Fornitori Beni e Servizi a dicembre 2020
La definizione dei rapporti tra gli Enti del SSR, l’Ente Pagatore senza accollo del debito e Regione Lazio è sancita nella DGR 799 del 10/11/2020 attraverso la sottoscrizione di una
apposita Convenzione, intesa a realizzare la piena cooperazione tra le Parti in materia di gestione dei pagamenti del SSR, ed è finalizzata a garantire che i servizi pubblici sanitari resi dalle Parti medesime, siano prestati nell’ottica di conseguire gli obiettivi comuni, in funzione dei
canoni di uniformità e tempestività nell’adempimento delle obbligazioni pecunarie facenti capo all S.S.R.
5.7 Sistemi applicativi coinvolti
Si riporta di seguito una descrizione dei principali sistemi coinvolti nell’Ecosistema Pagamenti del SSR:
• SIPA - SIPA: sistema informatico integrato con il Sistema d’Interscambio (SDI) e con i sistemi contabili aziendali, che gestisce le modalità e i dati di fatturazione e pagamento dei creditori
del SSR del Lazio. Tale Sistema è finalizzato al monitoraggio e alla dematerializzazione del ciclo passivo delle XX.XX., dalla fase di sottoscrizione degli accordi/contratti di budget (per le Strutture Private Accreditate) o di trasmissione dell'ordine elettronico (per i Fornitori di beni e servizi) fino alla fase di chiusura contabile dei crediti. Il Sistema, gestito da LAZIOcrea, mette a disposizione di tutti gli attori interessati (XX.XX., Strutture Private Accreditate, Fornitori, Cessionari, Regione Lazio) le funzionalità e i dati di propria competenza per la gestione e il monitoraggio di tale processo. Dal sistema SIPA dovranno essere adeguati i servizi per inviare Fatture ed Esiti firmati in conservazione (Service Esterno);
• SDI - SDI: nodo principale del processo di fatturazione elettronica verso la Pubblica Amministrazione, creato da SOGEI per conto dell’Agenzia delle Entrate, per connettere i fornitori delle Pubbliche Amministrazioni con i propri clienti. Tale sistema informatico,
gestito dall'Agenzia delle Entrate, è in grado di:
▪ ricevere le fatture sotto forma di file con le caratteristiche della FatturaPA;
▪ effettuare controlli sui file ricevuti;
▪ inoltrare le fatture alle Amministrazioni destinatarie;
• Sistemi Gestionali Contabili delle XX.XX. del Lazio: software utilizzati dalle XX.XX. per l’automatizzazione dei processi di gestione contabile;
• Bridge: interfaccia informatica predisposta da LAZIOcrea Spa in grado di svolgere due funzioni:
▪ recepire dai sistemi gestionali delle XX.XX. il mandato OPI (ordinativi e reversali) firmati digitalmente e inviarlo al SIOPE+; ricevere dal SIOPE+ gli esiti e i giornali di cassa e renderli disponili alle AASS;
▪ acquisire gli OPI dal SIPA e dal sistema DCRonLine, consentirne la firma massiva, e inviarli al SIOPE+; ricevere da questi gli esiti e i giornali di cassa;
▪ inviare gli OPI, esiti e giornali di cassa firmati in conservazione (Service esterno).
• SIOPE+: nuova infrastruttura sviluppata dalla Banca d'Italia per conto della Ragioneria Generale dello Stato (RGS) che intermedia il colloquio tra Pubbliche Amministrazioni e banche tesoriere con l'obiettivo di migliorare la qualità dei dati per il monitoraggio della spesa pubblica e per rilevare i tempi di pagamento delle Pubbliche Amministrazioni nei confronti delle imprese fornitrici. La completa dematerializzazione dei flussi informativi scambiati tra Amministrazioni e tesorieri e la standardizzazione del protocollo e delle modalità di colloquio contribuiscono a innalzare il livello di informatizzazione dei singoli enti e ad accrescere l'efficienza del sistema dei pagamenti pubblici. Le Amministrazioni Pubbliche sono tenute a ordinare incassi e pagamenti al proprio tesoriere o cassiere utilizzando esclusivamente ordinativi informatici emessi secondo lo standard definito dall'Agenzia per l'Italia Digitale (AgID) e trasmessi attraverso l'infrastruttura SIOPE+;
• PCC: La piattaforma dei crediti commerciali – PCC della Ragioneria Generale dello Stato
rappresenta il sistema per il monitoraggio dei debiti commerciali della PA. Tale piattaforma nasce nel 2012 come strumento attraverso il quale le imprese, previa istanza presentata ai rispettivi enti pubblici debitori, possono ottenere la certificazione dei crediti commerciali vantati2. A partire dal 1° luglio 2014, il sistema ha assunto la funzione di piattaforma per il
monitoraggio dei debiti commerciali della PA. Le P.A. hanno l’obbligo di tracciare sulla
piattaforma le operazioni di contabilizzazione3 e pagamento4 e di comunicarne l’eventuale scadenza5. Il caricamento delle informazioni sul sistema, tanto per i creditori quanto per le
P.A., può avvenire nelle seguenti modalità:
▪ immissione manuale dei dati via web: questa modalità è idonea solo se si ha necessità di
o comunicare quantità limitate di informazioni;
▪ caricamento massivo dei dati tramite invio di file precompilati: questa modalità, che consente di comunicare grandi quantità di informazioni, richiede comunque un’attività manuale per predisporre e caricare i file;
▪ trasmissione telematica di flussi di dati: questa modalità permette di comunicare grandi quantità di informazioni senza necessità di particolari interventi manuali, tuttavia
2 D.L. 35/2013, art.7, c.1.
3 D.L. 35/2013, art. 7-bis, c. 2.
4 D.L. 35/2013, art. 7-bis, c. 5.
5 D.L. 35/2013, art. 7-bis, c. 4.
richiede che il soggetto (creditore o P.A.) che intende avvalersene disponga di sistemi informatici in grado di connettersi alle interfacce rese disponibili dal sistema PCC;
▪ servizi web: questa modalità di trasmissione consente la piena integrazione tra il sistema
di contabilità della P.A. e il sistema PCC, tuttavia richiede che la P.A. che intende avvalersene disponga di adeguati sistemi informatici.
• Sistemi Informativo Sanitario (QUASIO, QUASIAS, RAD-R, FILE F, SIES, SIAT, etc.): flusso di informazioni riferite all’attività sanitaria erogata dalle strutture pubbliche/private utilizzato
dagli Enti del SSR per il monitoraggio dell'attività svolta, il finanziamento delle strutture erogatrici, la programmazione sanitaria e la creazione automatica, relativamente al QUASIAS, delle fatture sul SIPA;
• Digital Signature Services (DSS): applicazione per la verifica di firme digitali apposte sui file digitali caricati sul SIPA;
• ARUBA PEC: servizio di Posta Elettronica Certificata utilizzato per l’invio delle PEC dal SIPA agli attori coinvolti nei processi afferenti al ciclo passivo gestiti sul SIPA stesso; Tecnologia
Job;
• NSO (NSO): infrastruttura sviluppata da SOGEI per conto della Ragioneria Generale dello Stato per la gestione di tutti gli ordini di acquisto della pubblica amministrazione, ivi compresi quelli emessi dagli Enti del SSN; gli ordini dovranno essere effettuati esclusivamente in formato elettronico e trasmessi per il tramite del NSO;
• MOR, MOR Report: piattaforma di intermediazione tecnica in trasmissione e ricezione degli ordini elettronici e relativo cruscotto di monitoraggio integrato con i gestionali delle Aziende Sanitarie e NSO;
• Sistema delle Verifiche dei Pagamenti: sistema realizzato in architettura a microservizi, permette di effettuare le verifiche contabili e riconciliazioni tra le fatture pervenute e le rate di pagamento emesse. E’ integrato con il SIPA funzionale alle verifiche automatiche dei pagamenti:
• Sistema dei Mandati Regionali: Sistema che permette di effettuare le verifiche contabili dei mandati di pagamento effettuati dalla Regione Lazio tra il 2009 e il 2018
6 DESCRIZIONE DEI SERVIZI OGGETTO DELL’APPALTO
Come precedentemente detto, la Regione Lazio ha un ruolo centrale di governance di tutto il ciclo passivo del SSR e LAZIOcrea S.p.A. ha assunto un ruolo di supporto non solo tecnico ma anche organizzativo nella gestione dei processi del ciclo passivo sanitario e nella progettazione, gestione e manutenzione dei sistemi informatici a supporto.
LAZIOcrea S.p.A., quindi, prosegue con le sue funzioni di soggetto delegato al pagamento dei crediti dei fornitori del SSR e con il percorso di evoluzione dei servizi e dei sistemi informatici che costituiscono l’Ecosistema Pagamenti.
Tutte le azioni effettuate da LAZIOcrea S.p.A. sono orientate al perseguimento di obiettivi di efficacia nell’erogare i servizi nell’ambito delle funzioni affidate e efficienza rispettando i tempi di pagamento e ottimizzando le risorse a diposizione attraverso la realizzazione di nuovi
strumenti tecnologici e realizzazione di automazioni a supporto dei processi di pagamento.
In questo capitolo quindi saranno descritti i servizi complessivi oggetto del presente appalto per il proseguimento di tutte le attività di supporto organizzativo e operativo, di sviluppo software e di gestione e manutenzione dei sistemi informatici che costituiscono l’Ecosistema
Pagamenti.
6.1 Servizi di supporto organizzativo
Tra i servizi di supporto organizzativo rientrano tutte le attività di consulenza specialistica a supporto della Direzione Regionale Salute e Integrazione Socio Sanitaria, consulenza per la revisione dei processi e process mining relativi al ciclo dei pagamenti, governance complessiva di progetto.
6.1.1 ID SOC - Consulenza specialistica in continuità
In continuità con le attività attuali:
• Supporto alle attività per la gestione dei rapporti economico-giuridici con il privato accreditato (incluse le reti di Aggregazione dei Laboratori Analisi), quali l'attuazione di nuovi modelli organizzativi, la definizione delle tariffe e gli impatti sul Sistema Sanitario Regionale, la compartecipazione alla spesa, la definizione del livello massimo di finanziamento, la definizione del format contrattuale, la sottoscrizione digitale su SIPA dei contratti di budget, la remunerazione delle prestazioni tenuto conto degli abbattimenti tariffari e controlli esterni analitici, la definizione di un layout fattura, il monitoraggio e la gestione del contenzioso in merito alle tematiche sopra descritte;
• Supporto specialistico per le analisi e gli approfondimenti sulle posizioni debitorie pregresse, elaborazione e monitoraggio dello stock del debito;
• Gestione processi afferenti al ciclo passivo e attivo delle Aziende Sanitarie e dei fornitori del SSR gestiti attraverso l’ESIPA: adeguamento normative, definizioni di nuove specifiche tecniche per tutti i processi relativi a Ordini e DDT elettronici, Fatturazione
Elettronica, Liquidazione e Pagamenti;
• Supporto nella predisposizione della documentazione e degli schemi economico/finanziari per l’assolvimento degli adempimenti e dei debiti informativi previsti dalla normativa in vigore nei confronti degli Enti/Istituzioni esterne (Corte dei conti, Ministero della Salute, Ministero dell’Economia e delle Finanze, Comunità Europea, etc), tra le quali rendicontazioni delle spese legate a specifici progetti finanziati o anche
relazioni per riscontrare quesiti/richieste di chiarimenti;
• Supporto nel monitoraggio del costo del personale del SSR in correlazione al piano dei fabbisogni del personale delle Aziende ed Enti del SSR e agli obiettivi di spesa disposti dal bilancio preventivo economico annuale (BEP), definizione delle indicazioni operative nei confronti delle Aziende ed Enti del SSR per il rispetto delle linee di indirizzo nazionali e dell’equilibrio economico e finanziario del SSR;
• Supporto specialistico nell’elaborazione e adeguamento della Disciplina Uniforme sulle modalità di fatturazione e pagamento;
• Supporto nella ricognizione delle configurazioni (PL e Discipline) delle Case di Cura Private autorizzate che erogano prestazioni di assistenza ospedaliera per acuti;
• Supporto nella ricognizione delle configurazioni delle strutture private accreditate che erogano prestazioni di assistenza territoriale (inclusa assistenza specialistica);
• Supporto per la definizione di regole e sistemi innovativi di remunerazione delle attività non tariffabili, che tengano conto dell'intero percorso di cura, sia sotto il profilo della qualità delle prestazioni erogate che della copertura dei costi; nonché supporto per l’individuazione di nuovi modelli di finanziamento delle funzioni assistenziali che
garantiscano un'equa e appropriata distribuzione delle risorse al fine di valorizzare
l'offerta sanitaria sul territorio regionale;
• Supporto specialistico per la raccolta e definizione dei business requirement e dei requisiti per le evoluzioni software dell’ESIPA e attività di test e verifica funzionali;
• Supporto alle attività di governance e coordinamento regionale delle Aziende Sanitarie in riferimento ai modelli e alle modalità di attuazione e di integrazione dei sistemi gestionali aziendali con i sistemi centrali regionali;
• Supporto per la definizione di nuove modalità di gestione del budget e della remunerazione delle Case di Cura Provate Accreditate sui sistemi QUASIO e SIAS XL.
Il servizio sopra descritto prevede una rendicontazione a misura per un totale di 6.322 giornate uomo sulla base dei PAI. Si riporta di seguito la composizione del team di lavoro richiesto per la realizzazione delle attività per il Servizio in oggetto, indicando nel caso di rendicontazione a misura il totale delle Giornate uomo richieste.
Si precisa che tutte le attività dovranno essere preventivamente concordate con la Direzione Regionale Salute e Integrazione Socio Sanitaria e la rendicontazione di attività, effort e risorse impiegate dovrà essere formalmente approvata dalla Direzione stessa. La Società Appaltante approverà la fatturazione delle attività svolte solo dopo il riconoscimento da parte della Direzione Regionale così come specificato nel Paragrafo .8.16.1.
Servizio | Figure professionali del team | Giornate uomo a misura |
ID SOC – Consulenza specialistica in continuità | Senior Advisor | 660 |
Consulente Esperto di Organizzazione e Processi | 5662 | |
Tot. GIORNI PERSONA | 6322 |
In questo ambito rientra il supporto specialistico per il coordinamento e la governance regionale dei processi organizzativi e dei nuovi impatti tecnologici derivanti da eventuali aggiornamenti del processo di gestione degli ordini elettronici e dall’avvio dei nuovi processi di trasmissione
dei documenti di trasporto elettronici.
Il servizio prevede inoltre la consulenza specialistica sugli impatti tecnologici dei sistemi informatici a supporto del ciclo passivo in seguito a nuove normative e consulenza specialistica a supporto di altre Aree/Direzioni Regionali che hanno interesse nei dati gestiti dall’Ecosistema
Pagamenti e/o che sono supportate da sistemi informatici da integrare con i sistemi
dell’Ecosistema.
Considerando infatti che i sistemi informatici dell’ESIPA supportano il ciclo passivo sanitario e gestiscono in maniera integrata i dati e le informazioni utili per la governance della spesa
sanitaria è possibile ad esempio rispondere a specifiche esigenze della Centrale Acquisti Regionale fornendo consulenza e dati utili per la programmazione degli acquisti.
Rientrano inoltre le attività di Demand Management per il recepimento delle esigenze espresse dalla Regione Lazio e la loro declinazione in requisiti evolutivi a livello funzionale/tecnologico/architetturale e supporto al collaudo della soluzione;
Il servizio sopra descritto prevede una rendicontazione a misura per un totale di 2.065 Giornate uomo sulla base dei PAI. Si riporta di seguito la composizione del team di lavoro richiesto per la realizzazione delle attività per il Servizio in oggetto, indicando nel caso di rendicontazione a misura il totale delle Giornate uomo richieste.
Servizio | Figure professionali del team | Giornate uomo a misura |
ID SOE - Consulenza specialistica per le evoluzioni dei sistemi e il supporto ad altre Direzioni | Consulente Esperto di Organizzazione e Processi | 1.375 |
Demand Manager | 690 | |
Tot. GIORNI PERSONA | 2.065 |
6.1.3 ID SOP - Supporto alla revisione dei processi e Process Mining
Considerando la continua evoluzione di carattere normativo e tecnologico l’Appaltatore DOVRA’ supportare la revisione dei processi dell’ESIPA in ottica nativa digitale (processi dematerializzati, misurabili, distribuiti ed integrati tra i sistemi software) con l’obiettivo di adottare nuovi modelli organizzativi e nuove procedure a supporto del ciclo dei pagamenti.
In questo ambito di servizio rientra, inoltre, l’applicazione di tecniche di Process Mining per l’analisi dei processi di business basati sui log degli eventi. Sfruttando gli algoritmi di data mining ai log, si estrae la conoscenza necessaria per individuare informazioni e modelli afferenti al
sistema informativo. Scopo del process mining è migliorare il sistema informativo stesso per modellare i processi o sviluppare ulteriori operazioni per innovarli perseguendo i seguento pbiettivi:
▪ L’incremento delle performance di processo attraverso il monitoraggio dei relativi KPI, l’individuazione di eventuali elementi di inefficienza (colli di bottiglia) e di possibili soluzioni di miglioramento;
▪ Il mantenimento di elevati livelli di aderenza fra processi di business e applicazioni a supporto;
▪ Il mantenimento della compliance dei processi rispetto a best practice e/o regolamenti interni.
Il servizio sopra descritto prevede una rendicontazione a misura per un totale di 460 Giornate uomo sulla base dei PAI. Si riporta di seguito la composizione del team di lavoro richiesto per
la realizzazione delle attività per il Servizio in oggetto, indicando nel caso di rendicontazione a misura il totale delle Giornate uomo richieste.
Servizio | Figure professionali del team | Giornate uomo a misura |
ID SOP – Supporto alla revisione dei processi e Process Mining | Consulente Esperto di Organizzazione e Processi | 230 |
Analista di organizzazione e processi | 230 | |
Tot. GIORNI PERSONA | 460 |
6.1.4 ID SOG - Governance di progetto e PMO
In questo ambito rientrano le seguenti attività che l’Appaltatore DOVRA’ garantire:
• Supporto al Program & Project Management:
• Governo del programma complessivo di progetto e monitoraggio degli interventi evolutivi nel triennio;
• Monitoraggio di livelli di servizio delle attività di sviluppo e di gestione applicativa;
• Quality Assurance del programma;
• Attività di supporto Direzionale LAZIOcrea.
Il servizio sopra descritto prevede una rendicontazione a misura per un totale di 690 Giornate uomo sulla base dei PAI. Si riporta di seguito la composizione del team di lavoro richiesto per la realizzazione delle attività per il Servizio in oggetto, indicando nel caso di rendicontazione a misura il totale delle Giornate uomo richieste.
Servizio | Figure professionali del team | Giornate uomo a misura |
ID SOG - Governance di progetto e PMO | Responsabile di progetto applicativo | 690 |
Tot. GIORNI PERSONA | 690 |
6.2 Servizi di supporto operativo
Nell’ambito dei servizi di supporto operativo l’Appaltatore DOVRA’ garantire tutte le attività
necessarie a supportare le funzioni di LAZIOcrea in qualità di soggetto delegato al pagamento dei crediti dei fornitori del SSR, servizi di change management, servizi di assistenza e backend
6.2.1 ID SCM - Change Management
In questo ambito rientrano tutte le attività di affiancamento utente, formazione e comunicazione destinate a tutti gli interlocutori dell’Ecosistema: LAZIOcrea, Regione Lazio, Aziende Sanitarie, Fornitori del SSR.
Il servizio sopra descritto prevede una rendicontazione a misura per un totale di 200 Giornate uomo sulla base dei PAI. Si riporta di seguito la composizione del team di lavoro richiesto per la realizzazione delle attività per il Servizio in oggetto, indicando nel caso di rendicontazione a misura il totale delle Giornate uomo richieste.
Servizio | Figure professionali del team | Giornate uomo a misura |
ID SCM - Change Management | Analista di organizzazione e processi | 200 |
Tot. GIORNI PERSONA | 200 |
6.2.2 ID SAB – Servizi di assistenza e backend
L’Appaltatore DOVRA’ svolgere tutte le attività di assistenza (frontend) verso gli utenti e i beneficiari dei servizi e dei sistemi informatici dell’Ecosistema Pagamenti, il supporto nell’ambito
della gestione dei rapporti e delle comunicazioni da/verso le Aziende Sanitarie e i fornitori del SSR e tutti i servizi di backend funzionali all’erogazione delle attività di frontend.
A titolo esemplificativo ma non esaustivo:
• Supporto agli utenti delle Aziende Sanitarie nell’ambito di tutti i servizi e processi del ciclo passivo e attivo supportati dai sistemi informatici dell’Ecosistema Pagamenti. A titolo esemplificativo e non esaustivo:
⮚ Gestione Contratti e Accordi;
⮚ Ordini;
⮚ Documenti di Trasporto e Carichi di Magazzino;
⮚ Fatturazione Attiva e Passiva delle Aziende Sanitarie;
⮚ Fatturazione attiva dei fornitori del SSR;
⮚ Fatturazione attiva e passiva della Regione Lazio e degli Enti Intermediati per la fatturazione elettronica;
⮚ Liquidazione e Pagamento dei crediti dei fornitori del SSR;
• Supporto dedicato ai Fornitori delle Aziende Sanitarie attinente le seguenti macro- tematiche:
⮚ Supporto dedicato ai fornitori del SSR, sottoscrittori della Disciplina Uniforme/Contratti di Budget per richiesta informazioni, supporto sulle funzionalità dei sistemi informatici dell’Ecosistema
⮚ Richiesta di informazioni e/o criticità riscontrate in fase di registrazione sul Sistema Pagamenti del SSR;
⮚ Richiesta di informazioni e/o criticità riscontrate in fase di gestione dell’utenza creata sul Sistema Pagamenti del SSR (esempio: riattivazione utenza e reset credenziali di login);
⮚ Richiesta di informazioni e/o criticità riscontrate da parte dei Fornitori di beni e servizi in fase di aggiornamento dell’anagrafica censita sul Sistema Pagamenti del SSR;
⮚ Richiesta di informazioni e/o criticità riscontrate in fase di validazione o cambio delle coordinate bancarie da dichiarare sul Sistema Pagamenti del SSR;
⮚ Richiesta di informazioni e/o criticità riscontrate in fase di censimento dei negozi giuridici stipulati con le Aziende Sanitarie in cui risulta integrata la Disciplina Uniforme (DCA U00308/2015 e s.m.i.);
⮚ Richiesta di informazioni e/o criticità riscontrate in fase di registrazione della cessione del credito tramite il Sistema Pagamenti;
⮚ Richiesta di informazioni utili in tema di effettuazione dei pagamenti delle fatture passive emesse verso le Aziende Sanitarie (Es: data valuta, report in pagamento, report pagato);
⮚ Richiesta di informazioni e supporto in tema di ordini elettronici.
• Attività di gestione delle cessioni dei crediti vantati da fornitori e strutture sanitarie nei confronti delle Aziende Sanitarie del Lazio, ovvero:
⮚ Acquisire tutta la documentazione pervenuta presso la Regione Lazio in modalità cartacea o digitale;
⮚ Riportare in un tracciato standard i dati identificativi degli atti trasmessi e dei crediti oggetto di cessione;
⮚ Consultazione e verifica delle risultanze presenti sul Sistema Pagamenti del SSR.
⮚ Comunicazione ai fornitori delle Aziende Sanitarie delle risultanze delle verifiche effettuate
• Gestione delle comunicazioni
⮚ Predisposizione ed invio di comunicazioni rivolte ai fornitori delle Aziende Sanitarie;
⮚ Gestione delle risposte a richieste pervenute da parte dei fornitori delle Aziende Sanitarie;
⮚ Gestione delle caselle di posta dedicate (PEC e ordinarie);
⮚ Gestione delle comunicazioni e degli avvisi sul Portale Istituzionale di Regione Lazio.
• Monitoraggio dei documenti trasmessi in Conservazione a norma e supporto utenti
• Gestione e monitoraggio dei servizi di backend
⮚ Gestione di tutte le funzionalità di “admin” dei sistemi applicativi dell’Ecosistema: es. gestione anagrafiche, gestione documenti, log, audit, gestione job, ecc.
⮚ Gestione della reportistica: estrazione e analisi dei report richiesti da parte dell’Amministrazione Regionale, dagli utenti ASL e Fornitori, da LAZIOcrea;
⮚ Interfacciamento verso il team di sviluppo e manutenzione software;
Il servizio sopra descritto DOVRA’ essere erogato come servizio di tipo continuativo e sarà remunerato a corpo previa valutazione dei livelli di Servizio da parte della Stazione Appaltante.
Il Gruppo di Lavoro richiesto per la realizzazione delle attività oggetto del presente servizio DEVE essere composto da almeno i seguenti profili professionali i quali DEVONO avere almeno i requisiti di cui in Appendice 1.
Servizio | Figure professionali del team |
ID SAB – Assistenza e backend | Specialista di tematica |
Tot. GIORNI PERSONA |
6.2.3 ID SPP Supporto ai processi di pagamento
• Verifiche propedeutiche ai pagamenti (monitoraggio e controllo delle verifiche automatiche):
⮚ Verifica scadenza già pagate;
⮚ Verifica dell’effettiva titolarità del credito;
⮚ Verifica della correttezza dello split payment;
⮚ Verifica della correttezza dei dati bancari;
⮚ Verifica della corretta contabilizzazione delle note di credito;
• Verifiche della regolarità contributiva e fiscale;
• Monitoraggio notifiche inadempienza (DURC/Equitalia) e allineamento con le ASL per i pignoramenti;
• Gestione/Monitoraggio del processo di pagamento (supportato da Sistema Pagamento e BRIDGE SIOPE+) e chiusure contabili ASL;
• Monitoraggio stock debito scaduto;
• Monitoraggio e allineamento centralizzato contabilizzazioni fatture PCC (MEF);
• Supporto all’Amministrazione di LAZIOcrea durante tutte la fasi di pagamento.
Il servizio sopra descritto DOVRA’ essere erogato come servizio di tipo continuativo e sarà remunerato a corpo previa valutazione dei livelli di Servizio da parte della Stazione Appaltante.
Il Gruppo di Lavoro richiesto per la realizzazione delle attività oggetto del presente servizio DEVE essere composto da almeno i seguenti profili professionali i quali DEVONO avere almeno i requisiti di cui in Appendice 1.
Servizio | Figure professionali del team |
ID SPP Supporto ai processi di pagamento | Consulente Esperto di Organizzazione e Processi |
Analista di organizzazione e processi | |
Tot. GIORNI PERSONA |
6.3 Servizi ICT e sviluppo Software
L’Appaltatore DOVRA’ garantire i servizi di presa in carico, gestione e manutenzione dei sistemi software dell’ESIPA e servizi di reingegnerizzazione tecnologica dell’attuale Sistema Pagamenti
garantendo la corretta esecuzione delle funzionalità esistenti fino alla completa e conforme migrazione delle componenti oggetto di reingegnerizzazione, come meglio dettagliato nel successivo capitolo 7 del presente documento.
6.3.1 ID MSW - Manutenzione Evolutiva
Nell’ambito di questi servizi rientrano tutte le attività necessarie a garantire la manutenzione evolutiva dei sistemi software e dello stack tecnologico (infrastruttura e architettura) in esercizio dell’ESIPA che dovranno continuare ad esercire le proprie funzioni ordinarie parallelamente alle attività di reingegnerizzazione:
• Sistema Pagamenti e Fatturazione Elettronica (SIPA);
• Sistema Ordini Regionale (MOR e Cruscotto);
• Modulo PAS: Predictive Analysis System
• Sistema Mandati di Pagamento Centralizzati;
• Sistema Verifiche Automatiche dei Pagamenti;
• Piattaforma di Intermediazione Ordinativi di Pagamento Informatici (BRIDGE SIOPE+);
• Integrazione dell’ESIPA con l’eventuale sistema di gestione dei DDT elettronici;
• Sistema/Piattaforma di ticketing;
Il servizio sopra descritto prevede una rendicontazione a misura per un totale di 4.381 Giornate uomo sulla base dei PAI. Si riporta di seguito la composizione del team di lavoro richiesto per la realizzazione delle attività per il Servizio in oggetto, indicando nel caso di rendicontazione a misura il totale delle Giornate uomo richieste.
Servizio | Figure professionali del team | Giornate uomo a misura |
ID MSW - Manutenzione Evolutiva | Analista funzionale | 1.390 |
Analista programmatore | 2783 | |
Data-base Administrator | 120 | |
Sistemista | 88 | |
Tot. GIORNI PERSONA | 4.381 |
6.3.2 ID GAP - Gestione del portafoglio applicativo – Gestione Applicativi e Basi Dati
In questo ambito rientrano le attività di monitoraggio delle performance applicativa, Servizi di Service Desk e Supporto tecnico ai diversi referenti dei sistemi informatici esterni integrati con l'ESIPA e la manutenzione correttiva e adeguativa per i software già in esercizio e per il software reingegnerizzato.
Il servizio di Gestione applicativa e basi dati comprende l’insieme di attività, risorse e strumenti
di supporto per la gestione delle applicazioni e delle loro relative basi dati e degli strumenti a supporto necessari per il monitoraggio e ottimizzazione delle performance, correzione di bug, estrazione dati, correzione e aggiornamento di eventuali e potenziali vulnerabilità del software per tutti i sistemi informatici/moduli software dell’Ecosistema Pagamenti. Per ogni sistema o
componente applicativa in esercizio o nuovo e per ogni evoluzione di sistema negli ambiti
precedentemente descritti, i servizi di questo ambito sono:
Gestione delle funzionalità in esercizio:
• help desk applicativo:
⮚ prendere in carico le richieste di intervento da parte degli utenti provvedendo al loro censimento in uno strumento di Trouble Ticketing come previsto nell’Appendice 2 - Indicatori di qualità IQ 3.3 e IQ 3.4;
⮚ analizzare il problema segnalato e fornire al richiedente una prima ipotesi di
soluzione e di tempistica;
⮚ fare una diagnosi approfondita dei problemi di competenza diretta e intervento per la loro risoluzione;
⮚ fare escalation della segnalazione verso i soggetti competenti, se non risolvibile dal servizio o non di sua competenza;
⮚ aggiornare lo stato del ticket via via che viene portato avanti l’intervento e
chiudere il ticket a risoluzione avvenuta;
⮚ accertarsi che la soluzione adottata sia stata risolutiva;
⮚ fornire indicazioni agli altri servizi oggetto dell’appalto specifico per eventuali
attività di loro competenza (ad es. aggiornamento della configurazione del software, allineamento della documentazione, modifiche alle banche dati, ecc.);
⮚ risoluzione delle richieste di intervento aperte dall’utente;
⮚ intercettazione e registrazione dei problemi alla fonte, classificazione,
eventuale riproduzione dell’errore e, se necessario, conseguente attivazione del servizio di manutenzione correttiva e verifica dell’esito dell’intervento effettuato;
⮚ verifica e aggiornamento di eventuale documentazione specifica della gestione applicativa;
⮚ contenente FAQ, modi d’uso, modalità di esecuzione di particolari attività del
servizio di gestione (ad esempio manutenzione preventiva, ecc.).
Presa in carico di nuove funzionalità in esercizio:
• schedulazione e pianificazione del rilascio in esercizio di nuove funzionalità;
• attività di parametrizzazione specifiche su procedure, parametri e tabelle, manuale utente, manuale di gestione, definizioni relative ai dati, ecc.;
• supporto alla predisposizione dell’ambiente di esercizio, e quanto necessario a consentire l’inizio delle attività da parte degli utenti;
• gestione della nuova configurazione.
Supporto agli utenti, per l’uso appropriato delle funzioni secondo le modalità previste nei manuali d’uso
• assistenza tecnico/funzionale agli utenti;
• preparazione di documentazione aggiuntiva rispetto a quella a corredo dei sistemi in esercizio, (es. documenti di sintesi, demo, presentazioni, ecc.).
Pianificazione funzionale del servizio
• movimentazione e controllo giornaliero dei batch;
• verifica disponibilità del servizio on line;
• controllo e fasatura dell’introduzione di nuove versioni di software di base (anche in via estemporanea e/o transitoria) nell’ambiente gestionale;
• pianificazione ed esecuzione di elaborazioni di prova, con relativa ripresa di dati reali, a scopo di manutenzione preventiva, per anticipare l’esito dell’elaborazione di procedure critiche per la Società Appaltante
Supporto tecnico agli interlocutori esterni che hanno interesse nell’ESIPA per attività di System Integration:
• supporto ai referenti IT delle Aziende Sanitarie;
• supporto ai referenti IT di altri sistemi esterni all’ESIPA ma integrati con esso. Manutenzione correttiva
Nel servizio di Gestione Applicativi e Basi Dati, rientrano anche le attività di manutenzione correttiva che prevedono la diagnosi e la rimozione delle cause e degli effetti, sia sulle interfacce utente che sulle basi dati, dei malfunzionamenti delle procedure e dei programmi in esercizio ed in genere di tutti i componenti del sistema a decorrere dal completamento della presa in carico dei sistemi.
La manutenzione correttiva viene innescata da una segnalazione di impedimento all’uso dell’applicazione di una o più delle sue funzioni. Per impedimento si intende una malfunzione vera e propria dell’applicazione o gli effetti che tale malfunzione ha causato alla base dati (es. anomalie in un programma batch che corrompono la base dati, anomalie causate da query non
performanti, mancanza di indici, presenza di blob all’interno del data base, ecc.).
I malfunzionamenti, le cui cause non sono imputabili a difetti presenti nel software applicativo, ma ad errori tecnici, operativi o d’integrazione con altri sistemi (ad esempio interruzione del collegamento TP, uso improprio delle funzioni, ecc.), oppure relativi a software in gestione affidata a un fornitore diverso dell’aggiudicatario della presente Gara, comportano, nell’ambito
della manutenzione correttiva, il solo supporto all’attività diagnostica sulla causa del
malfunzionamento, a fronte della segnalazione pervenuta, ma sono poi risolti da altre strutture di competenza. Analogamente per il software realizzato/modificato/gestito nel corso del Contratto di cui alla presente gara, i malfunzionamenti dovranno essere risolti nell’ambito dei
servizi oggetto del presente appalto per tutta la durata contrattuale.
Fanno parte della manutenzione correttiva le seguenti attività:
• contributi di competenza sistemistica e specialistica di prodotto necessari alla corretta soluzione del malfunzionamento;
• attivazione del gruppo di sviluppo per adeguare l’eventuale software in corso di sviluppo/modifica/collaudo;
• test in ambiente assimilabile all’ambiente di esercizio della soluzione realizzata;
• gestione della configurazione;
• in caso di malfunzioni su programmi di interfaccia verso l’esterno, validazione tecnica e controllo dei risultati del contenuto dei flussi informativi destinati a strutture esterne o dei dati esposti negli elaborati del sistema;
• allineamento della documentazione.
Per i pacchetti e/o sw personalizzato o integrato:
• in caso di malfunzionamenti sulla componente di pacchetto di mercato è finalizzato a diagnosticare la natura del malfunzionamento distinguendo se questo è:
a. all’interno del codice sorgente del pacchetto di mercato;
b. all’interno del software parametrizzato/personalizzato;
• nel caso a. il servizio è tenuto alla tempestiva apertura della segnalazione sul contratto di manutenzione dello specifico pacchetto e alla successiva verifica dell’esito dell’intervento effettuato; le risorse deputate al servizio dovranno dimostrare un’approfondita conoscenza del pacchetto utilizzato dall’Società Appaltante, tale da azzerare i rischi di apertura di segnalazioni di malfunzionamento errate ovvero
segnalazioni che si risolvono con parametrizzazione del pacchetto;
• nel secondo caso x. xxxx quanto già indicato per le malfunzioni sul sw ad hoc.
All’affidamento del servizio l’Appaltatore può analizzare, a campione, il software esistente, nella sua totalità, al fine di determinare, con campionamento statistico, il volume della baseline in FP e il debito tecnico per funzione/applicazione (tasso di difettosità) dichiarato dall’Società Appaltante.
Manutenzione adeguativa
La manutenzione adeguativa comprende due tipologie di manutenzione ed in particolare:
• attività di manutenzione volta ad assicurare la costante aderenza delle procedure e dei programmi alla evoluzione dell’ambiente tecnologico del Sistema informativo ed al cambiamento dei requisiti (d’ambiente, di sicurezza). A titolo esemplificativo e non
esaustivo si citano le seguenti tipologie di intervento: adeguamenti necessari per l’aggiornamento di versioni del software di base e per l’aggiornamento delle versioni del
sistema realizzato nell’ambito del presente progetto, adeguamenti necessari per
preservare l’efficienza degli applicativi al variare delle condizioni e dei carichi di lavoro, ad esempio per migliorie di performance, per aumento delle dimensioni delle basi dati,
ecc.). Gli interventi di manutenzione adeguativa che rientrano in tale tipologia, qualora la stima per la realizzazione effettuata dall’Appaltatore ed approvata dalla Società Appaltante superi i 20 gg/uu, saranno classificati come interventi di manutenzione
adeguativa per il numero di giorni fino alla soglia indicata, mentre i giorni eccedenti tale soglia saranno gestiti e rendicontati come giorni di MEV;
• Attività di manutenzione volte ad assicurare la costante aderenza delle procedure e dei programmi all’evoluzione della normativa, ai cambianti organizzativi ed alle mutate esigenze dell’ente. Gli interventi di manutenzione adeguativa che rientrano in tale
tipologia, qualora la stima per la realizzazione effettuata dall’Appaltatore ed approvata
dalla Società Appaltante superi i 15 gg/uu, saranno classificati come interventi di manutenzione adeguativa per il numero di giorni fino alla soglia indicata, mentre i giorni eccedenti tale soglia saranno gestiti e rendicontati come giorni di MEV.
In particolare, per problemi tecnici che dovessero determinare il malfunzionamento del sistema, l’Appaltatore deve garantire, a seconda della tipologia di problema determinata ad insindacabile giudizio della Società Appaltante, la completa risoluzione del problema stesso nei termini indicati nell’Appendice 2 – Indicatori di Qualità :
Al riguardo, si precisa che:
• per segnalazione del guasto/malfunzionamento s’intende la data e l’orario dell’effettuazione della chiamata telefonica e/o dell’invio di un messaggio di posta elettronica e/o dell’invio di un fax e/o di apertura ticket da parte della Società Appaltante verso l’Appaltatore.
• per orario minimo di prestazione del servizio si rimanda al Capitolo 8.13 , fermo restando che la Società Appaltante si riserva l’insindacabile facoltà di richiedere in alcune situazioni particolarmente critiche la prestazione del servizio anche al di fuori del predetto orario;
• è interamente a carico dell’Appaltatore la determinazione della causa del problema, l’individuazione del guasto ed il ripristino della piena funzionalità del Sistema malfunzionante.
• l’Appaltatore DEVE inoltre garantire la manutenzione di tutte le componenti delle soluzioni
realizzate e DEVE provvedere alla risoluzione dei malfunzionamenti, intervenendo anche on- site ove necessario.
Per quanto riguarda gli interventi di manutenzione adeguativa, l’Appaltatore, a seguito di una
segnalazione da parte della Società Appaltante, deve presentare un piano di intervento entro e non oltre 24 (ventiquattro) ore lavorative dalla richiesta, salvo un diverso termine stabilito dalla Società Appaltante. Tale piano DEVE contenere le modalità e le tempistiche di esecuzione dell’intervento e sarà soggetto all’approvazione da parte della Società Appaltante. In caso di
interventi dovuti ad adeguamenti normativi, l’intervento DEVE comunque essere effettuato nel
rispetto degli eventuali termini ivi previsti.
Nell’ambito di questo servizio l’Appaltatore DOVRÀ rendere disponibile uno strumento di
Trouble Ticketing per il censimento e la gestione delle singole attivazioni di gestione applicativa e manutenzione correttiva e per il monitoraggio dei livelli di qualità del servizio come definiti nell’Appendice 2 – “Indicatori di qualità”.
L’ambito sopra descritto prevede una rendicontazione a corpo fatta eccezione per quanto previsto dalla manutenzione adeguativa..
Il Gruppo di Lavoro richiesto per la realizzazione delle attività oggetto del presente servizio DEVE essere composto da almeno i seguenti profili professionali i quali DEVONO avere almeno i requisiti di cui in Appendice 1.
Servizio | Figure professionali del team |
ID GAP Gestione del Portafoglio – Applicativa e Base Dati | Responsabile di progetto applicativo |
Specialista di tecnologia/prodotto | |
Analista Funzionale | |
Sistemista | |
Analista Programmatore | |
Data Base Administrator |
6.3.3 ID SSW Sviluppo Software
L’Appaltatore DOVRA’ realizzare il progetto di reingegnerizzazione tecnologica e funzionale del Sistema Pagamenti coerentemente con quanto previsto nell’ambito della realizzazione dei
moduli applicativi a supporto degli ordini elettronici, delle automazioni realizzate per le verifiche dei pagamenti e il modulo dei mandati regionali 2009-2017. Nel capitolo successivo verrà pertanto descritto il progetto di reingegnerizzazione che riguarderà il rifacimento di alcune funzionalità core attraverso i seguenti interventi:
• Predisposizione di una nuova infrastruttura tecnologica:
• Reingegnerizzazione dei servizi di:
⮚ Integrazione SDI e Gestione documenti contabili:
⮚ Riconciliazione fatture-flussi stato fattura;
⮚ Evoluzione del modulo Pagamenti
• Integrazione con le funzionalità già reingegnerizzate Interoperabilità Regionale
La soluzione attualmente implementata dalla Società Appaltante per garantire l’interoperabilità regionale e per la realizzazione di soluzioni di integrazione con architetture a micro-servizi nel rispetto delle nuove “Linee Guida Modello di Interoperabilità” di AgID è basata sul middleware WSO2.
L’adozione di un middleware unificato:
• assicura i servizi di sicurezza per tutte le applicazioni;
• semplifica il riuso dei servizi applicativi attraverso un API manager;
• isola la logica applicativa dall’evoluzione dei protocolli e delle interfacce;
• evita il proliferare di soluzioni eterogenee per le medesime funzioni. La soluzione WSO2 realizzata da LAZIOcrea è basata su:
• WSO2 API Manager/Gateway: realizza il punto d’accesso per i servizi d’integrazione applicativa e può essere brevemente sintetizzato nei macro-componenti schematizzati
in figura.
Figura 6: API Manager FRONT END
Il front-end dell’API Manager offre, via web l’insieme integrato delle funzionalità necessarie allo sviluppo delle interfacce dei servizi applicativi (API), supporta il versionamento delle interfacce, la documentazione e la pubblicazione nello API store
dell’insieme delle interfacce per i servizi applicativi;
• WSO2 Enterprise Integrator (ESB): utilizzato per l’integrazione e la comunicazione tra diverse applicazioni. Si colloca quale elemento di disaccoppiamento tra le applicazioni
per la gestione dei servizi inter-applicativi e il routing dei messaggi verso le loro destinazioni. Il prodotto include anche un profilo Analytics separato per un monitoraggio completo, un profilo di Message Broker (WSO2 MB) che può essere utilizzato per la messaggistica affidabile, nonché il profilo XXX0 XXX0x, che è possibile utilizzare per eseguire micro-servizi per i flussi di integrazione;
• Message Broker (MB) Apache Active MQ, integrato: utilizzato, integrato con la suite WSO2, per la riproduzione dei servizi asincroni esistenti basati su JMS publisher e SOAP subscribers.
Metodologia DevOps
La Società Appaltante ha deciso di adottare in modo incrementale su tutti i progetti la metodologia DevOps, al fine di garantire:
• la governance unica e centralizzata di tutte le iniziative progettuali;
• la gestione efficiente delle attività di sviluppo, test e rilascio delle componenti applicative;
• il monitoraggio della qualità dell’intero processo di sviluppo;
• la riduzione delle attività manuali e a basso valore aggiunto;
• la realizzazione di applicazioni sicure;
• una semplificazione nella gestione collaborativa delle attività dei diversi gruppi di lavoro coinvolti nel ciclo di sviluppo del software;
• la riduzione del time2market delle soluzioni software.
Tutti i sistemi già esistenti che rientrano negli ambiti di intervento descritti DEVONO essere pertanto evoluti dall’Appaltatore per permettere il passaggio alla metodologia DevOps sfruttando la piattaforma centralizzata e integrata messa a disposizione dalla Società
Appaltante. La piattaforma rappresenta lo strumento di orchestrazione e di controllo delle attività operative per l’attuazione delle pipeline DevOps Secure ed è basata su affermate soluzioni di tipo Open Source. Più precisamente per la realizzazione dei processi di Continuous
Integration e Continuous Delivery si sono adottati i seguenti strumenti:
Ruolo | Descrizione | Tool |
Orchestratore | Orchestrazione dei software presenti nella piattaforma DevOps mediante implementazione delle pipeline di Continuous Integration e Continuous Delivery. | Xxxxxxx |
Source Code Repository | Versioning e archiviazione dei codici sorgenti con supporto a branch strategy. | GITLab |
Artifact Repository | Software repository per la gestione delle componenti necessarie allo sviluppo e al rilascio delle applicazioni. Utilizzato in fase di sviluppo come repository sorgente per le librerie esterne necessarie e anche per versionare e pubblicare gli artefatti prodotti da installare sui server. | Nexus |
Build | Gestione delle attività di build dei pacchetti e gestione delle dipendenze tra questi (inclusi DB) | Apache Maven |
Analisi statica del codice e delle librerie a supporto | Piattaforma che esamina la possibile esposizione a bug di sicurezza noti come CWE/SANS TOP 25 e OWASP Top 10 e verifica la qualità del codice implementato e delle librerie a supporto dei sistemi. | SonarQube, Dependency- Check |
Deploy | Installazione dei pacchetti applicativi custom sugli ambienti target | Ansible |
Containerizzatore | Isolamento di tutte le risorse software necessarie ad un’applicazione, i file di configurazione, le librerie le | Doker |
Ruolo | Descrizione | Tool |
dipendenze e quant’altro necessario, in modo tale da poter essere eseguite all’interno di un Container (immagine) che assicura un proprio ambiente d’esecuzione sullo stesso sistema operativo | ||
Doker Registry | Piattaforma web per la gestione delle immagini docker | Portus |
Orchestratore container | Orchestrazione tra diverse immagini containerizzate per governare le operazioni in modo centrale ed integrato. | Kubernates |
Tabella 1 - Strumentazione della pipeline DevOps-Secure
Nella piattaforma, il processo di Continuous Delivery controlla le fasi del ciclo a partire dal design fino al rilascio in produzione. Le fasi inziali della CD possono essere raggruppate sotto il concetto di Continuous Integration il cui obiettivo è quello di supportare con continuità gli sviluppi dei singoli developer mediante l’integrazione dei loro deliverable assicurando allo
stesso tempo la qualità dei singoli pacchetti.
Parte integrante delle catene di CI e CD dovrà essere:
• la compilazione del codice sorgente recuperandolo da repository Git;
• l’esecuzione di sonar-scanner ovvero la componente client di SonarQube per l’analisi statica del software;
• l’esecuzione del dependency check per l’analisi delle dipendenze;
• l’esecuzione dell’intero insieme delle tipologie di test ad ogni iterazione a partire dagli
unit test fino ai component, integration test e agli scenari E2E;
• il caricamento su Nexus degli artefatti prodotti durante la compilazione;
• il deploy in collaudo\produzione all’interno del cluster di Kubernetes.
L’Appaltatore DOVRÀ utilizzare la piattaforma di DevOps Secure secondo gli standard e le indicazioni operative definite dalla Società Appaltante.
Cyber Security
Nella fase di progettazione e sviluppo DEVONO essere opportunamente considerati gli aspetti di sicurezza.
In particolare, DEVONO essere indirizzate le seguenti tematiche:
• inclusione dei requisiti di sicurezza nelle specifiche funzionalità dei servizi e dei sistemi in base agli standard attualmente in uso presso la Società Appaltante;
• adozione di best practice per lo sviluppo e la manutenzione del software durante la progettazione e il design dell’applicazione (Security by Design);
• gestione controllata della documentazione;
• separazione degli ambienti di sviluppo e test con impiego di procedure formali di accettazione nel passaggio fra gli ambienti.
In accordo con la Società Appaltante DOVRANNO essere inoltre adottate misure tecniche e organizzative atte a garantire elevati livelli di sicurezza in osservanza delle best practice di riferimento e della normativa applicabile (nazionale ed europea) in materia di tutela e protezione dei dati per gestire e mitigare rischi correlati ad aspetti quali:
• la distruzione, perdita, modifica, divulgazione non autorizzata o accesso, in modo accidentale o illegale, a eventuali dati personali trasmessi (es. codice fiscale degli utenti del sistema), conservati o comunque trattati;
• trattamento dei dati non consentito o non conforme alle norme e alle finalità delle operazioni di trattamento.
Nel caso di trattamento di dati personali e sensibili DOVRÀ essere implementata la crittografia con un algoritmo “forte”.
Ogni operazione effettuata da qualsiasi utente attraverso l’interfaccia grafica DOVRÀ essere
opportunamente registrata nei modi e formati preventivamente stabiliti di concerto con la Società Appaltante.
I log applicativi di sistema e software DOVRANNO essere integrati in una piattaforma unica e retention e rotation DOVRANNO essere configurate in base agli standard di sicurezza attualmente in uso presso la Società Appaltante.
L’ambito sopra descritto è a ciclo di sviluppo intero o completo (a partire dall’analisi dei requisiti e sino all’avvio in esercizio) ed è remunerato a corpo.
Il Gruppo di Lavoro richiesto per la realizzazione delle attività oggetto del presente servizio “Sviluppo Software” DEVE essere composto da almeno i seguenti profili professionali i quali DEVONO avere almeno i requisiti di cui in Appendice 1.
Servizio | Figure professionali del team |
ID SSW Sviluppo Software | Responsabile di progetto applicativo |
Analista funzionale | |
Specialista di prodotto/tecnologia | |
Architetto applicativo | |
System Integrator | |
Data Base Administrator | |
Analista programmatore | |
Sistemista | |
Test Specialist |
6.4 Riepilogo delle giornate uomo e Team Mix per i Servizi Richiesti
Si riporta di seguito una vista complessiva della composizione del team di lavoro richiesto per la realizzazione delle attività di ciascuno dei Servizi di Gara, indicando, nel caso di rendicontazione a misura il totale esatto delle giornate uomo a disposizione della Società Appaltante, fermo restando che quest’ultima, in ogni caso, riconoscerà e autorizzerà il
pagamento delle sole attività effettivamente svolte in esecuzione di quanto preventivato nel
Piano delle attività e che procederà al pagamento ed allo scorporo (dal monte di giornate/persona destinate al servizio) delle sole giornate/persona indicate nei Piani delle attività preventivamente approvati dalla Società stessa. Fermo restando quanto sopra la Società Appaltante si riserva l’insindacabile facoltà di utilizzare in tutto o in parte le
giornate/persona messe a disposizione dall’Appaltatore e nessun compenso sarà
riconosciuto/dovuto all’Appaltatore per le giornate/persona eventualmente non utilizzate.
Servizio | Figure professionali del team | Giornate uomo a misura |
ID SOC – Consulenza specialistica in continuità | Senior Advisor | 660 |
Consulente Esperto di Organizzazione e Processi | 5.662 | |
Tot. GIORNI PERSONA SOC | 6.322 | |
ID SOE - Consulenza specialistica per le evoluzioni dei sistemi e il supporto ad altre Direzioni | Consulente Esperto di Organizzazione e Processi | 1.375 |
Demand Manager | 690 | |
Tot. GIORNI PERSONA SOE | 2.065 | |
ID SOP – Supporto alla revisione dei processi e Process Mining | Consulente Esperto di Organizzazione e Processi | 230 |
Analista di organizzazione e processi | 230 | |
Tot. GIORNI PERSONA SOP | 460 | |
ID SOG - Governance di progetto e PMO | Responsabile di progetto applicativo | 690 |
Tot. GIORNI PERSONA SOG | 690 | |
ID SCM - Change Management | Analista di organizzazione e processi | 200 |
Tot. GIORNI PERSONA SCM | 200 | |
ID MSW - Manutenzione Evolutiva | Analista funzionale | 1.390 |
Analista programmatore | 2783 | |
Data-base Administrator | 120 | |
Sistemista | 88 | |
Tot. GIORNI PERSONA MSW | 4.381 | |
Tot. GIORNI PERSONA | 14.118 | |
In considerazione della necessità che alcune figure professionali operino in parallelo sui vari sistemi nonché in diversi servizi, il gruppo di lavoro DEVE essere composto almeno dalle seguenti figure professionali e dal relativo numero di risorse come riportato nella seguente tabella per l’intera durata dell’appalto. L’appaltatore dovrà garantire che il gruppo di progetto
sia composto da almeno il seguente numero di persone in relazione a ciascuna figura
professionale.
Figure professionali del team | Numero di persone |
Analista di organizzazione e processi | 9 |
Analista Funzionale | 3 |
Analista Programmatore | 12 |
Architetto applicativo | 1 |
Business Intelligence Expert | |
Consulente Esperto di Organizzazione e Processi | 15 |
Data Base Administrator | 1 |
Data scientist | |
Demand Manager | 1 |
Operatore Data Entry | |
Progettista DW/BI | |
Programmatore | |
Responsabile di progetto applicativo | 2 |
Senior Advisor | 1 |
Sistemista | 1 |
Specialista di pacchetto | |
Specialista di tecnologia/prodotto | |
Specialista di tecnologia/prodotto senior | 1 |
Specialista di tematica | 3 |
System integrator | 1 |
Test specialist | 1 |
Totale | 52 |
La Società Appaltante si riserva il diritto di disporre la rimodulazione dei gruppi di lavoro con una diversa distribuzione delle giornate/persona tra le diverse figure professionali, a parità di costo, eventualmente eseguendo una conversione del numero di giornate qualora i costi giornata differiscano per le diverse figure.
L’Appaltatore DEVE prestare tutte le attività oggetto del presente appalto mediante un Gruppo
di Xxxxxx dedicato, con le competenze professionali e le qualifiche meglio descritte nel seguito del presente paragrafo.
Le risorse dell’Appaltatore preposte ai servizi oggetto del presente appalto DEVONO avere e mantenere per tutta l’esecuzione dell’appalto una ottima preparazione sulle applicazioni, sia di tipo funzionale, sia tecnica e lavorare in sinergia con i restanti membri del team impegnati nei
servizi di sviluppo al fine di rispondere prontamente ed efficacemente alle diverse esigenze di progetto.
La Società appaltante nel corso dell’esecuzione dell’appalto verificherà le competenze e le
capacità del personale addetto alle prestazioni dovute, svolgendo analisi sui curricula resi disponibili ed effettuando dei colloqui con le singole figure professionali, anche al fine di verificare che nell’esecuzione delle attività appaltate sia impiegato esattamente il medesimo
gruppo di lavoro indicato nell’Offerta tecnico-economica presentata in sede di gara.
Qualora, a seguito di tali rilevazioni, emergessero incongruenze tra le risorse professionali
proposte in sede di gara dall’Appaltatore e quelle effettivamente rese disponibili per l’esecuzione dell’appalto, la Società Appaltante si riserva la facoltà di richiedere la sostituzione del personale addetto alle prestazioni dovute, che fosse diverso da quello indicato in sede di
offerta dall’Appaltatore e/o che non possieda effettivamente le competenze/conoscenze dichiarate in sede di offerta e/o che fosse motivatamente ritenuto dalla Società Appaltante non idoneo alla perfetta esecuzione dell’appalto.
L’esercizio di tale facoltà e l’eventuale sostituzione del personale dell’Appaltatore non comportano alcun onere aggiuntivo rispetto al corrispettivo di cui oltre per la Società
Appaltante e/o per la Regione Lazio. In caso di richiesta di sostituzione di unità di personale deputate all’esecuzione del presente appalto, l’Appaltatore DEVE provvedere entro 3 (tre) giorni lavorativi dalla richiesta, integrando il gruppo di lavoro con soggetti dotati di esperienza
e capacità pari o superiori a quelle dei soggetti da sostituire, ferma restando la necessità di ottenere la preventiva autorizzazione scritta da parte della Società Appaltante.
Qualora l’Appaltatore proponga la sostituzione di un componente del gruppo di lavoro con una
risorsa con un profilo superiore a quello richiesto dalla Stazione Appaltante, tale sostituzione non comporterà oneri aggiuntivi per la Stazione Appaltante e la tariffa riconosciuta sarà pari a quella corrispondente al profilo sostituito.
Fermo restando quanto sopra, la Società Appaltante approverà ed autorizzerà a tutti gli effetti l’eventuale sostituzione di una risorsa professionale proposta dall’Appaltatore solo in casi di eccezionale impossibilità di prosecuzione dell’appalto da parte della stessa, debitamente
motivati e comprovati dall’Appaltatore. In caso di diniego, ad insindacabile giudizio della Società Appaltante, dell’autorizzazione alla sostituzione della risorsa, l’Appaltatore DEVE
garantire l’esecuzione delle attività appaltate da parte della risorsa di cui ha proposto la sostituzione.
Resta inteso che l’eventuale sostituzione di unità di personale NON DEVE in nessun modo avere ripercussioni negative sulle attività di progetto e sul rispetto delle relative scadenze prefissate.
7 FOCUS SUL PROGETTO DI REINGEGNERIZZAZIONE: REQUISITI
L’obiettivo del presente capitolo è definire il modello a tendere dell’architettura funzionale e tecnologica dell’Ecosistema Pagamenti (ESIPA) di LAZIOcrea S.p.A. che l’Appaltatore DEVE rispettare nell’esecuzione del presente appalto. Nello specifico, tale modello ha come obiettivo l’identificazione di ambiti funzionali specializzati, chiamati “micro servizi”, ognuno dei quali assolve ad un set limitato e indipendente di funzionalità erogabili come processi “utente”, processi di System Integration e come processi “ancillari” a supporto dei primi due.
Di seguito sono descritti i servizi che l’appaltatore DEVE prestare in relazione al servizio ISSSW sviluppo software.
7.1 Architettura funzionale Ecosistema Pagamenti
L’immagine di seguito illustra l’architettura funzionale definita per l’ESIPA, con una classificazione dei relativi micro-servizi in “ambiti funzionali” (esagoni in figura).
Figura 7: Modello target architettura funzionale ESIPA
Nell’elaborazione del presente modello sono stati tenuti in considerazione alcuni principi fondamentali dell’ingegneria del software in modo da governare sia l’eterogeneità che la complessità delle funzioni del sistema attuale. Il disegno dell’architettura funzionale del modello “OBIETTIVO” è quindi guidato dai seguenti principi:
• Divide et impera: l’ ESIPA, rende disponibile agli utenti un gran numero di funzionalità (l’analisi svolta sullo stato dell’arte del sistema ha consentito di tracciare oltre 200
funzionalità) che sono state definite in tempi diversi e aggregate in un unico software (SIPA): la divisione in ambiti funzionali separati va nella direzione opposta, abilitando la
creazione di sotto-sistemi autonomi e meno complessi da analizzare, manutenere e evolvere;
• Single Responsibility e Collaboration: ogni ambito funzionale (esagono) comprende funzionalità auto consistenti, la cui composizione consente di supportare per sé interi macro-processi;
• Testability & Maintainance: il design funzionale così rappresentato rende ogni modulo testabile e manutenibile indipendentemente dagli altri: ciò consente un maggior controllo quando, nel normale ciclo di sviluppo software, vengono introdotte nuove funzionalità riducendo la numerosità di test di regressione interna e cross-modulo e favorendo la definizione delle API (Application Programming Interface);
• Additività, Scalabilità: la definizione di un nuovo set di funzionalità indipendenti tra loro consentono sia all’analista che al progettista della soluzione di decidere se creare un nuovo “ambito funzionale” o far crescere le funzionalità di un “ambito funzionale” esistente;
• Indipendenza dalle scelte tecnologiche: sebbene il termine “micro servizi” venga usato
in ambito tecnologico, il modello definito non è necessariamente vincolato ad un particolare design architetturale, tuttavia il mapping tra un microservizio funzionale e la sua implementazione risulta naturale;
• User friendly: omogeneizzare le UX/UI di tutti gli ambiti funzionali individuati all’interno dello schema architetturale, rappresentato in “Figura 7: Modello target architettura funzionale ESIPA”, tramite un’unica interfaccia utente.
Le logiche di reingegnerizzazione del SIPA richiedono il ricorso a un insieme di micro servizi relativi agli ambiti funzionali rappresentati in “Figura 7: Modello target architettura funzionale ESIPA”, classificati nelle seguenti macro categorie:
• Enterprise Application Services: comprendente gli ambiti funzionali strumentali a garantire le caratteristiche di un Sistema di classe “Enterprise”: identificazione e accesso utenti, Logging applicativo, archiviazione di file/documenti, gestione di messaggi (es.
code per ricezione/invio messaggi di tipo notifiche applicative, email, XML, JSON, EDI). Scopo di tali servizi è garantire l’accesso al sistema, la sicurezza e continuità operativa e monitoraggio, flussi di lavoro utente;
• Core Functional Services: comprendente l’insieme delle funzionalità atte a garantire la copertura dei processi utente che caratterizzano l’ESIPA, fra cui “Case Management tool” che consente la gestione delle fatture/cessione e dei contratti di budget,
“Riconciliazione tra fatture e flussi di liquidazione”, “Gestione Pagamenti” e “Ticketing System”;
• Integration Services: comprendente gli ambiti funzionali strumentali a garantire l'integrazione dell’ESIPA con Sistemi informativi e gestionali di altre PA: NSO (Ordini), SDI (Fatture), SPID, SIOPE+, software Gestionali Contabili delle AASS, Sistema
Ospedaliero Regionale (SIO), Sistema Informativo Assistenza Specialistica (SIAS), Sistema Informativo Assistenza Territoriale (SIAT), Rapporto accettazione-dimissione per la Riabilitazione del Lazio (sistema RAD-R), Sistemi per la conservazione sostitutiva, APP-IO di AgID.
7.1.1 Dettaglio funzionalità soluzione Obiettivo
7.1.1.1 Enterprise Application Services
L’Enterprise Application Services rappresenta l’insieme delle funzionalità di base per un Sistema di classe Enterprise. Nel seguito sono descritte le funzionalità che ciascun “Ambito funzionale” afferente agli Enterprise Application Services dovrà rendere disponibili attraverso
l’implementazione di specifici micro-servizi.
7.1.1.1.1 Identity Access Management
Il modulo comprende le funzionalità per la gestione dell’accesso all’ESIPA da parte degli utenti
e dei sistemi esterni. Tale ambito funzionale rivestirà un ruolo strategico di particolare rilevanza per garantire il superamento delle criticità rilevate in fase di Assessment ed esplicitate nel Capitolo Errore. L'origine riferimento non è stata trovata. del presente documento: l’evoluzione f
unzionale dell’ESIPA prevede, infatti, il passaggio da un funzionamento del sistema "Centrico
rispetto alla tipologia di fatturazione" a un funzionamento di tipo "Utente centrico". Secondo tale logica, l’ESIPA dovrà prevedere delle specifiche funzionalità di profilazione degli utenti e successiva aggregazione degli stessi in gruppi, attraverso l'implementazione di "Group Policy
Object" (di seguito GPO). L'implementazione di GPO dovrà consentire a ciascun utente di avere visibilità sui dati e accesso a specifiche funzionalità del Sistema in ragione dell'appartenenza a uno o più "Gruppi". Nello specifico, le utenze potrebbero essere aggregate nei seguenti “Gruppi”:
• Utenti di tipo Fornitore, comprendente tutti gli attori che usufruiscono dell’ESIPA per le operazioni di adesione alla Disciplina Uniforme, sottoscrizione dei Contratti di Budget,
fatturazione e monitoraggio dei pagamenti, dei dati e della documentazione di propria competenza;
• Utenti di tipo Azienda Sanitaria, comprendente tutti gli attori che usufruiscono del Sistema per l'emissione di ordini, sottoscrizione dei contratti di budget, ricezione delle
fatture emesse dai propri fornitori, invio di flussi di liquidazione, monitoraggio dei dati e dei documenti di propria competenza;
• Utenze di Sistema e Applicative, comprendente tutti gli attori che svolgono a vario titolo operazioni di amministrazione, monitoraggio, supporto alle altri categorie di utenti, utenze applicative (include operazioni automatiche quali ad esempio validazione delle fatturePA trasmesse da/verso il sistema SDI, riconciliazione fatturePA con flussi di liquidazione, verifiche automatiche propedeutiche al pagamento, nonché le utenze di tipo “user di integrazione” strumentali a garantire l’interoperabilità con sistemi terzi);
• Altri stakeholders dei processi di pagamento, comprendente tutti gli altri stakeholders dei processi di pagamento coinvolti a vario titolo nell'Ecosistema Pagamenti del SSR, quali Cessionari e Service.
Figura 8 – Vista logica dei gruppi di utenti nei relativi sotto-gruppi
Si riporta nel seguito una descrizione delle funzionalità del modulo di “Identity Access Management”:
• Registrazione degli utenti sull’ESIPA sia attraverso form di registrazione che tramite l’integrazione con sistema SPID (Sistema Pubblico di Identità Digitale) ed esposizione delle maschere contenenti i campi da compilare (codice fiscale, nome, cognome, email);
• Profiling degli utenti in una fra le macro categorie citate precedentemente e conseguente associazione a ciascun utente di specifici ruoli nel Sistema, visibilità sui dati, accesso alle funzionalità disponibili in base al profilo applicativo dell’utente;
• Gestione degli accessi all’ESIPA per i vari gruppi di utenti;
• Implementazione delle policy di sicurezza in fase di log-in degli utenti mediante assegnazione di una password a ciascun utente, implementazione delle regole di scadenza delle password, reset delle password, autenticazione multi-factor per l’esecuzione di specifiche operazioni;
• Aggiunta/rimozione/aggiornamento degli utenti e dei loro ruoli;
• Creazione manuale di nuove utenze da parte di un utente di tipo “Amministratori di sistema
- Utenti di back office”;
• Assegnazione dinamica delle funzionalità ai rispettivi profili e ai relativi ruoli da parte di un utente di tipo “Amministratori di sistema - Utenti di back office” mediante l’utilizzo di un “Pannello di gestione utenze e ruoli”;
• Protezione dei dati personali in coerenza con i dettami normativi del Regolamento (UE) n. 2016/679 (GDPR).
A titolo esemplificativo, si riporta nel seguito l’iter di registrazione per utenti afferenti il gruppo “Fornitori” e una descrizione dello stesso.
Figura 9 – Workflow registrazione utenti di tipo “Fornitore”
Il processo di registrazione degli utenti di tipo “Fornitore” dovrà prevedere due differenti modalità:
• Registrazione tramite SPID/Credenziali IAM (Identity Access Management)
▪ Inserimento credenziali SPID/IAM (almeno livello 2) da parte del rappresentante legale di una o più imprese;
▪ Compilazione delle maschere relative ai dati anagrafici delle imprese disponibili
sull’interfaccia grafica dell’ESIPA, selezionando inoltre il ruolo di ciascuna impresa fra “Fornitori di Beni e Servizi”, “Fornitori di Beni e Servizi – Farmacie”, “Soggetti Erogatori con Contratto di Budget”, “Cessionari” e “Service” (senza vincoli di mutua esclusione);
▪ Ricezione email di conferma sull’indirizzo di posta elettronica dichiarato dal rappresentante legale, contenente le credenziali di accesso all’ESIPA;
▪ Conferma email da parte del rappresentante legale e re-indirizzamento automatico sull’ESIPA;
▪ Upload della documentazione inerenti i poteri di firma sull’ESIPA da parte del rappresentante legale;
▪ Apertura automatica di una lavorazione di “Registrazione nuovo utente” sull’ESIPA;
▪ Verifica documentazione caricata sull’ESIPA da parte di un utente afferente il sotto gruppo “Amministratori di Sistema - Struttura di Supporto”;
▪ Nel caso in cui l’esito del processo di verifica sia positivo, l’ESIPA invia una notifica di “Registrazione confermata” al rappresentante legale della/e impresa/e;
▪ Nel caso in cui l’esito del processo di verifica sia negativo, l’ESIPA invia una “Richiesta di integrazione di ulteriore documentazione” all’indirizzo email del rappresentante legale della/e impresa/e;
▪ Il rappresentante legale effettua l’upload della documentazione integrativa richiesta sull’ESIPA;
▪ La Struttura di Supporto esamina la documentazione integrativa caricata sull’ESIPA: se l’esito della verifica è positivo l’ESIPA invia una notifica di “Registrazione confermata” al rappresentante legale della/e azienda/e (fine del workflow), altrimenti l’ESIPA invia una “Richiesta di integrazione di ulteriore documentazione” all’indirizzo email del rappresentante legale della/e azienda/e, fintanto che l’esito della verifica non risulti positivo.
Si riporta nel seguito la “matrice di visibilità” contenente una mappatura di alto livello dei gruppi di utenti precedentemente citati sugli ambiti funzionali di cui potranno fruire in ragione del proprio ruolo sull’ESIPA.
Figura 10 – Matrice di visibilità Gruppi di Utenti/Ambiti funzionali
Il presente ambito funzionale riguarda le funzionalità di Logging/Audit Trail che l’ESIPA reingegnerizzato dovrà erogare al fine di supportare gli utenti afferenti gli “Amministratori di Sistema” (sotto-gruppo degli “Utenti di Sistema”) nelle operazioni di monitoraggio di tutte le funzionalità dell’Ecosistema Pagamenti del SSR del Lazio. Nello specifico, il modulo di “Logging/Audit Trail” dovrà erogare le seguenti funzionalità:
• Consentire la raccolta e l’analisi di dati eterogenei inerenti i log delle operazioni effettuate dagli utenti in merito sia ai processi utente quali, per esempio, “Immissione fatturePA”, “Gestione dei Pagamenti”, includendo quindi le operazioni di riconciliazione dei Flussi Stato
Fattura con le relative FatturePA, “Immissione Fatture” (da parte dei Fornitori , Soggetti Erogatori e XX.XX.), “Gestione degli Ordini”, “Gestione Anagrafica Utente”, “Gestione Cessioni”, “Gestione Segnalazioni (Ticket)”, sia in merito ai processi applicativi: utilizzo memoria, spazio disco, disponibilità di un servizio applicativo esterno;
• Abilitare una gestione automatica dei dati personali/sensibili attraverso il Data masking a livello applicativo;
• Supportare l'elaborazione complessiva dei dati, indipendentemente dall'origine degli stessi, dal formato o dal relativo modello dati;
• Supportare la normalizzazione, l’arricchimento e l’archiviazione dei dati secondo logiche di
aggregazione configurabili dagli Amministratori di Sistema attraverso la creazione di filtri sulle informazioni di logging;
• Supportare gli Amministratori di Sistema nello svolgimento di operazioni di monitoraggio dei log aggregati in cluster in ragione dello specifico dominio attraverso delle dashboard configurabili che producano ed espongano grafici on demand (es. torte, istogrammi, grafici a dispersione) anche relativi alle serie storiche di ciascun dominio.
Gli ambiti di applicazione individuati per il presente ambito funzionale riguardano:
• L’analisi della correlazione fra i log e i ticket aperti dagli utenti durante la fruizione delle funzionalità erogate dai micro servizi afferenti i Core Functional Services (il modulo di
immissione fatturazione va in eccezione applicativa e gli utenti aprono un ticket del tipo “Problema immissione fatturazione”);
• L’erogazione di funzionalità di Process Mining che consentano di utilizzare i “log” applicativi afferenti ai “Processi applicativi” di BPM e alle relative interazioni con gli ambiti funzionali “ancillari” (Enterprise Application Services) per eseguire analisi “evidence based” (oggettive) che supportino:
▪ L’incremento delle performance di processo attraverso il monitoraggio dei relativi KPI, l’individuazione di eventuali elementi di inefficienza (colli di bottiglia) e di possibili soluzioni di miglioramento;
▪ Il mantenimento di elevati livelli di aderenza fra processi di business e applicazioni a supporto;
▪ Il mantenimento della compliance dei processi rispetto a best practice e/o regolamenti interni.
• Il controllo “in isolamento” dei rilasci (Canary test): gli operatori incaricati della realizzazione di attività di aggiornamento del codice e di script sui database in uso a ciascun ambito
funzionale hanno la possibilità di fruire del “Logging” per individuare eventuali errori ed effettuare un roll back sulla versione precedente del software in tempi rapidi.
Si riporta nel seguito una rappresentazione delle logiche di funzionamento dell’ambito funzionale “Logging/Audit Trail”.
Figura 11 – Logiche di funzionamento dell’ambito funzionale “Logging/Audit Trial”
7.1.1.1.3 Eventi/Messaggi Applicativi
Il presente ambito funzionale ha per oggetto le funzionalità che l’ESIPA reingegnerizzato dovrà erogare al fine di garantire la gestione delle code di notifiche/messaggi applicativi (interni ed
esterni al Sistema). Nello specifico, le funzionalità del presente ambito sono descritte nel seguito:
• Memorizzazione delle code garantendo adeguati livelli di persistenza;
• Supportare lo scambio di notifiche/messaggi applicativi fra i microservizi dell’architettura target dell’ESIPA;
• Supportare l’esecuzione di operazioni quali l’accodamento dei messaggi e l’instradamento dei messaggi/notifiche delle code;
• Supportare il bilanciamento di carico dei messaggi/notifiche e garantire l'elevata disponibilità dei dati;
• Garantire agli utenti di tipo “Amministratori di sistema - Utenti di back office” la possibilità di eseguire operazioni quali:
▪ Aggiungere elementi alla coda, garantendo inoltre la possibilità di definire code di priorità;
▪ Visualizzare il messaggio in cima alla coda senza rimuoverlo;
▪ Rimuovere elementi dalla coda;
▪ Rimuovere l’elemento in cima alla coda e visualizzare il nuovo elemento in capo alla coda;
▪ Monitorare il numero di elementi in coda;
▪ Presentare informazioni inerenti lo stato delle code attraverso una specifica dashboard.
Le funzionalità precedentemente descritte consentiranno di migliorare notevolmente la gestione attuale delle azioni automatiche eseguite dal sistema. Di seguito sono riepilogati alcuni dei principali vantaggi:
• Scalabilità e Velocità. La separazione di azioni tra il publisher, subscriber e coda consentono di aumentare sensibilmente la velocità delle azioni all’interno dell’ESIPA. Ogni attore sarà responsabile unicamente dell’esecuzione dell’azione per cui è stato configurato:
▪ Il ruolo del publisher è unicamente quello di scrivere il messaggio all’interno dell’apposita coda (distinzione data dal topic);
▪ La coda è responsabile nel garantire la ricezione del messaggio da parte del subscriber;
▪ Il subscriber deve eseguire l’azione configurata ogni volta che all’interno della coda alla quale è stato assegnato viene inserito un nuovo messaggio.
• Affidabilità. La messaggistica di tipo asincrono consente alle varie applicazioni dell’ESIPA di eseguire notevoli carichi di lavoro contemporaneamente in modo uniforme. Per mezzo del pannello di configurazione e controllo, sarà possibile monitorare gli errori
intermittenti e configurare nuove code per migliorare o aggiungere funzionalità al sistema.
• Semplificazione delle comunicazioni. Una gestione di eventi/messaggi applicativi basata su code facilita la comunicazione tra le diverse piattaforme, linguaggi di programmazione o protocolli di comunicazione diversi presenti all’interno
dell’architettura.
Figura 12 – Funzionalità di scrittura, gestione e ricezione dei messaggi tramite l’utilizzo di una coda
Si precisa che il presente ambito funzionale, in sinergia con gli ambiti funzionali afferenti gli Integration Services, consentirà la gestione dei messaggi da inviare ai moduli “client” dell’ESIPA, siano essi sistemi in uso ai cittadini o ad altre Pubbliche Amministrazioni. Secondo tale logica, ogni sotto-sistema dell’ESIPA emetterà “messaggi”/”eventi” quindi, come “publisher”, scriverà
su una coda (topic delle code) un messaggio. Il WS “client”, per esempio verso la App IO sarà
invece “subscriber”, ovvero leggerà dal “topic” della coda e a sua volta “scrive” su App IO per l’invio di notifiche al cittadino relative alla liquidazione di una fattura, alla ricezione di un nuovo pagamento etc.).
Un’ulteriore esempio di applicazione del presente ambito funzionale è il ciclo di fatturazione passiva:
• Il modulo di System Integration “SDI” dell’ESIPA riceve una nuova fattura dallo SDI. Il web service assume il ruolo di publisher scrivendo il “messaggio” di ricezione nuova fattura sulla coda relativa alla gestione delle fatture passive;
• Il modulo “Business Rules/Verifiche” dell’ESIPA legge il “messaggio” sulla coda, in quanto subscriber, e procede con le verifiche automatiche (es: firma accordo da fornitore/soggetto erogatore, validazione iban, etc.). In base all’esito delle verifiche, il sistema pagamenti scrive un nuovo messaggio sulla coda;
• Il modulo “Fatture” dell’ESIPA legge il “messaggio” sulla coda di verifiche automatiche con esito “OK”, in quanto subscriber, e procede con la memorizzazione della fattura;
• Eseguita l’azione di memorizzazione della nuova fattura, il sistema pagamenti diventa a sua volta publisher di un “messaggio” nella coda relativa al prelevamento della fattura per l’ASL;
• Il Sistema Gestionale dell’ASL può quindi prelevare la fattura SDI dall’ESIPA.
Le funzionalità precedentemente descritte dovranno essere implementate per l’acquisizione dei flussi relativi agli Stati Fattura.
Il modulo funzionale riguarderà le funzionalità che l’ESIPA reingegnerizzato dovrà erogare agli utenti afferenti ciascuno dei gruppi individuati nel paragrafo 7.3.1.1 nell’ambito della gestione documentale. Nello specifico, le funzionalità previste per tale ambito funzionale riguardano:
• La gestione di contenuti di diverso tipo (documenti, record, pagine Web, immagini, contenuti avanzati);
• La realizzazione di ricerche semplici, avanzate e full-text;
• La gestione del versioning dei documenti e dello storico delle modifiche;
• La gestione dei metadati;
• L’implementazione di politiche di sicurezza per limitare l’accesso e/o le modalità di utilizzo dei documenti;
• L’identificazione automatica di contenuti soggetti a GDPR e la relativa anonimizzazione;
• L’applicazione di controlli di sicurezza e la gestione dei contenuti soggetti a GDPR su tutto il loro ciclo di vita (acquisizione, elaborazione, disposizione).
Il presente ambito funzionale abiliterà la condivisione di documenti afferenti diverse entità (Fatture, Cessioni, Contratti di Budget etc.) fra i relativi attori competenti, garantendo inoltre adeguati livelli di scalabilità.
7.1.1.2 Core Functional Services
I Core Functional Services rappresentano l’insieme delle funzionalità utente che l’ESIPA reingegnerizzato dovrà erogare al fine di garantire adeguati livelli di copertura funzionale ai
processi “Core” ovvero caratteristici dell’ESIPA. Nei seguenti paragrafi sono descritte le funzionalità che ciascun modulo o “Ambito funzionale” afferente ai Core Functional Services dovrà rendere disponibili attraverso l’implementazione di specifici micro servizi.
Il Ticketing System deve fornire un adeguato supporto informatizzato nella gestione delle interazioni con i fornitori (fornitori di beni e servizi, farmacie e soggetti erogatori), XX.XX. e utenti interni al perimetro della Regione Lazio fornendo una vista centralizzata e deve consentire la gestione delle segnalazioni/richieste inviate da utenti al servizio di assistenza attraverso canali quali e-mail, chiamata telefonica, integration API con Case Management tool. Qualsiasi domanda, commento o problema di un fornitore, azienda sanitaria e utente interno costituisce un nuovo ticket, ovvero un oggetto nel quale è tracciata la richiesta suddivisa per
tipologia (classificazione dei singoli “ticket” all’interno di aree tematiche predefinite). La
tipologia consente all’utente di tipo amministratore di configurare dinamicamente le regole di assegnazione dei “ticket” agli attori preposti. Il singolo ticket contiene al suo interno l’insieme delle informazioni necessarie per la sua risoluzione, come la vista sui dati anagrafici necessari
per effettuare attività di analisi, una sezione relativa al thread di e-mail inviate al fornitore, Azienda Sanitaria o utente interno per la risoluzione della casistica, accessi rapidi alle funzionalità necessarie (divise per tipologia di ticket).
A titolo esemplificativo di seguito è riportato il processo di gestione di ticket generico:
Figura 13 – Processo di gestione di un ticket
Il processo di gestione di un ticket generico si compone delle seguenti attività:
• Creazione di un nuovo ticket da parte di un utente sia interno che esterno al perimetro della Regione Lazio;
• Selezione della tipologia di ticket aperto (operazione obbligatoria);
• Assegnazione alla coda. Ogni nuovo ticket creato sarà assegnato agli operatori preposti per la sua risoluzione;
• Presa in carico dell'operatore della struttura di supporto. Il ticket sarà visualizzato all’interno di una vista centralizzata contenente tutti i ticket assegnati alla propria coda (la coda di assegnazione determinerà le tipologie di ticket accessibili all’utente);
• Lavorazione da parte dell'operatore della struttura di supporto;
• Chiusura del ticket. L'operatore della struttura di supporto, al termine della lavorazione, procede con la chiusura del caso;
• Invio notifica automatica. Al termine della lavorazione viene inviata automaticamente una notifica all'utente che ha aperto il ticket per informarlo della sua risoluzione.
La realizzazione di un sistema di ticketing così articolato e vasto necessiterà di un adeguato supporto anche dalla “struttura organizzativa”. In particolare, il Ticketing System dovrà
condividere il modulo Identity Access Management dell’ESIPA, descritto nel paragrafo 7.1.1.1.1, e
quindi dovrà essere accessibile sia dalla struttura di backoffice (1° livello) che quella tecnica (2° livello) per la gestione sia di ticket funzionali che tecnici. Di seguito è riportato mostrato un esempio di gestione “ticket” basato su una struttura a due livelli:
Figura 14 – Struttura organizzativa dedicata alla risoluzione dei ticket
Il sistema assegnerà di default ogni nuovo ticket aperto agli operatori di primo livello (utenti di back office). Nel caso in cui il primo livello non sia in grado di risolvere/gestire la richiesta evidenziata all’interno del caso, potrà procedere con l’inoltro agli operatori di secondo livello.
Gli utenti assegnati al secondo livello, a differenza del primo livello, saranno divisi verticalmente
sulle casistiche di propria competenza (es. Richieste evolutive, bug di sistema, etc.).
L’implementazione di un sistema di ticketing di questa tipologia dovrà consentire di:
• Ridurre i tempi di lavorazione. Ogni singolo ticket sarà assegnato alla coda specifica di operatori preposti, i quali saranno responsabili di ogni singola lavorazione non evasa.
• Individuazione veloce della possibile risoluzione. L’aggregazione di ticket in tipologie aiuterà gli operatori ad individuare la soluzione in tempi nettamente inferiori.
• Minore dispersione delle informazioni. Tutte le comunicazioni di un cliente saranno aggregate all’interno di un’unica vista, di conseguenza qualsiasi operatore sarà in grado di lavorare la stessa pratica accedendo velocemente e facilmente a tutto lo storico di messaggi/richieste scambiate. Ciò contribuirà ad aumentare sensibilmente l’efficienza interna e percepita esternamente.
• Individuazione delle informazioni. Gli operatori non dovranno eseguire ricerca sul sistema per individuare le informazioni necessarie per risolvere il ticket, tutto l’insieme di dati necessari per la sua lavorazione (i campi specifici saranno diversi per ogni tipologia di ticket) saranno inseriti nel ticket tramite l’API Integration con il Case Management tool.
A supporto del sistema sopra citato, l’Appaltatore DOVRA’ realizzare un “Knowledge Management”, ovvero la creazione di articoli contenenti procedure (es. modifica iban da operatore della società di supporto) o risposte alle domande frequenti (es. quando viene
effettuato il pagamento delle fatture). Ogni singolo articolo creato dal “Knowledge Manager” (utente interno al perimetro della Regione Lazio responsabile della creazione, condivisione e aggiornamento degli articoli) andrà a costituire la Knowledge Base di gestione processi, best
practice e risposte a domande a disposizione di tutti gli utenti (interni ed esterni) che accedono all’ESIPA. Nello specifico, dovranno essere realizzate dall’Appaltatore due tipologie di articoli:
• Articoli dedicati agli utenti interni. Insieme di informazioni utili agli utenti interni al perimetro della Regione Lazio per supportarli nella loro operatività quotidiana. Gli articoli saranno inseriti in un’apposita sezione all’interno dei ticket;
• Articoli dedicati agli utenti esterni. Risposte alle domande più frequenti che vengono recapitate agli utenti interni (FAQ) da parte di AASS, Soggetti Erogatori e Fornitori di beni e servizi. Tali informazioni saranno configurate all’interno dell’ESIPA e rese disponibili sul portale web.
L’ESIPA dovrà garantire le seguenti funzionalità per il corretto funzionamento del Knowledge Management:
• Pubblicazione. Tutti gli articoli saranno racchiusi all’interno di uno specifico Tab di sistema accessibile dal Knowledge Manager al fine di poter consultare, modificare e creare nuovi articoli da pubblicare all’interno dell’ESIPA. In fase di pubblicazione dell’articolo il knowledge
manager specificherà anche se l’articolo è rivolto verso utenti interni o esterni;
• Ricerca. Tutti gli articoli pubblicati all’interno dell’ESIPA saranno reperibili grazie a funzionalità di ricerca aventi come “chiave” il titolo dell’articolo;
• Versioning. Il “Knowledge Manager” dovrà poter gestire il versioning degli articoli in modo da tracciare i relativi aggiornamenti;
• Composizione. Gli articoli saranno caratterizzati da una struttura standard, composta da un titolo, tag (es. fatture, contratti di budget, anagrafica, etc.) e un corpo (es. testo libero, immagine, tabella, etc.). Sarà, inoltre, garantita la possibilità di allegare file agli articoli creati.
7.1.1.2.2 Case Management tool
Il presente ambito funzionale riguarda l’implementazione di un Case Management tool per la gestione integrata delle comunicazioni tra utenti dell’ESIPA (fornitori, soggetti erogatori, struttura di supporto (backoffice/helpdesk), XX.XX. del SSR, Cessionari, etc) e per la definizione
dei Case relativi alle funzionalità “Core” dell’ESIPA (anagrafica utente, fatture, cessioni, budget, riconciliazione, pagamenti, disciplina uniforme, fatturazione attiva), che deve essere effettuata dall’Appaltatore in esecuzione del presente appalto.
Il Case Management tool deve consentire la gestione degli oggetti (e dei casi di dominio dell’ESIPA e delle relative pratiche, anche attraverso funzionalità di definizione di workflow.
I suddetti “casi”, relativi alle funzionalità “Core” dell’ESIPA (anagrafica utente, fatture, cessioni,
budget, riconciliazione, pagamenti, disciplina uniforme, fatturazione attiva) riguarderanno:
• la gestione della profilazione utenti in base ai ruoli associati e l’accesso al sistema;
• la creazione dinamica di oggetti e dei processi dell’attuale SIPA;
• la creazione di workflow dinamici mediante la funzionalità di Process Builder;
• la creazione di processi di approvazione (Approval Process) in logica BPM (Business Process Management)
• la creazione di “casi” (pratiche) associati agli oggetti e agli utenti del Sistema;
• la creazione e la visualizzazione dello stato di avanzamento e le notifiche di gestione del ticket;
• il monitoraggio e la tracciabilità di tutti gli eventi legati al Sistema;
• la gestione dei rilasci delle funzionalità utenti;
• la redazione della reportistica a supporto degli utenti per il monitoraggio costante del Sistema;
• l’integrazione con sistemi esterni.
7.1.1.2.2.1 Users e anagrafica
Ogni utente abilitato alla fruizione del Case Management tool deve possedere un Account, che funge da vera e propria anagrafica dell’utente (insieme di dati che definiscono il Fornitore / Soggetto Erogatore) e a cui devono essere associati tutti gli altri oggetti (tutti i record relativi ad altri oggetti che referenziano l’anagrafica). In questo modo sarà possibile concentrare in una sola schermata tutte le informazioni di un Account (anagrafica, casi correlati, verifiche Durc,
verifiche Equitalia, contratti di budget, fatture, etc.).
Il Sistema deve garantire un adeguato supporto ai processi di gestione utenti e gestione delle anagrafiche con tutti gli oggetti correlati attraverso le seguenti funzionalità:
• Gestione Utenti: ad ogni utente saranno attribuiti da parte degli utenti di back office un profilo e un ruolo. Ciascun profilo configurato sottenderà delle specifiche regole di visibilità in ragione del suo gruppo di appartenenza:
▪ per utenti afferenti al gruppo “Amministratori di Sistema – Utenti di back office”:
o creazione di un nuovo utente, mediante:
- selezione del gruppo di appartenenza;
- selezione del profilo utente;
- inserimento dei dati anagrafici dell’utente;
- attribuzione di una password di accesso all’ESIPA per l’utenza da generare;
- preview e salvataggio dei dati relativi alla nuova utenza creata.
o ricerca utenti attraverso “Username”, “Nome”, “Cognome”, “Codice fiscale”, “Gruppo di appartenenza”;
o modifica dei dati di dettaglio della propria utenza, preview e salvataggio dei dati modificati;
o modifica della password associata alla propria utenza.
▪ per utenti afferenti al gruppo “Fornitori”, sarà assegnata un’utenza nominale
dagli utenti di back office in base alla struttura specifica a cui fanno riferimento gli utenti e che consentirà loro di:
o visualizzare i propri dati anagrafici;
o modificare i propri dati anagrafici;
o effettuare una preview e salvare i dati anagrafici modificati;
o modificare la password associata alla propria utenza;
o visualizzare la documentazione di propria competenza.
▪ per utenti afferenti al gruppo “Altri Stakeholders dei Processi di Pagamento”:
o visualizzazione dei propri dati anagrafici;
o modifica dei propri dati anagrafici;
o preview e salvataggio dei dati anagrafici modificati;
o modifica della password associata alla propria utenza;
o visualizzazione della documentazione di propria competenza. Infine, il Case Management deve prevedere le seguenti funzionalità:
• La fruibilità agli utenti di tipo “Fornitore”, “Azienda Sanitaria”, “Utenze di Sistema e applicative” (utenti di tipo “Amministratore di Sistema – Utenti di back office” e “Amministratore di Sistema – Regione Lazio”) e “Altri stakeholders dei processi di pagamento” di una sezione contenente le risposte a FAQ, in modo da consentire la risoluzione autonoma di problematiche ricorrenti;
• L’emissione di richieste di apertura di un nuovo caso per utenti di tipo “Fornitore”, “Azienda Sanitaria”, “Utenze di Sistema e applicative” (utenti di tipo “Amministratori di sistema - Utenti di back office” e “Utenti di back office – Regione Lazio”) e “Altri stakeholders dei processi di pagamento”, qualora le FAQ non fossero sufficienti per la risoluzione autonoma della problematica;
• Il supporto agli utenti di tipo “Amministratore di Sistema – Utenti di back office” nella gestione dei casi mediante funzionalità dedicate all’individuazione della problematica, alla sua categorizzazione, all’assegnazione di un livello di priorità, al monitoraggio dello stato di avanzamento.
7.1.1.2.2.2 Creazione dinamica di oggetti
Il Case Management tool deve consentire la creazione dinamica di oggetti, come account e contatti, rappresentativi degli ambiti funzionali dell’attuale SIPA e di eventuali nuovi ambiti funzionali che saranno sviluppati in futuro.
Tale funzionalità prevede che l’amministratore di sistema definisca gli oggetti e le relative proprietà, come ad esempio campi personalizzati, relazioni con gli altri tipi di dati e oggetti (reference), layout di pagina e tab personalizzati.
Inoltre, il Sistema deve consentire di creare e associare i “casi” agli oggetti, in maniera tale da consentire una classificazione in base alla tipologia di oggetto.
7.1.1.2.2.3 Process Builder
Il Case Management tool deve prevedere la funzionalità di Process Builder per automatizzare i processi di business e limitare le operazioni manuali degli utenti. Il Sistema deve inoltre consentire agli utenti di tipo “Amministratore di sistema – Regione Lazio” e “Amministratore di
sistema – Utenti di back office” di implementare in autonomia nuove funzionalità e relativi
workflow.
Dovrà inoltre essere possibile configurare i suddetti workflow affinché possano essere inizializzati da eventi specifici, come ad esempio creazione/aggiornamento record, ricezione di uno specifico messaggio, invocazione da altri processi, etc.
Il Process Builder dovrà permettere quindi di modellare un processo definendone le proprietà, configurandone i trigger e i criteri e definendone le azioni da eseguire. A titolo esemplificativo, si riportano di seguito alcuni esempi di azioni attuabili automaticamente dal sistema:
• creazione di un record per ciascun oggetto definito;
• aggiornamento record;
• richiamare un processo;
• inviare una e-mail;
• inviare una notifica personalizzata.
7.1.1.2.2.4 Processi Approvativi (BPM)
Il Case Management tool deve prevedere la funzionalità di Approval Process che consente di creare un processo automatizzato di approvazione nell’ambito di procedure guidate. La pre- condizione per fruire della predetta funzionalità riguarda la definizione puntuale di specifici step
di approvazione. Deve inoltre essere possibile definire delle azioni automatiche da attuare al raggiungimento di determinati step di processo (invio inziale, approvazione finale, rifiuto, etc.), come ad esempio:
• assegnazione di un task ad uno specifico utente;
• invio e-mail a un destinatario designato utilizzando uno specifico template;
• modifica al valore di un campo selezionato, mediante inserimento manuale di un nuovo valore o calcolo automatico in base a una formula;
• invio di un outbound message a un destinatario designato.
Inoltre, l’Approval Process deve prevedere l’invio automatico di alert e notifiche sullo stato di
approvazione del processo. Gli alert automatici possono essere notifiche di approvazione o rifiuto, richieste di aggiornamento (laddove il responsabile dell'approvazione richieda che il mittente apporti modifiche all'invio originale) o notifiche di aggiornamento dello stato di approvazione di una procedura.
7.1.1.2.2.5 Creazione e visualizzazione stato avanzamento ticket
Il Case Management tool deve prevedere la funzionalità di creazione di un nuovo ticket (tramite integration API con Ticketing tool) che sarà contestualizzato dalle informazioni relative a:
• utente creatore del ticket;
• workflow in esecuzione al momento della creazione del ticket da parte dell’utente;
• dettagli informativi della problematica censiti dall’utente creatore del ticket.
Il ticket, una volta creato e salvato, sarà inoltrato mediante integration API al Ticketing System
che si occuperà della relativa gestione e risoluzione, come descritto nel paragrafo 7.1.1.2.1.
Inoltre, il Case Management tool deve consentire agli utenti di visualizzare, in un’apposita area del sistema, lo stato avanzamento e le notifiche di gestione dei ticket di propria competenza.
7.1.1.2.2.6 Audit applicativo
Il Case Management tool deve prevedere la funzionalità “Audit applicativo” per supportare gli utenti di tipo “Amministratori di sistema – Regione Lazio” e “Amministratori di sistema – Utenti di back office” nelle operazioni di tracciamento e monitoraggio dei log degli eventi legati al Sistema.
7.1.1.2.2.7 Funzionalità di scripting e User Interface per customizzazioni non complesse
Il Case Management tool deve prevedere “Funzionalità di scripting”, tramite linguaggio dedicato (es javasript, java o simili) che consentano l’introduzione di semplici funzionalità per la realizzazione di “logiche di business” (es: validazione campi con operatori logici, chiamate a
servizi REST e processamento delle risposte) o per la configurazione di processi e task per soddisfare dei requisiti funzionali di complessità non elevata.
Dove possibile, il sistema deve prevedere lo strumento di drag and drop che facilita l’interazione dell’utente per la realizzazione di business logics non complesse basate sul confronto tra proprietà di oggetti .
7.1.1.2.2.8 Gestione rilasci funzionalità utenti
Il Case Management tool dovrà consentire la gestione dei rilasci di nuove funzionalità utente mediante:
• la gestione del versioning del codice sviluppato;
• la distribuzione degli upgrade;
• la gestione automatica del passaggio fra gli ambienti software di test, collaudo e produzione.
Infine, il Sistema deve prevedere la funzionalità di rollback per consentire il ripristino delle versioni precedenti dei rilasci effettuati nel Sistema.
7.1.1.2.2.9 Content Management
Il Case Management tool deve prevedere la funzionalità di Content Management per la raccolta, la gestione e la pubblicazione delle informazioni. In particolare, gli utenti di back-office del Sistema, tramite tale funzionalità, potranno caricare nel Sistema documenti/comunicazioni (esempio nuove specifiche tracciato OPI, verifiche DURC, fatturazione SDI, etc.) sulla base di template predefiniti e rendere i suddetti documenti accessibili agli utenti abilitati.
7.1.1.2.2.10 Budgeting SSR - Case Management Tool
A titolo esemplificativo si riporta uno scenario di una possibile implementazione dei processi per la gestione dei contratti di budget attraverso il Case Management tool.
Si riportano nel seguito le funzionalità del Sistema a supporto del processo di Configurazione di un Contratto di Budget, con il dettaglio degli attori che potranno fruire delle suddette funzionalità in ragione del loro ruolo nel processo stesso:
• gli utenti di tipo “Amministratore di Sistema – Regione Lazio” avranno la possibilità di effettuare l’upload del modello annuale di Contratto di Budget sul Sistema;
• a valle dell’upload del nuovo modello di Contratto di Budget, il Sistema invierà automaticamente una notifica agli utenti di tipo “Amministratori di sistema - Utenti di back office”, per informarli della presenza di un nuovo template da generare;
• il Sistema consentirà la creazione di un nuovo template del documento “Contratto di
Budget”, mediante l’inserimento dei seguenti campi:
▪ durata del contratto (inserita dalla ASL nella fase di creazione di un nuovo Contratto di
Budget e visualizzata in fase di immissione di fattura da parte del Soggetto Erogatore);
▪ descrizione breve es: “Ospedali Classificati 2019 XXX 0XX” (inserita dalla ASL nella fase di “creazione” di un nuovo Contratto di Budget);
▪ il file “template” del modello contenente i contenuti statici del contratto di budget
oggetto del processo di firma.
• il Sistema supporterà l’editing del nuovo template di Contratto di Budget, permettendo agli utenti di tipo “Amministratori di sistema - Utenti di back office” di definire gli elementi statici
e dinamici del modello, di modificare gli elementi statici (es. testo paragrafo, formato e stile dei caratteri) e inserire gli identificativi delle variabili di contesto che verranno valorizzate al momento della creazione del contratto estraendo i valori dal database. Le variabili di contesto coincidono con gli attuali “dati di budget e prestazioni” caricati sull’ESIPA e
visualizzabili in “Lista Caricamenti Budget”:
▪ %AnagraficaASL%;
▪ %AnagraficaSoggettoErogatore%;
▪ %AnagraficaPresidioSoggettoErogatore%;
▪ %PrestazioneSanitaria%;
▪ %ProvvedimentoAmministrativoDiAccreditamento%;
▪ %ElencoPrestazioniAFinanziamento%;
▪ %ElencoPrestazioniARimborso%;
▪ %DurataContratto%;
▪ %ElencoValorizzazionePrestazioniPerProvvedimentoAmministrativo%;
▪ %ValoreComplessivoCalcolato%.
• l’utente “Amministratori di sistema - Utenti di back office”, dovrà poter salvare lo stato dell’editing del template del Contratto di Budget, visualizzare il template generato e inserire valori nelle parti dinamiche dello stesso in modo da verificare la correttezza dell’output generato;
• il Sistema invierà una notifica di “creazione di un nuovo template di Contratto di Budget” agli utenti di tipo “Amministratore di Sistema – Regione Lazio”, in modo che tali utenti possano verificare la conformità dello stesso;
• qualora il template risulti conforme, gli utenti di tipo “Amministratore di Sistema – Regione Lazio” ne effettueranno la pubblicazione sul Sistema;
• qualora il template non risulti conforme, gli utenti di tipo “Amministratore di Sistema – Regione Lazio” potranno descrivere in un apposito campo di testo esposto sull’interfaccia grafica del Sistema le ragioni di non conformità del template;
• in seguito al popolamento della maschera di descrizione delle ragioni di non conformità del template, il Sistema invierà automaticamente agli utenti di tipo “Amministratori di sistema - Utenti di back office” una notifica di non conformità;
• in ragione di quanto riportato nella notifica di non conformità, gli utenti di tipo “Amministratori di sistema - Utenti di back office” procederanno con la riconfigurazione del template, eventualmente ridefinendone gli elementi statici e dinamici;
• a valle della riconfigurazione del template, gli utenti di tipo “Amministratori di sistema - Utenti di back office” effettueranno il salvataggio dello stato di editing del template e il Sistema notificherà la creazione del nuovo template agli utenti di tipo “Amministratore di Sistema – Regione Lazio” in modo da avviare le procedure di verifica della conformità del template;
• qualora il template risulti conforme, gli utenti di tipo “Amministratore di Sistema – Regione Lazio” ne effettueranno la pubblicazione sul Sistema, altrimenti sarà nuovamente inizializzato il loop di notifica alla struttura di supporto, riconfigurazione, salvataggio del
template, verifiche di conformità dello stesso.
Le funzionalità precedentemente descritte e relative alla creazione di un template di Contratto di Budget dovranno consentire il superamento delle criticità attualmente presenti nell’ESIPA e dovute alla necessità di consegna di un modello di contratto al team di sviluppo incaricato dell’esecuzione delle necessarie attività di digitalizzazione e gestione informatica del contratto. Infine, il Sistema dovrà supportare i processi di definizione del tetto massimo del budget
annuale disponibile alle XX.XX. del SSR del Lazio e di attribuzione del suddetto budget ai vari soggetti erogatori mediante l’erogazione delle seguenti funzionalità:
• Assistenza Territoriale e Specialistica:
▪ gli utenti di tipo “Amministratore di Sistema – Regione Lazio” potranno effettuare il
caricamento sul Sistema del Decreto/Delibera contenete il budget totale a disposizione di ciascuna Azienda Sanitaria per l'assistenza Territoriale e Specialistica;
▪ il Sistema invierà automaticamente notifica di caricamento del Decreto/Delibera;
▪ l'Azienda Sanitaria usufruirà del Sistema per ripartire il budget totale a disposizione sui Soggetti Erogatori di propria competenza;
▪ l'Azienda Sanitaria effettuerà l’upload della delibera del budget e di un file allegato con
ulteriori informazioni necessarie, messi a disposizione di ciascun Soggetto Erogatore sul Sistema;
▪ gli utenti di tipo “Amministratore di Sistema – Regione Lazio” ricevono una notifica di caricamento della delibera;
▪ gli utenti di tipo “Amministratore di Sistema – Regione Lazio” effettuano la verifica dei codici utenti e dei dati relativi all’anagrafica dei presidi (codici NSIS e codici SIAS) dei Soggetti Erogatori;
▪ nel caso in cui siano necessarie delle modifiche all'allocazione del budget, l'Azienda Sanitaria lo modifica autonomamente sul singolo Soggetto Erogatore attraverso apposite maschere del Sistema.
• Assistenza Ospedaliera:
▪ l’utente di tipo “Amministratore di Sistema - Regione Lazio” carica sul Sistema il
Decreto/Delibera contenete il budget assegnato alle singole Strutture che erogano Assistenza Ospedaliera;
▪ l'Azienda Sanitaria riceve una notifica generata automaticamente di caricamento del Decreto/Delibera;
Le funzionalità precedentemente descritte dovranno consentire la generazione di un nuovo Contratto di Budget risolvendo le criticità attuali relative alla gestione extra sistema delle operazioni di definizione del tetto massimo del budget annuale e di ripartizione dello stesso fra Soggetti Erogatori, pervenendo comunque al tracciamento puntuale delle informazioni qualificanti il Contratto di Budget stesso.
Figura 15 - Funzionalità creazione nuovo template e sottoscrizione Contratto di Budget
Le attuali funzionalità a supporto del processo di firma del contratto di budget sono sufficienti a garantire la digitalizzazione di un contratto nel rispetto dell’attuale legislazione attraverso la generazione di un contratto in formato digitale (file PDF/A) e l’applicazione della firma
elettronica da parte dell’Azienda Sanitaria e del Soggetto Erogatore. Tuttavia, non sono
presenti funzionalità per il monitoraggio dell’erosione del finanziamento (budget) massimo erogabile per tutte le tipologie di prestazioni sanitarie. Per colmare il gap precedentemente descritto, il Sistema dovrà erogare le seguenti funzionalità di monitoraggio dell’erosione del Budget:
• attribuzione del Budget Provvisorio
▪ l’utente “Amministratore di Sistema - Struttura di Supporto” attribuirà a ogni presidio un budget provvisorio che, in prima istanza, potrà essere definito da una struttura dati del tipo: “Competenza”, “Durata”, “Lista delle tipologie di prestazioni abilitate in
fatturazione”, “Anno”, “Mese di competenza” e “Importo” per ogni tipologia di
prestazione.
▪ in fase di immissione di una fattura l’utente “Soggetto Erogatore con Contratto di Budget” selezionerà il budget provvisorio assegnatogli e il Sistema registrerà nel budget provvisorio l’importo fatturato.
• firma contratto e Budget Definitivo
▪ la firma del Contratto di Budget dovrà farà diventare definitivo il budget provvisorio non alterando la naturale esecuzione del processo di immissione delle fatture dei Soggetti Erogatori.
• monitoraggio erosione Budget
▪ le funzionalità del modulo di Reporting dovranno rendere fruibili agli utenti aventi profilo “Amministratori di Sistema - Struttura di Supporto” e “Amministratori di
Sistema - Regione Lazio” dei report specifici e un cruscotto per il monitoraggio
dell’erosione del budget.
Figura 16 - Funzionalità Budget Provvisorio e Monitoraggio
7.1.1.2.2.11 Fatture/Cessioni – Case Management Tool
In riferimento al Case Management tool, l’Appaltatore dovrà realizzare funzionalità e processi di “Gestione fatturePA” e di “Gestione delle Cessioni” che l’ESIPA dovrà erogare agli utenti afferenti i gruppi “Fornitore”, “Azienda Sanitaria”, “Utenti di Sistema” e “Altri Stakeholders dei processi di pagamento”. Si precisa che, nell’ambito dei suddetti processi, si dovrà eliminare la dicotomia attualmente esistente fra fatturePA e fatture regionali all’interno dell’ESIPA: l’unica entità di tipo “Fattura” gestita dal Sistema dovrà essere quella relativa alle fatturePA.
Si riporta nel seguito una descrizione delle funzionalità afferenti la “Gestione fatturePA” che dovranno essere erogate dal Sistema:
• per utenti di tipo “Soggetto Erogatore con Contratto di Budget”:
▪ dopo aver effettuato l’accesso al Sistema il Soggetto Erogatore potrà selezionare il presidio (qualora il Soggetto Erogatore abbia censito più di un proprio presidio);
▪ dopo aver selezionato il presidio il Soggetto Erogatore potrà selezionare un Contratto di Budget, tra quelli sottoscritti per quel presidio, su cui immettere la FatturaPA (qualora il Soggetto Erogatore sia titolare di più di un Contratto di Budget);
▪ nel caso in cui il budget relativo al contratto selezionato sia esaurito, il Soggetto Erogatore potrà usufruire di un contratto provvisorio per il proprio processo di fatturazione (si veda paragrafo 7.3.2.2.10, Budgeting SSR);
▪ il Soggetto Erogatore avrà a disposizione delle maschere di compilazione nelle quali inserire i dati relativi alla fattura;
▪ l’inserimento dei dati relativi alle prestazioni erogate a corredo della fattura potrà avvenire attraverso una fra le seguenti modalità:
o inserimento manuale da parte del Soggetto Erogatore delle prestazioni per le quali ha sottoscritto un Contratto di Budget;
o inserimento automatico attraverso la System Integration con i sistemi informativi SIO, SIAS, SIAT (in base alla tipologia di prestazione erogata), laddove disponibili.
▪ preview dei dati di dettaglio relativi alla fattura e modifica degli stessi (qualora necessario);
▪ salvataggio della FatturaPA generata seguendo gli step precedentemente descritti;
▪ visualizzazione delle fatturePA di propria competenza;
▪ visualizzazione del log degli eventi (immissione fattura, invio a SDI, ricezione Azienda Sanitaria etc) delle fatturePA
• per utenti di tipo “Fornitore di Beni e Servizi”:
▪ nel caso in cui il Fornitore immetta una FatturaPA sul Sistema, effettuerà la compilazione dei campi di dettaglio della FatturaPA sulle relative maschere, indicando inoltre l’Accordo Pagamenti/Disciplina Uniforme di riferimento;
▪ nel caso in cui il Fornitore invii la FatturaPA direttamente allo SDI, riceverà una notifica dal Sistema al momento della presa in carico della fattura dallo SDI. Inoltre, il Sistema assocerà automaticamente la FatturaPA all’Accordo Pagamenti/Disciplina Uniforme di
riferimento: qualora si verifichi un errore nella suddetta associazione, il Sistema genererà
automaticamente un Case;
▪ preview dei dati di dettaglio relativi alla fattura e modifica degli stessi (qualora necessario);
▪ salvataggio della FatturaPA generata seguendo gli step precedentemente descritti;
▪ visualizzazione delle fatturePA di propria competenza;
▪ visualizzazione del log degli eventi delle fatturePA di propria competenza.
Si riporta nel seguito una descrizione delle funzionalità afferenti la “Gestione delle Cessioni” che dovranno essere erogate dal Sistema:
• per utenti afferenti il gruppo “Fornitori”:
▪ creazione di una nuova Cessione mediante la sezione dedicata del Sistema;
▪ inserimento dei dati relativi alla cessione nelle apposite maschere esposte dal Sistema;
▪ upload del file pdf relativo alla Cessione sul Sistema;
▪ notifica dell’upload del file pdf relativo alla Cessione;
▪ ricezione di una notifica di cambio di stato della Cessione;
▪ visualizzazione del log degli eventi delle Cessioni di propria competenza.
• per gli utenti afferenti il Gruppo “Azienda Sanitaria”:
▪ ricezione di una notifica di upload di un documento di Cessione (effettuata da un utente di tipo “Fornitore”);
▪ upload sul Sistema di un file comprovante lo stato di adesione alla Cessione;
▪ ricezione di una notifica di cambio di stato della Cessione.
• per utenti afferenti il gruppo “Cessionari”:
▪ notifica dell’upload del file pdf relativo alla Cessione (effettuato da un utente di tipo “Fornitore”);
▪ ricezione di una notifica di cambio di stato della Cessione.
▪ associazione delle fatture all’atto di Cessione attraverso il Sistema;
▪ visualizzazione del log degli eventi di una Cessione.
• per gli utenti afferenti i gruppi “Amministratori di sistema - Utenti di back office” e “Amministratore di Sistema – Regione Lazio”:
▪ visualizzazione log degli eventi delle Cessioni;
▪ ricerca Cessioni e visualizzazione dati di dettaglio di una Cessione;
▪ eliminazione di una Cessione;
▪ download file pdf relativo alle Cessioni.
Il Sistema, inoltre, dovrà esporre tutti i dati relativi alle fatture e cessioni immagazzinate al suo interno verso le XX.XX. per mezzo dell’apposito micro servizio di integrazione “Stato Fattura /
Pagamenti”.
7.1.1.2.2.11.1 Invio fatturaPA verso SDI (SDICoop)
Per i Fornitori che immettono una FatturaPA sul Sistema, quest’ultimo deve inviare la fatturaPA a SDI tramite il servizio SDICoop Trasmissione che è realizzato tramite due endpoint:
• SDIRiceviFile: esposto dal SDI, si occupa della ricezione dei file inviati dal trasmittente;
• TrasmissioneFatture: esposto dal trasmittente, si occupa della ricezione dei messaggi inviati dallo SDI.
L’endpoint SDIRiceviFile è esposto dal Sistema di Interscambio e prevede il solo webservice RiceviFile, come mostrato in figura.
Figura 17 – Endpoint SDIRiceviFile
Mentre l’endpoint TrasmissioneFatture (Figura 20), esposto dal trasmittente, prevede i seguenti webservice con i quali SDI invia le notifiche seguenti:
• notifica di decorrenza termini: è la comunicazione che il SDI invia sia al trasmittente che al destinatario trascorsi 15 giorni senza aver ricevuto notifica di esito committente;
• notifica di esito: è la comunicazione, che lo SDI inoltra al trasmittente, contenente l’esito esplicitato dal destinatario nella notifica di esito committente;
• notifica di file non recapitabile: è la comunicazione, che lo SDI inoltra al trasmittente, per segnalare la definitiva impossibilità di recapitare al destinatario il file fatturaPA;
• notifica di mancata consegna: è la comunicazione che lo SDI invia al trasmittente per segnalare la temporanea impossibilità di recapitare al destinatario il file fatturaPA;
• notifica di scarto: è la comunicazione che lo SDI invia al trasmittente nel caso in cui il file trasmesso (file fatturaPA ovvero file archivio) non abbia superato i controlli previsti;
• ricevuta di consegna: comunicazione che lo SDI invia al trasmittente per certificare l’avvenuta consegna al destinatario del file fattura, sia per il flusso verso la PA sia per il flusso B2B. È importante precisare che i tracciati di tali ricevute sono differenti fra loro
ed hanno un preciso schema da rispettare;
• ricevuta di scarto: è la comunicazione che lo SDI invia al trasmittente nel caso in cui il file trasmesso non abbia superato i controlli previsti;
• ricevuta impossibilità di recapito: è la comunicazione che lo SDI invia al trasmittente per segnalare il mancato recapito al destinatario del file fattura e la messa a disposizione nell’area riservata dello stesso.
Figura 18 – Endpoint TrasmissioneFatture
Quindi l’invio di una fatturaPA dal sistema pagamenti a SDI deve prevedere i passi illustrati nella figura seguente:
Figura 19 -Flussi invio di una fatturaPA
7.1.1.2.2.11.2 Ricezione fatturaPA da SDI (SDICoop)
Il Sistema deve prevedere inoltre la ricezione della fatturaPA da SDI tramite il servizio SDICoop Ricezione, che permette di interagire con il Sistema di Interscambio nel ruolo di destinatario. In particolare, tale servizio deve consentire al Sistema di:
• ricevere dallo SDI un file fatturaPA;
• inviare allo SDI le notifiche di esito committente relative ad ogni file fatturaPA contenuta nei file ricevuti;
• ricevere l’eventuale scarto esito committente.
In particolare, il Servizio SDICoop – Ricezione è costituito da due endpoint:
• RicezioneFatture: esposto dal destinatario, si occupa della ricezione dei file fattura inviati dallo SDI secondo i diversi formati di trasmissione (FPR12, FPA12, FSM10) e della ricezione da parte della notifica di decorrenza termini;
Figura 20 – Servizio RicezioneFatture
• SDIRiceviNotifica: esposto dal SDI per i soli file fatturaPA, si occupa di ricevere la notifica di esito committente e di restituire l’eventuale scarto esito committente.
Figura 21 – Servizio SDIRiceviNotifica
L’invio della fatturaPA da SDI all’ESIPA si può riassumere nei passi riportati nella figura seguente:
Figura 22 – Flusso invio della fatturaPA da SDI al SIPA
7.1.1.2.2.12 Integrazione con altri ambiti funzionali
Il Case Management tool si deve integrare, senza soluzione di continuità (seamlessly), con gli altri moduli del nuovo ESIPA tra cui:
• modulo di Identity Access Management attraverso connettori custom basati sugli standard indicati da LAZIOcrea;
• modulo MOR;
• modulo MOR Report;
• modulo Verifica Pagamenti;
• modulo mandati di pagamento regionali del SSR;
• modulo profilazione;
• modulo intermediazione fatturazione SDI (Integration SDI);
• modulo di riconciliazione fatture (Business Rules-Riconciliazione/Verifiche Dati);
• Modulo intermediazione pagamenti verso SIOPE+;
• Ticketing System;
• Modulo File/Repository.
La system integration con tali moduli è prevista utilizzando interfacce API basate su standard aperti (es: OpenId, REST-WS) per consentire il recupero di determinate informazioni e dati necessari al corretto funzionamento del Sistema.
7.1.1.2.2.13 Xxxxxxx e Pratiche– Case Management tool
A titolo esemplificativo e non esaustivo, nel presente paragrafo sono descritti gli oggetti e i casi che devono essere gestiti dal Case Management tool nell’ambito del dominio dell’ESIPA. Oggetti di interesse del Case Management tool:
• Account che comprende l’anagrafica vera e propria, ovvero l’insieme di dati che definiscono il Fornitore / Soggetto Erogatore e la gestione degli utenti che assegna automaticamente o manualmente un profilo in base alla tipologia di utenza. La tabella riportata nel seguito descrive le tipologie di utenza:
Tipo Utente | Descrizione |
Amministratori di sistema - Utenti di back office | Utenti regionali che hanno la possibilità di visualizzare i dati delle fatture, ordini, pagamenti emessi da Fornitori e XX.XX. per svolgere attività di monitoraggio e di verifica propedeutiche all’esecuzione dei pagamenti da parte delle XX.XX. del SSR |
Amministratori di sistema – Regione Lazio | Utenti regionali che hanno la possibilità di creare nuovi utenti, ricercare utenti, modificare i propri dati di dettaglio e visualizzare i dati delle fatture, ordini, pagamenti emessi da Fornitori e XX.XX. |
XX.XX. del SSR | XX.XX. locali, Aziende Ospedaliere, Aziende Ospedaliere Universitarie, IRCCS pubblici, l’Azienda ARES 118 e della Fondazione Policlinico Tor Vergata |
Fornitori di beni e servizi senza contratto di budget | Soggetti aderenti alla Disciplina Uniforme relativa alle modalità di fatturazione e pagamento dei crediti vantati verso le XX.XX. del SSR che forniscono beni o prestano servizi in favore delle XX.XX. |
Fornitori di beni e servizi senza contratto di budget (Farmacie) | Soggetti aderenti alla Disciplina Uniforme relativa alle modalità di fatturazione e pagamento dei crediti vantati verso le XX.XX. del SSR che forniscono beni (farmaci) o prestano servizi in favore delle XX.XX. |
Soggetti erogatori con contratto di budget (Assistenza ospedaliera e territoriale) | Strutture erogatrici di servizi di assistenza ospedaliera e territoriale aderenti alla Disciplina Uniforme relativa alle modalità di fatturazione e pagamento dei crediti vantati verso le XX.XX. del SSR che intrattengono rapporti con le Aziende stesse sulla base di specifici accordi o contratti |
Soggetti erogatori con contratto di budget (Assistenza | Strutture erogatrici di servizi di assistenza specialistica e ambulatoriale aderenti alla Disciplina Uniforme relativa alle modalità di fatturazione e pagamento dei |
specialistica e ambulatoriale) | crediti vantati verso le XX.XX. del SSR che intrattengono rapporti con le XX.XX. sulla base di specifici accordi o contratti |
Ospedali Classificati, Policlinici Universitari non statali e I.R.C.C.S. privati | Strutture ospedaliere pubbliche e private aderenti alla Disciplina Uniforme relativa alle modalità di fatturazione e pagamento dei crediti vantati verso le XX.XX. del SSR che intrattengono rapporti con le XX.XX. sulla base di specifici accordi o contratti |
Service | Utenti delegati alla gestione delle fatture di uno o più fornitori e soggetti erogatori |
Cessionari | Cessionari dei crediti commerciali derivanti da un contratto di fornitura che devono accettare espressamente e integralmente nell’Atto di Cessione i termini e le condizioni della Disciplina Uniforme per le modalità di fatturazione e pagamento |
Enti Previdenziali Cessionari (INPS, INAIL,) | Enti previdenziali al quale un fornitore di beni e servizi o un soggetto erogatore può cedere gli introiti derivanti dai crediti commerciali associati ai propri contratti di fornitura, per esempio per adempiere a un debito contratto con gli Enti previdenziali stessi |
Tabella 2 - Tipologia utente per l'oggetto Account
• Contatto che comprende tutti i contatti (per esempio rappresentante legale, direttore generale, etc.) relativi agli utenti definiti nell’oggetto “Account”;
• Fattura che comprende la gestione di tutte le fatture passive e attive (anche note di credito e di debito) che sono immesse dalle seguenti due tipologie di utenti:
▪ Fornitori di beni e servizi soggetti erogatori senza Contratto di Budget;
▪ Soggetti erogatori con Contratto di Budget.
• Contratto che comprende la gestione di tutte le categorie di contratto stipulate dagli utenti appartenenti al gruppo dei “Fornitori”, di cui si riporta una descrizione nella seguente tabella:
Tipo Contratto | Descrizione |
Contratto di Budget | Il Contratto di Budget è il contratto firmato tra XX.XX. e Xxxxxxxx erogatori di Prestazioni con onere a carico del SSR ad eccezione delle prestazioni eseguite nei multi- |
presidi, riferendoci specificatamente ad alcune strutture che erogano prestazioni territoriali di riabilitazione ex art. 26 previa assegnazione di un unico budget su più presidi. | |
Disciplina uniforme | Ai sensi DEL U00308 DEL 3 Luglio 2015, le XX.XX., Aziende Ospedaliere, Policlinici Universitari Pubblici, IRCCS Pubblici e dell’Azienda ARES 118 hanno l’obbligo di applicare la “disciplina uniforme delle modalità di fatturazione e di pagamento“ includendola quale parte integrante di tutti i negozi giuridici insorti a far data dalla pubblicazione del provvedimento stesso (16/07/2015) e pertanto per i crediti derivanti da contratti insorti successivamente al 16/07/2015 e che includeranno al loro interno la suddetta disciplina. Tale contratto deve essere firmato dall’utente avente profilo Fornitori di Beni e Servizi e Strutture Erogatrici senza contratto di budget e sono previste due diverse modalità di gestione dei documenti contabili riferiti ai crediti vantati nei confronti delle XX.XX./Ospedaliere della Regione Lazio per la fornitura di beni e servizi sanitari: • “Adesione Disciplina Uniforme” (DCA 6/2018) valida per i crediti derivanti da contratti sorti prima del giorno 16/07/2015; • “Disciplina Uniforme delle modalità di fatturazione e di pagamento” (DCA 308/2015 e DCA 32/2017), valida per i crediti derivanti da negozi giuridici sorti a partire dal giorno 16/07/2015. |
Tabella 3 - Tipologia contratto
• Casi che il sistema dovrà gestire, elencati di seguito con una classificazione nelle fattispecie “Pratiche” e “Issue” e con evidenza dei relativi oggetti.
ID | Tipologia Caso | Caso | Oggetti coinvolti |
1 | Pratica | Registrazione Utente | - Account |
2 | Pratica | Recupera password | - Account |
3 | Pratica | Assegnazione Profilo ad Utente | - Account - Contatto |
4 | Pratica | Inserimento nuovo contatto | - Account - Contatto |
5 | Pratica | Aggiornamento contatto | - Account - Contatto |
6 | Pratica | Eliminazione contatto | - Account - Contatto |
7 | Pratica | Censimento presidi | - Account (Soggetti erogatori con Contratto di Budget) |
8 | Pratica | Sottoscrizione Contratto di Budget | - Account (Soggetti erogatori con Contratto di Budget, XX.XX.) - Contratto |
9 | Pratica | Aggiornamento Contratto di Budget | - Account (Soggetti erogatori con Contratto di Budget, XX.XX.) - Contratto |
10 | Pratica | Eliminazione contratto di budget | - Account (Soggetti erogatori con Contratto di Budget, XX.XX.) - Contratto |
11 | Pratica | Firma contratto di budget | - Account (Soggetti erogatori con Contratto di Budget, XX.XX.) - Contratto |
12 | Pratica | Adesione disciplina uniforma | - Account (Fornitore) - Contratto |
13 | Pratica | Firma file adesione disciplina uniforme | - Account (Fornitore) - Contratto |
14 | Pratica | Proroga disciplina uniforme | - Account (Fornitore) - Contratto |
15 | Pratica | Aggiunta nuovo codice IBAN | - Account (Fornitore) - Coordinate Bancarie |
16 | Pratica | Inserimento nuova Azienda Sanitaria | - Account (Fornitore) - Coordinate Bancarie |
17 | Pratica | Validazione IBAN per Azienda Sanitaria | - Account (Fornitore) - Coordinate Bancarie |
18 | Pratica | Sostituzione IBAN per Azienda Sanitaria | - Account (Fornitore) - Coordinate Bancarie |
19 | Pratica | Disabilitazione IBAN per Azienda Sanitaria | - Account (Fornitore) - Coordinate Bancarie |
20 | Pratica | Creazione di una nuova Cessione | - Account (Fornitori) - Cessione - Fattura |
21 | Pratica | Estensione validità di una Cessione | - Account (Fornitori) - Cessione - Fattura |
22 | Pratica | Gestione retrocessione | - Account (Fornitori) - Cessione - Fattura |
23 | Pratica | Immissione fattura attiva | - Fattura - Account (Soggetti erogatori con Contratto di Budget, ) |
24 | Pratica | Predisposizione file “In pagamento” e ricezione esito validazione | - Pagamento - Account (Amministratore di sistema) |
25 | Pratica | Predisposizione e invio file “Aggregato OPI” | - Pagamento - Account (Amministratore di sistema) |
26 | Pratica | Caricamento file “Pagato” e ricezione esito validazione | - Pagamento - Account (Amministratore di sistema) |
27 | Pratica | Verifica pagamenti | - Pagamento - Account (Amministratore di sistema) |
28 | Pratica | Verifica congruità dettaglio OPI con importo disponibile | - Pagamento - Fattura - Account (Azienda Sanitaria, Fornitore) |
29 | Pratica | Caricamento del modello annuale di Contratto di Budget | - Contratto - Account (Amministratore di sistema) |
30 | Pratica | Creazione di un nuovo template del documento Contratto di Budget | - Contratto - Account (Amministratore di sistema) |
31 | Pratica | Editing del nuovo template del documento Contratto di Budget | - Contratto - Account (Amministratore di sistema) |
32 | Pratica | Definizione del tetto massimo di budget annuale disponibile alle XX.XX. del SSR | - Contratto - Account (Amministratore di sistema, XX.XX.) |
33 | Pratica | Ripartizione del budget totale a disposizione sui Soggetti Erogatori di propria competenza dell’Azienda Sanitaria | - Contratto - Account (Amministratore di sistema, XX.XX., Soggetto erogatore) |
34 | Pratica | Monitoraggio erosione Budget | - Contratto - Account (Amministratore di sistema) |
35 | Pratica | Attribuzione del Budget provvisorio | - Contratto - Account (Amministratore di sistema) |
36 | Pratica | Eliminazione di una Cessione | - Account (Amministratori di sistema) - Cessione - Fattura |
37 | Pratica | Creazione nuovo controllo DURC | - Pagamento - Account (Amministratore di sistema) |
38 | Pratica | Creazione nuovo controllo verifiche Equitalia | - Pagamento - Account (Amministratore di sistema) |
39 | Pratica | Verifica DURC | - Pagamento - Account (Amministratore di sistema) |
40 | Pratica | Verifica Equitalia | - Pagamento - Account (Amministratore di sistema) |
41 | Pratica | Riconciliazione manuale delle singole fatture scartate a seguito della riconciliazione automatica dei flussi di liquidazione | - Fattura - Pagamento - Account (utenza regionale) |
42 | Issue | Problema con Firma Digitale | - Account (Fornitore) - Coordinate Bancarie - Fattura |