CAPITOLATO TECNICO PER IL RINNOVO DEI SERVIZI DI GESTIONE, ASSISTENZA, HELP DESK E MANUTENZIONE ORDINARIA, NORMATIVA,
CAPITOLATO TECNICO PER IL RINNOVO DEI SERVIZI DI GESTIONE, ASSISTENZA, HELP DESK E MANUTENZIONE ORDINARIA, NORMATIVA,
CORRETTIVA ED EVOLUTIVA DELLE PIATTAFORME CONTICKI E CUP 2.0
PREMESSA
Con DETERMINAZIONE DIRIGENZIALE N° 441 del 12/12/2013 di Estar (ex ESTAV
SudEst) avente ad oggetto: “AGGIUDICAZIONE PROCEDURA APERTA PER LA PROGETTAZIONE E SVILUPPO DI UN SISTEMA DI GESTIONE DEL PROCESSO PRESCRIZIONE-EROGAZIONE DI PRESTAZIONI SANITARIE NELL’AMBITO DEL
SISTEMA INFORMATIVO SANITARIO TOSCANO” è stata aggiudicata la fornitura della piattaforma regionale denominata Conticki alla RTI Engineering Ingegneria Informatica SpA con Postel SpA.
Con successiva DETERMINAZIONE DIRIGENZIALE N° 592 del 18/05/2016 di ESTAR avente ad oggetto: “SERVIZIO DI PROGETTAZIONE E SVILUPPO DEL SISTEMA DI GESTIONE DEL PROCESSO PRESCRIZIONE-EROGAZIONE DI PRESTAZIONI SANITARIE NELL'AMBITO DEL SISTEMA INFORMATIVO SANITARIO TOSCANO, DI CUI ALLA DETERMINAZIONE EX ESTAV SE N.441/2013. ESTENSIONE.” la piattaforma
regionale Conticki è stata estesa al fine di realizzare la piattaforma regionale CUP 2.0.
L’oggetto della fornitura è la stipula di una Convenzione della durata di 4 anni, rinnovabile per ulteriori 2 anni, per l’esecuzione di SERVIZI DI HELP DESK E MANUTENZIONE ORDINARIA, NORMATIVA, CORRETTIVA ED EVOLUTIVA DELLE
PIATTAFORME CONTICKI E CUP 2.0 acquisite con gli atti sopra elencati e i cui file sorgenti sono di proprietà della Stazione Appaltante.
I servizi si applicano a tutti gli ambienti attualmente presenti:
● Conticki: ambiente di test e ambiente di produzione
● CUP 2.0: ambiente di staging, ambiente di formazione, ambiente di produzione, ambiente di collaudo
Nel caso in cui Estar ritenesse opportuno generare ulteriori ambienti (fino ad un massimo di 4 per Conticki e 4 per CUP 2.0 salvo ambienti creati transitoriamente per la migrazione dei dati), l’Aggiudicatario è tenuto a includerli nel presente contratto senza oneri aggiuntivi.
La presente gara non prevede l’acquisizione di hardware, che sarà messo a disposizione da Estar.
Stante la pervasività dell’uso quotidiano dei sistemi oggetto di gara, l’ampia diffusione ad un numero importante di operatori, il livello di integrazioni con i sistemi informativi del SSR e l’alto impatto sui processi critici (es. dematerializzazione delle ricette, pagamento dei ticket, etc) non saranno ammesse soluzioni che prevedono la sostituzione di parti rilevanti del software in uso con altri software presenti sul mercato e/o a riuso.
Tutto il software sviluppato durante il periodo contrattuale rimane patrimonio di Estar, e il fornitore è tenuto, senza oneri aggiuntivi, a consegnare i file sorgenti e la documentazione aggiornati al termine del contratto con un dettaglio informativo minimo pari a quanto pubblicato in allegato al presente bando.
I file sorgenti allegati sono stati estratti durante i lavori del Collegio Tecnico, sono pertanto aggiornati a poche settimane antecedenti la pubblicazione del bando e sufficienti al mercato a garantire la partecipazione alla gara. Al momento della stipula del contratto
attuativo, sarà responsabilità di ESTAR consegnare all’Aggiudicatario i file sorgenti aggiornati all’atto dell’avvio del periodo di subentro (vedi rispettivo paragrafo).
LEGENDA
IRIS: è la piattaforma tecnologica regionale su cui convergono i pagamenti dei ticket a livello unico regionale e che è l’intermediario tecnologico per le integrazioni dei pagamenti con il livello nazionale PagoPA.
Conticki: è la piattaforma software regionale, installata al TIX, che informatizza il processo di prescrizione-erogazione di prestazioni sanitarie nell'ambito del sistema informativo sanitario toscano; è integrata con CUP 2.0, con tutti i CUP locali e con altri applicativi aziendali e svolge il ruolo di livello regionale di interoperabilità verso RT/MEF per le ricette elettroniche/dematerializzate e verso PagoPA.
CUP 2.0: è la piattaforma software regionale, installata al TIX, che estende la piattaforma Conticki aggiungendovi le funzionalità di gestione di offerta e prenotazione di prestazioni specialistiche ambulatoriali a livello regionale. E’ integrata con Conticki e con i CUP aziendali di II livello.
CUP II Livello: è la piattaforma software locale, installata presso i data center aziendali o presso il TIX, che gestisce il processo di accettazione-erogazione-pagamento delle prestazioni ambulatoriali di ciascuna azienda sanitaria. E’ integrata con Conticki e CUP 2.0 e con gli altri dipartimentali locali.
CONTESTO
La Regione Toscana, le XX.XX. ed ESTAR hanno completato da tempo il dispiegamento della piattaforma Conticki in tutte le realtà sanitarie e nell’anno 2016 hanno avviato un progetto denominato CUP 2.0 che prevede l’estensione del progetto Conticki a piattaforma centralizzata regionale per la gestione delle agende e per la registrazione delle prenotazioni di prestazioni ambulatoriali.
Il processo di accettazione, erogazione e pagamento è demandato ai CUP locali già in essere, divenuti quindi software CUP di II livello.
Il progetto CUP 2.0 è già stato avviato nelle seguenti Aziende Sanitarie:
● Lucca
● Massa
● Versilia
● Livorno
● Grosseto
● Siena
● AOU Senese
● Arezzo (previsto avvio entro il primo trimestre 2020)
ed è prevista a seguire la sua adozione in tutte le XX.XX. Toscane.
Si evidenzia che la ASL Toscana Centro (Firenze, Prato, Pistoia ed Empoli) intende procedere alla unificazione dei 4 software CUP di II Livello e che la fornitura è oggetto di un bando di gara aggiudicato con DETERMINAZIONE ESTAR N° 1256 del 10/09/2019 alla RTI Onit Group s.r.l. (mandataria)/Extra Red s.r.l. (mandante).
I software CUP di II livello in uso a novembre 2019 sono i seguenti:
● fornitore Ised per l’ex ASL Firenze
● fornitore GPI (exRF) per l’exASL Prato e Arezzo
● fornitore Xxxxxxx per l’exASL 3, AOU Careggi
● fornitore Xxxxxxx (exNoemalife) per AOU Meyer
● fornitore OSLO per l’exASL Empoli
● fornitore Engineering per l’exASL Lucca, Viareggio, Massa e Livorno
● fornitore ADS per l’exASL Pisa, Siena, grosseto, AOU Senese e AOU Pisana
● fornitore GPI (exInsielmercato) per FTGM
Nel corso dell’anno 2020 almeno gli impianti seguenti:
● fornitore Ised per l’ex ASL Firenze
● fornitore GPI (exRF) per l’exASL Prato
● fornitore Xxxxxxx per l’exASL 3
● fornitore OSLO per l’exASL Empoli
saranno progressivamente migrati al nuovo CUP II livello della ASL Toscana Centro, con un ordine di migrazione da concordare tra ASL, ESTAR e fornitore.
Si precisa che sono possibili ulteriori adesioni di altre XX.XX. al bando di gara suddetto.
Le piattaforme CONTICKI e CUP 2.0 si integrano con il progetto regionale ANAGRAFE e con la piattaforma IRIS che raccoglie tutte le posizioni debitorie della PA Toscana.
Di seguito, al fine della valutazione della complessità del progetto, si riportano i dati numerici inerenti CUP 2.0 e attualmente in possesso del Collegio Tecnico:
5.952
NR OPERATORI ATTIVI
PERIODO: GENNAIO-NOVEMBRE 2019 | VOLUMI DI ATTIVITÀ (prenotazioni/spostamenti/disdette) |
GROSSETO | 530.086 |
SIENA, avvio 3 GIU 19 | 208.818 |
LIVORNO | 919.618 |
XXXXX | 000.000 |
XXXXX | 621.788 |
VIAREGGIO | 413.347 |
AOUS, avvio 3 GIU 19 | 188.004 |
PERIODO: GENNAIO-SETTEMBRE 2019 | NR OPERATORI ATTIVI | NR MASSIMO OPERATORI CONTEMPORANEI | NR PRENOTAZIONI |
FIRENZE E ISPRO | 2.792 | 1.526 | 1.781.045 |
FTGM | 43 | 15 | 64.899 |
EMPOLI | 582 | 260 | 346.241 |
PRATO | 790 | 411 | 822.028 |
PISA E AOUP | - | - | 846.107 |
Al fine di comprendere il contesto tecnico e architetturale in cui si inquadra la presente gara, si riepilogano nel seguito i tratti salienti dei progetti CONTICKI, CUP 2.0 e IRIS.
PIATTAFORMA CONTICKI
Il progetto Conticki implementa la piattaforma di monitoraggio del processo prescrizione-erogazione supportando le aziende nel processo di organizzazione aziendale, attuando la dematerializzazione delle ricette specialistiche, centralizzando il calcolo unificato del ticket, predisponendo una conoscenza centralizzata dei pagamenti effettuati tramite i canali integrati con IRIS, esponendo un sistema di recupero crediti e sanzioni.
Conticki è il vero e proprio sistema di governo del ciclo prescrittivo che interagisce e comunica lo stato della prescrizione e i relativi eventi al sistema regionale SAR e di conseguenza al sistema centrale SAC.
Verticali CUP integrati con Conticki per la gestione dei dati di prescrizione (RFC 246):
● Massa
● Lucca
● Viareggio
● Livorno
● Pisa
● Firenze
● Prato
● Pistoia (tramite servizi in back office)
● Empoli
● Siena
● Arezzo
● Grosseto
● FTGM
● AOU Pisana
● AOU Careggi
● AOU Meyer
● AOU Senese
Oltre ai verticali CUP sono integrati con Conticki per la gestione dei dati di prescrizione (RFC 246) anche i software di laboratorio di analisi per le seguenti aziende:
● Massa
● Lucca
● Viareggio
● Pisa
● Firenze
● Prato
● Empoli
● AOU Careggi
● AOU Meyer
La piattaforma Conticki implementa e gestisce le seguenti RFC:
● RFC 244: Condivisione Agende
● RFC 245: Calcolo del Ticket
● RFC 246: Processo Prenotazione – Erogazione
● RFC 127: IRIS, gestione posizioni debitorie
● RFC 145: IRIS, gestione pagamenti
Conticki dispone di una console di ricerca e controllo dei messaggi transitati sull’infrastruttura come da manuale operativo riportato nell’allegato E “CONTICKI_SIM CONSOLE_MUT_1.1.pdf.”
PIATTAFORMA CUP 2.0
CUP 2.0 estende la piattaforma Conticki aggiungendo la gestione di offerta e prenotazione di prestazioni specialistiche ambulatoriali a livello regionale.
Utilizza le RFC 244 e 246, già realizzate per Conticki, per l’interoperabilità con i CUP locali, ai quali trasmette i dati di offerta e prenotazione. I CUP locali mantengono le funzioni di: accettazione, erogazione, incasso/pagamento, risposta ai debiti informativi verso RT e Ministero, integrazione con i dipartimentali, alimentazione dei datawarehouse locali ed eventuali ulteriori funzioni specifiche del singolo impianto.
La piattaforma offre interoperabilità a servizi per la consultazione delle disponibilità e per la gestione degli appuntamenti (prenotazione/modifica/disdetta). La principale applicazione di tale funzione è rappresentata oggi dal Portale di Prenotazione accessibile via WEB e TOTEM (xxxxx://xxxxxxx.xxxxxx.xxxxxxx.xx/) ma sono già operativi i primi esempi di integrazione con Cartelle Cliniche Ambulatoriali.
Il sistema presenta un modulo semplificato per l’erogazione dei servizi in farmacia (il cosiddetto CUP 2.0 ‘light’), comprensivo di una funzione di incasso analoga a quella in essere sui canali di pagamento automatico.
La base dati CUP 2.0 alimenta il sistema di Business Intelligence regionale su cui è in corso di implementazione il cruscotto direzionale per il governo delle liste d’attesa e dell’offerta di prestazioni specialistiche ambulatoriali.
Di seguito è riportato uno schema dell’infrastruttura CUP 2.0 comprensivo delle integrazioni in essere.
In estrema sintesi, il sistema utilizza le seguenti integrazioni:
● RFC 75 - Invio di SMS di conferma o promemoria appuntamento
● RFC 127* - Gestione delle posizioni debitorie verso IRIS
● RFC 145* - Acquisizione degli incassi da IRIS
● RFC 231 - Interazione con il SAR per gestione dati di Prescrizione
● RFC 244* - Trasmissione dei dati di offerta ai CUP locali
● RFC 245 - Calcolo Ticket Centralizzato
● RFC 246* - Trasmissione dei dati di prenotazione ai CUP locali
● RFC 249 - Integrazione con Istanza Anagrafica Unica Regionale
● Integrazione a servizi con dipartimentale ambulatoriale in uso c/o Siena e AOUS e portale regionale di prenotazione
*tramite Infrastruttura CAST
Per le RFC 244 e 246, strettamente legate alle funzioni offerte da CUP 2.0 (gestione offerta e prenotazione di prestazioni specialistiche ambulatoriali), è attivo un sistema di monitoraggio accessibile mediante profilo manager.
Ad oggi sono già migrate su piattaforma CUP 2.0 le seguenti realtà:
● Azienda USL TNO
○ Livorno
○ Lucca
○ Massa
○ Viareggio
● Azienda USL TSE
○ Arezzo (previsto avvio entro I TRIM 2020)
○ Grosseto
○ Siena
● AOUS
Di seguito una schematizzazione del processo in termini di coinvolgimento dei CUP di I e II livello sugli impianti migrati su infrastruttura CUP 2.0.
VISTE PER DWH REGIONALE
La base dati Conticki alimenta il sistema di Business Intelligence di livello regionale.
I dati storici sono esposti su viste materializzate su un db di replica analogo a quello di produzione. La profondità storica definita sulla base delle esigenze statistiche espresse dal Comitato Direttivo Regionale per ciascuna vista e potrà subire variazioni nel tempo.
I dati in linea sono esposti su viste materializzate aventi stessa struttura delle precedenti ma con profondità storica limitata alle esigenze di elaborazione dati in linea.
Per il dettaglio delle strutture dati, si rimanda all’allegato “ALLEGATI E - REQ SINC
-Conticki Strutture per DWH_100.pdf”.
L’attività di assistenza e manutenzione ordinaria e correttiva è da considerarsi inclusa nella fornitura del generico servizio di assistenza e manutenzione. L’attività di manutenzione evolutiva sarà erogata a consumo.
PORTALE, APP E SMS PER PRENOTAZIONI E DISDETTE PER I CITTADINI
Per gli impianti migrati a piattaforma CUP 2.0 è disponibile un servizio di prenotazione e disdetta tramite portale regionale (xxxxx://xxxxxxx.xxxxxx.xxxxxxx.xx/). E’ in corso di sviluppo il dispiegamento della funzione su APP SmartSST.
Il servizio consente di prenotare o disdire una prestazione sanitaria mediante utilizzo di:
● Codice Fiscale
● Numero Ricetta Elettronica (NRE), riportato sul promemoria di ricetta medica elettronica ovverosia ricetta dematerializzata su foglio bianco
Le prestazioni oggetto di prenotazione sono state identificate dal Comitato Direttivo Regionale e potranno subire variazioni nel tempo (vedi xxxxx://xxxxxxx.xxxxxx.xxxxxxx.xx/xxxxxxxxx/00000/0/xxxxxx_xxxxxxxxxxx.xxx/0x000x00-00x 5-48ce-a4b8-c0f802a3384c).
Le disdette sono invece applicabili a tutte le prestazioni, purché prescritte su ricetta dematerializzata.
Alla data di stesura di presente bando è in imminente attivazione la funzione di integrazione a servizi tra la APP regionale SmartSST e CUP 2.0.
Il cittadino può disdire una prenotazione effettuata (anche tramite call center) in 2 modalità: tramite il portale e breve anche tramite la APP SmartSST.
E’ attivo un servizio di remind/conferma delle prenotazioni tramite SMS; per realizzarlo il sistema CUP 2.0 è stato integrato con un servizio regionale di invio dei messaggi tramite la RFC 75 e tale integrazioni rientra negli ambiti del presente bando.
Si precisa che la manutenzione e l’assistenza del portale regionale di prenotazione al cittadino rimane in carico ai contratti di Regione Toscana e non è oggetto del presente
bando, mentre rientra nei servizi inclusi in questo bando la manutenzione e l’assistenza dei WebService esposti da CUP 2.0 per i servizi di prenotazione da parte di applicazioni terze, siano esse software in uso agli operatori sanitari, siano essi i servizi invocati dalla APP regionale SMARTSST.
PIATTAFORMA IRIS E INFRASTRUTTURA REGIONALE PAGAMENTI
La piattaforma Conticki gestisce anche l’integrazione con IRIS ed interessa tutte le Aziende Sanitarie nell’ambito della gestione del processo di prenotazione, erogazione e pagamento delle prestazioni sanitarie. Alla data di stesura del presente capitolato tutte le AASS toscane sono già in produzione con l’integrazione Conticki-IRIS tranne: AOU Careggi, AOU Meyer, ex ASL Pistoia che saranno attivate in produzione tra la fine del 2019 e il 2020.
Il modello prevede che il DB pagamenti/posizioni debitorie sia centralizzato e che i diversi canali di pagamento si interfaccino con IRIS per leggere le posizioni debitorie e comunicare i pagamenti, come per esempio il modulo cassa CUP 2.0 delle farmacie.
IRIS aderisce a PagoPA quindi tutte le posizioni debitorie da esso gestite sono “pagabili” tramite tutti i canali di pagamento afferenti a PagoPA, per esempio sportelli postali, lottomatica, etc.
Nell’architettura scelta dalla sanità toscana il verticale CUP è l’unico sistema informativo incaricato all’apertura, gestione e chiusura delle posizioni debitorie ad IRIS.
Pertanto per garantire la presenza di tutte le posizioni debitorie sanitarie ogni altro sistema informativo viene integrato con il CUP tramite il progetto pre-conticki che prevede ad esempio l’integrazione dei verticali LIS o PS al CUP. Gli identificativi di pagamento (IUV-Identificativo Univoco di Versamento) delle prenotazioni effettuate da CUP 2.0 transitano a verticale CUP aziendale a cui è demandata l’apertura e gestione della relativa posizione debitoria ad IRIS.
Il progetto prevede l'invio delle posizioni debitorie a Conticki da parte dei CUP tramite l' RFC127; l'infrastruttura invia tramite CAST/CART le posizioni a IRIS. I pagamenti effettuati su IRIS tramite i canali esposti vengono comunicati tramite l' RFC145 al CUP.
Fig. 2 - Iris
E’ in fase di attivazione la nuova fornitura di livello regionale per i sistemi di accoglienza e pagamento delle prestazioni sanitarie che prevede il pagamento delle posizioni debitorie tramite infrastruttura IRIS, pertanto tutti i sistemi di pagamento quali totem, ATM, etc. saranno integrati con la piattaforma IRIS salvo il permanere di residuali situazioni di pagamenti spontanei, ovvero non abbinati a posizioni debitorie precostituite.
INFRASTRUTTURA TECNOLOGICA
L’infrastruttura da utilizzare per il software oggetto del presente capitolato viene messa a disposizione da ESTAR sia in termini di hardware che di licenze e manutenzione dei software (SO, RDBMS) che in termini di tecnologie di rete.
Nota: Trattandosi dunque di una architettura già in essere, nessuna licenza o canone di manutenzione e assistenza dei software di base (RBDMS, S.O., ecc.) è a carico dell’aggiudicatario, contrariamente a quanto riportato nel documento ALLEGATO Linee Guida Tecnologiche.
Tale infrastruttura è ampiamente documentata negli ALLEGATI F aggiornati a dicembre 2019; si precisa che nel corso del 2020 sono possibili cambiamenti sull’asset tecnologico conseguenti alle evoluzioni regionali previste al TIX, sarà quindi compito della stazione appaltante consegnare all’Aggiudicatario la documentazione aggiornata all’atto dell’avvio del contratto.
Ogni evoluzione e correzione che verrà realizzata per tutta la durata dell’appalto dovrà risultare compliant alle indicazioni contenute nell’ALLEGATO Linee Guida Tecnologiche.
Gli ambienti infrastrutturali attualmente presenti per Conticki sono i seguenti:
● ambiente di staging
● ambiente di produzione
per CUP 2.0:
● ambiente di staging
● ambiente di formazione
● ambiente di produzione
● ambiente di collaudo
Relativamente alle indicazioni specifiche tecniche relative alla connettività, si rimanda inoltre all’ALLEGATO InterSST Regole d’uso.
Si ritiene invece opportuno che all’interno dei servizi di assistenza e manutenzione a carico dell’Aggiudicatario siano compresi i servizi di DBA Oracle, dei quali viene chiesta esplicita valutazione sia tecnica che economica.
EVOLUZIONI INCLUSE NELLA FORNITURA
Oltre al servizio di help desk e manutenzione ordinaria, normativa e correttiva, il contratto prevede la realizzazione di manutenzione evolutiva sulle piattaforme oggetto del bando. In merito ad essa sono richieste due distinte modalità di erogazione:
A. Manutenzione evolutiva standard: da erogarsi a consumo mediante moduli MEV come da procedura ‘ALLEGATO B - PA 45 2018 REV02 SOFTWARE CHANGE REQUEST’ ed attingendo ad una previsione di giornate annuali inserita nella scheda offerta economica; si precisa che non vi è alcuna garanzia di acquisizione di queste evoluzioni;
B. Manutenzione evolutiva predefinita: da erogarsi attingendo ad un elenco di voci ben precise riportate nella scheda offerta economica; si precisa che non vi è alcuna garanzia di acquisizione di queste evoluzioni e che pertanto esse sono tutte da considerarsi ‘OPZIONALI’;
Tutte le integrazioni dovranno essere implementate nel rispetto di quanto indicato negli allegati tecnologici, applicando senza oneri aggiuntivi eventuali versioni aggiornate delle specifiche vigenti al momento della pubblicazione del bando.
I dettagli tecnici delle integrazioni devono essere oggetto dell’offerta tecnica in termini di soluzione proposta e secondo le modalità di integrazione rese necessarie sulla base dei fornitori dei servizi invocati.
I costi di help desk, assistenza e manutenzione delle integrazioni già in essere sono da considerarsi a carico dell’aggiudicatario e da conteggiarsi all’interno delle voci di assistenza ordinaria.
A quanto suddetto si aggiunge la richiesta di integrare i sistemi oggetto del bando con le modalità di autenticazione attualmente diffuse sul mercato e compliant con gli standard
tecnologici di Regione Toscana: il fornitore dovrà quindi prevedere, entro 60 giorni dalla stipula del contratto e senza oneri aggiuntivi, il passaggio alla modalità di autenticazione regionale facendo riferimento a quanto riportato sul sito Oscat (xxxxx://xxxxx.xxxx.xxxxxxx.xx/) e in attuazione a quanto contenuto nell’ “ALLEGATO F - RT Piattaforma Arpa.PDF”.
MODALITA’ DI PRESENTAZIONE DELLA DOCUMENTAZIONE TECNICA E DI COMPILAZIONE DELLA SCHEDA OFFERTA ECONOMICA IN MERITO ALLA TIPOLOGIA B: MANUTENZIONE EVOLUTIVA PREDEFINITA
Per tutto quanto concerne la manutenzione evolutiva già oggi prevista/prevedibile sulle piattaforme Conticki e CUP 2.0, nel seguito viene prodotto un elenco di richieste (codificate con la tipologia EV*) per ciascuna delle quali i partecipanti dovranno produrre uno o più documenti di offerta tecnico/funzionale tra i quali devono essere esposti chiaramente i riferimenti ai file sorgenti che - per ciascuna evoluzione - il fornitore propone di modificare.
Il materiale prodotto sarà oggetto di:
● valutazione della proposta tecnico/funzionale nella griglia punteggi
● valutazione della proposta economica nella relativa scheda offerta
Si precisa che le seguenti manutenzioni evolutive devono essere eseguite sui file sorgenti oggetto del presente bando in modo da garantire che il software finale per l’utilizzatore sia unico e invariante rispetto a quello attualmente in uso e che non saranno ammesse soluzioni che prevedono l’introduzione di differenti software rispetto a quelli oggetto del bando.
Per tutta la durata dell’appalto e con cadenza semestrale, l’Aggiudicatario è tenuto alla consegna ad ESTAR (RES e DEC) di tutta la documentazione aggiornata del progetto e del software, al livello qualitativo minimo pari a quanto allegato al presente bando.
Si precisa inoltre che l’acquisto di manutenzione evolutiva, che sia essa predefinita od oggi non nota e da realizzarsi tramite le giornate a consumo, in nessun caso darà adito ad incrementi del canone di manutenzione ed assistenza per tutta la durata dell’appalto, anche nel caso in cui vengano richieste e realizzate nuove integrazioni.
EV01 - PIATTAFORMA CONTICKI - RECUPERO CREDITI E SANZIONI
Il modulo di recupero crediti e sanzioni attua la delibera regionale 39 del 21/01/2013 che regolamenta e traccia le linee guida per il pagamento delle prestazioni sanitarie e relativo recupero crediti e sanzioni.
Conticki mantiene traccia sia delle posizioni debitorie che dei pagamenti di ticket ordinario, quote di Pronto Soccorso, quote aggiuntive per fasce di reddito, mancato ritiro referto, mancata disdetta prenotazione, permettendo così si supportare le aziende nella gestione della procedura di recupero bonario di quanto dovuto e non pagato.
Il modulo di recupero somme dovute permette gestire l’iter per il recupero delle somme dovute:
● individuare le posizioni debitorie insolute
● emissione di avviso bonario
○ creazione dell’avviso xxxxxxx
○ controllo
○ postalizzazione
○ lavorazione
● emissione dell’atto di intimazione
○ creazione dell’atto amministrativo
○ postalizzazione
○ notifica
○ pagamento
○ giustificativo
● gestione dell’eventuale giustificativo del debitore
● annullamento o rettifica dell’atto
Il modulo di recupero sanzioni applicate permette la gestione dell’iter delle sanzioni amministrative:
● identificazione mancata disdetta o mancato ritiro referto
● emissione del processo verbale da parte dell’azienda
○ emissione del processo verbale
○ controllo
○ postalizzazione
○ lavorazione
● emissione dell’ordinanza ingiuntiva nel caso di mancato pagamento di cui al punto precedente
○ creazione ordinanza ingiuntiva
○ postalizzazione
○ notifica
○ pagamento
○ giustificativi
● giustificazione tramite memoria difensiva
● annullamento o rettifica dell’atto
Il modulo di riscossione coattiva permette la gestione dell’iter di recupero delle posizioni insolute:
● identificazione delle posizioni insolute per l’iscrizione a ruolo
● creazione di una minuta di ruolo da inviare al riscossore
● il riscossore gestisce il recupero del credito
● controllo degli eventuali giustificativi
● acquisizione degli avvenuti pagamenti
Il modulo di recupero crediti è stato collaudato ad agosto 2019 ma non se ne prevede l’avvio in esercizio nel breve periodo per scelta delle XX.XX. e perché il precedente bando non prevedeva il recupero dei dati storici; non si esclude però che sia opportuno prevederne l’effort per il futuro, comprensivo pertanto del recupero delle posizioni debitorie pregresse e di eventuali proposte migliorative.
VOCE EV01 - INCLUSIONI
L’attività che i partecipanti devono prevedere nella offerta tecnica e nella scheda offerta economica include, per ogni XX.XX.:
● eventuale attività di sviluppo software
● il recupero dati delle posizioni debitorie pregresse dagli N software presenti nelle varie XX.XX. (CUP locali, LIS, PS, etc)
● le attività di configurazione, formazione, messa in esercizio
● l’affiancamento all’avvio
● il canone di assistenza e manutenzione per tutta la durata dell’appalto
EV02 - MIGRAZIONE AGENDE LIBERA PROFESSIONE SU CUP 2.0
La migrazione delle XX.XX. sulla piattaforma CUP 2.0 non ha incluso nella sua fase iniziale le agende della libera professione; ritenendo questa una possibile fase successiva del progetto, è opportuno individuare modalità e costi per ciascuna migrazione dai sistemi attualmente in uso in ciascuna realtà.
A tale scopo i partecipanti dovranno produrre:
● una proposta progettuale corredata di GANTT
● la modalità di configurazione dei listini
● il tracciato proposto per la migrazione dei dati dai CUP locali
● l’eventuale impatto sugli RFC di processo
● le eventuali modifiche necessarie a garantire i servizi online ai cittadini
● la proposta per la formazione e l’affiancamento per ciascuna exAASS/AOU
● il GANTT, le WBS e la proposta di check list di verifica di conformità
● le caratteristiche qualitative del PM e dei Team
VOCE EV02 - INCLUSIONI
L’attività che i partecipanti devono prevedere nella offerta tecnica e nella scheda offerta economica include, per ogni XX.XX.:
● eventuale attività di sviluppo software
● attività di installazione, configurazione, formazione e affiancamento all’avvio
● attività di recupero dati pregressi
● integrazione con i servizi al cittadino (TOTEM, Portale, APP ecc.)
● il canone di assistenza e manutenzione per tutta la durata dell’appalto
EV03 - EVOLUZIONE DELLE INTEGRAZIONI CON LE PRESCRIZIONI O CON ALTRI SERVIZI
Al fine di favorire le attività di prenotazione minimizzando l’impatto sui processi in essere, si ritiene utile individuare modalità e costi per mantenere costantemente aggiornata l’integrazione tra Conticki e CUP 2.0 e i servizi regionali/nazionali, per garantire l’aggiornamento dei servizi di interazione con IRIS, con i percorsi di accoglienza e pagamento, etc. Nello specifico, i partecipanti dovranno produrre:
● la proposta tecnica per la tempestiva inclusione, per tutta la durata dell’appalto, di ogni esistente o nuova informazione proveniente dalla prescrizione dematerializzata, da IRIS, da altri servizi
● ogni altra eventuale miglioria o evoluzione dei servizi di integrazione attuali
● una proposta per il supporto tecnico/funzionale ai fornitori terzi durante le attività di test e di avvio qualora le modifiche avessero un impatto sugli applicativi aziendali integrati
● il GANTT, le WBS e la proposta di check list di verifica di conformità per i fornitori
VOCE EV03 - INCLUSIONI
L’attività che i partecipanti devono prevedere nella offerta tecnica e nella scheda offerta economica include, per ogni XX.XX.:
● eventuale attività di sviluppo software
● le eventuali migliorie richieste e/o proposte
● il supporto ai fornitori terzi fino al raggiungimento del risultato
● il canone di assistenza e manutenzione per tutta la durata dell’appalto
EV04 - INTEGRAZIONI A SERVIZI PER AGEVOLARE LA PRENOTAZIONE DA ALTRI SOFTWARE
Al fine di favorire le attività di prenotazione minimizzando l’impatto sui processi in essere, si ritiene utile individuare modalità e costi per diffondere l’integrazione a servizi tra CUP
2.0 e i sistemi dipartimentali (cartelle cliniche ospedaliere, software in uso negli studi medici, app sanitarie ecc.). Nello specifico, i partecipanti dovranno produrre:
● una proposta per lo sviluppo di un nuovo servizio (o il potenziamento di quelli in essere) che sulla base di determinati parametri di chiamata (es. numero posti da individuare e numero di minuti in cui tenerli bloccati tutti) espone i posti migliori per il cittadino. Caso d’uso di esempio: la APP SmartSST riceve notifica di una nuova ricetta Dema per un certo CF e in modalità push propone al cittadino in automatico i primi posti liberi, con la garanzia che CUP 2.0 li tenga bloccati per un arco di tempo limitato.
● eventuali ulteriori proposte innovative per potenziare le funzioni di prenotazione
● una proposta per il supporto tecnico/funzionale ai fornitori terzi durante le attività di test e di avvio
VOCE EV04 - INCLUSIONI
L’attività che i partecipanti devono prevedere nella offerta tecnica e nella scheda offerta economica include, per ogni XX.XX.:
● eventuale attività di sviluppo software
● il supporto ai fornitori terzi fino al raggiungimento del risultato
● il canone di assistenza e manutenzione per tutta la durata dell’appalto
Viene ipotizzato l’acquisto di un numero forfaittario di servizi da conteggiarsi per ciascun software da integrare (in scheda offerta economica è ipotizzato l’acquisto opzionale di 20 servizi di integrazione). Uno stesso software presente nel SSR in più istanze viene comunque conteggiato con cardinalità 1.
EV05 - EVOLUZIONE FLUSSO TAT E MONITORAGGIO TEMPI DI ATTESA
Il monitoraggio dei tempi di attesa (TAT) delle prestazioni specialistiche ambulatoriali rappresenta uno degli elementi chiave per il governo regionale delle liste di attesa (vedi “Allegati G - PNGLA presente su sito Xxxxxx.Xxx e PRGLA 2019-2021”). L’adozione di un sistema di gestione di offerta e prenotazioni centralizzato pone le basi per il superamento della frammentaria rilevazione oggi in essere sui CUP locali a favore di un meccanismo di supporto in tempo reale. Si evidenzia che le tecnologie attualmente in uso in Regione Toscana prevedono un percorso di realizzazione di sistemi di reporting di livello regionale, cui potranno accedere tutte le XX.XX. su tecnologia SAP HANA.
A tale scopo i partecipanti dovranno produrre:
● una o più proposte progettuali per il monitoraggio dei tempi di attesa che garantisca la risposta ai debiti informativi previsti dal Piano Nazionale di Governo delle Liste di Attesa (tale proposta sarà valutata ed eventualmente realizzata come possibile alternativa alla tradizionale estrazione del flusso TAT)
● gli allegati tecnici a corredo della proposta
● il GANTT, le WBS e la proposta di check list di verifica di conformità
VOCE EV05 - INCLUSIONI
L’attività che i partecipanti devono prevedere nella offerta tecnica e nella scheda offerta economica include, per ogni XX.XX.:
● eventuale attività di sviluppo software
● le attività di implementazione e messa in opera della proposta per il monitoraggio e la realizzazione del flusso TAT secondo il tracciato regionale corrente
● il canone di assistenza e manutenzione per tutta la durata dell’appalto
EV06 - SINCRONIZZAZIONE DEI CATALOGHI
Al fine di contrarre i tempi di recepimento degli aggiornamenti periodicamente introdotti da RT sui cataloghi di ambito CUP, si ritiene utile individuare modalità e costi per la sincronizzazione automatica tra i dizionari di livello centrale e quelli interni alle piattaforme Conticki e CUP 2.0. A titolo di esempio citiamo: il catalogo dei medici del SSR, il catalogo regionale delle prestazioni ambulatoriali, il catalogo dei comuni, ecc.
A tale scopo i partecipanti dovranno produrre:
● l’elenco dei cataloghi che propongono di integrare
● una proposta tecnica per l’integrazione
● il GANTT, le WBS e la proposta di check list di verifica di conformità
VOCE EV06 - INCLUSIONI
L’attività che i partecipanti devono prevedere nella offerta tecnica e nella scheda offerta economica include, per ogni XX.XX.:
● le attività di implementazione e messa in opera della proposta, ivi incluse le attività di presidio dell’impianto, per tutta la durata contrattuale, necessarie nei momenti di modifiche ai cataloghi (es. cessazione codifiche in uso, introduzione nuove codifiche, etc…)
● il canone di assistenza e manutenzione per tutta la durata dell’appalto
EV07 - SEPARAZIONE CODE ED EVOLUZIONE EVENTI RFC 244 e 246
Al fine di ridurre l’impatto organizzativo della manutenzione programmata sui CUP locali nelle realtà migrate a infrastruttura CUP 2.0, si ritiene utile separare la gestione delle code eventi RFC 244 e 246 per ex-ASL/AOU (es. Siena, AOUS o Siena+AOUS). Una modalità di azione selettiva consentirebbe infatti di limitare il raggio d’azione del fermo ai soli servizi CUP di II livello (accettazione, incasso ecc.) mantenendo attivi i servizi di prenotazione o di gestione agende.
L’esperienza di integrazione tra CUP 2.0 e i CUP di II livello in uso nelle XX.XX migrate a tale infrastruttura ha fatto emergere esigenze di modifica o integrazione dei tag oggi gestiti su RFC 244 e 246. Si ritiene quindi utile valutare l’impegno necessario per gli eventuali adeguamenti.
A tale scopo i partecipanti dovranno produrre:
● una soluzione progettuale per la separazione delle code eventi RFC 244 e 246 a livello di ex-ASL/AOU
● una proposta di gestione del percorso che porta all’aggiunta di un tag, es. la struttura erogante necessaria a mantenere attive le regole di interoperabilità locali
● gli allegati tecnici a corredo della proposta
● il GANTT, le WBS e la proposta di check list di verifica di conformità
VOCE EV07 - INCLUSIONI
L’attività che i partecipanti devono prevedere nella offerta tecnica e nella scheda offerta economica include, per ogni XX.XX.:
● eventuale attività di sviluppo software
● le attività di implementazione e messa in opera della proposta
● il supporto ai fornitori terzi fino al raggiungimento del risultato
● il canone di assistenza e manutenzione per tutta la durata dell’appalto
EV08 - EVOLUZIONE DAY SERVICE
La migrazione delle XX.XX. sulla piattaforma CUP 2.0 non ha incluso nella sua fase iniziale la gestione semplificata degli accessi in Day Service che consenta una visualizzazione dell’offerta a matrice e una conseguente impostazione rapida del piano di cura ottimizzando il numero di accessi per il cittadino; ritenendo questa una possibile fase successiva del progetto, è opportuno individuare modalità e costi per la migrazione dai sistemi attualmente in uso in ciascuna realtà.
A tale scopo i partecipanti dovranno produrre:
● una proposta progettuale corredata da GANTT, WBS e check list di verifica di conformità
● l’eventuale impatto sugli RFC di processo
● le eventuali modifiche (che si intendono senza ulteriori oneri) necessarie a garantire i servizi online ai cittadini
● la proposta per la formazione e l’affiancamento per ciascuna exASL/AOU
VOCE EV08 - INCLUSIONI
L’attività che i partecipanti devono prevedere nella offerta tecnica e nella scheda offerta economica include, per ogni XX.XX.:
● eventuale attività di sviluppo software
● le attività di implementazione e messa in opera della proposta, ivi compresa la formazione a affiancamento per ogni XX.XX.
● il canone di assistenza e manutenzione per tutta la durata dell’appalto
EV09 - EVOLUZIONE PIANO ODONTOIATRICO
La migrazione delle XX.XX. sulla piattaforma CUP 2.0 non ha incluso nella sua fase iniziale la gestione semplificata degli accessi odontoiatrici; ritenendo questa una possibile evoluzione di carattere applicativo/funzionale, è opportuno individuarne modalità e costi di attivazione.
A tale scopo i partecipanti dovranno produrre:
● una proposta progettuale corredata da GANTT, WBS e check list di verifica di conformità
● l’eventuale impatto sugli RFC di processo
● le eventuali modifiche (che si intendono senza ulteriori oneri) necessarie a garantire i servizi online ai cittadini
● la proposta per la formazione e l’affiancamento per ciascuna exASL/AOU
VOCE EV09 - INCLUSIONI
L’attività che i partecipanti devono prevedere nella offerta tecnica e nella scheda offerta economica include, per ogni XX.XX.:
● eventuale attività di sviluppo software
● le attività di implementazione e messa in opera della proposta, ivi compresa la formazione a affiancamento per ogni XX.XX.
● il canone di assistenza e manutenzione per tutta la durata dell’appalto
EV10 - EVOLUZIONE NELLA GESTIONE ISTITUTI PRIVATI ACCREDITATI
I rapporti tra Aziende Sanitarie ed Istituti Privati Accreditati possono essere tendenzialmente suddivisi in due macro categorie:
● modello “tradizionale”
● modello “competitivo”
Il modello “tradizionale” prevede la stipula di una convenzione che limita il budget economico a disposizione di ciascuna specifica struttura.
Il modello “competitivo” prevede la definizione di un tetto massimo di prestazioni erogabili da più strutture lasciando quindi al cittadino la scelta della soluzione maggiormente appetibile.
Ritenendo tale duplice gestione una possibile evoluzione di carattere applicativo/funzionale, è opportuno individuarne modalità e costi di attivazione.
A tale scopo i partecipanti dovranno produrre:
● un proposta evolutiva volta a potenziare la gestione del budget e a consentire la doppia gestione contemporanea
● un’attenta descrizione delle funzioni proposte
● l’eventuale impatto sugli RFC di processo
● le eventuali modifiche (che si intendono senza ulteriori oneri) necessarie a garantire i servizi online ai cittadini
● una proposta progettuale corredata da GANTT, WBS e check list di verifica di conformità
VOCE EV10 - INCLUSIONI
L’attività che i partecipanti devono prevedere nella offerta tecnica e nella scheda offerta economica include, per ogni XX.XX.:
● eventuale attività di sviluppo software
● le attività di implementazione e messa in opera della proposta, ivi compresa la formazione a affiancamento per ogni XX.XX.
● il canone di assistenza e manutenzione per tutta la durata dell’appalto
EV11 - EVOLUZIONE NELLA GESTIONE DELLE NOTE AL CITTADINO
In aggiunta alle note testuali già configurabili sull’applicativo, si ritiene utile individuare modalità e costi di attivazione di una possibile evoluzione di carattere applicativo/funzionale che consenta alle XX.XX. di caricare file pdf da stampare contestualmente al promemoria a fronte della prenotazione dell’esame associato (es. indicazioni sulla preparazione a un esame piuttosto che consensi informati alla prestazione). Tale evoluzione deve ovviamente essere disponibile in multi-canalità, quindi anche le prenotazioni via APP/portale, e tramite invocazione a servizi da altri applicativi.
A tale scopo i partecipanti dovranno produrre:
● una proposta progettuale corredata da GANTT, WBS e check list di verifica di conformità
● un’attenta descrizione delle funzioni proposte
● l’eventuale impatto sugli RFC di processo e/o sui servizi di integrazione
● le eventuali modifiche (che si intendono senza ulteriori oneri) necessarie a garantire i servizi online ai cittadini
VOCE EV11 - INCLUSIONI
L’attività che i partecipanti devono prevedere nella offerta tecnica e nella scheda offerta economica include, per ogni XX.XX.:
● eventuale attività di sviluppo software
● le attività di implementazione e messa in opera della proposta, ivi compresa la formazione a affiancamento per ogni XX.XX.
● il canone di assistenza e manutenzione per tutta la durata dell’appalto
EV12 - EVOLUZIONE NELLA GESTIONE DEI VINCOLI DI ACCESSO ALL’OFFERTA
Ai fini del miglioramento del governo delle liste d’attesa e nell’ottica all'automatizzazione del percorso di prescrizione-prenotazione-erogazione, si ritiene utile prevedere delle evoluzioni nella gestione dei vincoli che determinano l’accesso all’offerta e l’eventuale rilascio di disponibilità non fruite (es. quesito diagnostico codificato, età ecc.); ritenendo che la funzione rappresenti una possibile evoluzione dell’ambito di progetto, è opportuno individuarne modalità e costi di attivazione.
A tale scopo i partecipanti dovranno produrre:
● una proposta progettuale corredata da GANTT, WBS e check list di verifica di conformità
● un’attenta descrizione delle funzioni proposte
● l’eventuale impatto sugli RFC di processo e/o sui servizi di integrazione
VOCE EV12 - INCLUSIONI
L’attività che i partecipanti devono prevedere nella offerta tecnica e nella scheda offerta economica include, per ogni XX.XX.:
● eventuale attività di sviluppo software
● le attività di implementazione e messa in opera della proposta
● il canone di assistenza e manutenzione per tutta la durata dell’appalto
EV13 - GESTIONE AVVISO DI PAGAMENTO
Il sistema di gestione posizioni debitorie e pagamenti IRIS espone un WS per la stampa dell’avviso di pagamento AGID compliant comprensivo di bollettino postale mod.3 come descritto nell’ “ALLEGATO E - RT_IRIS_MAN_GenerazioneAvvisi.pdf.
Al fine di agevolare il cittadino alle possibili opzioni di pagamento si ritiene utile lo sviluppo dell’integrazione al suddetto WS dall’applicativo CUP 2.0 prevedendo la stampa dell’avviso di pagamento o l’invio dello stesso in formato pdf tramite mail e/o sms.
L’avviso di pagamento, se richiesto, andrà ad aggiungersi all’attuale documentazione emessa dal sistema e rilasciata al cittadino all’atto della prenotazione (es. promemoria della prenotazione, preparazioni, etc.).
A tale scopo i partecipanti dovranno produrre:
● una proposta progettuale corredata da GANTT, WBS e check list di verifica di conformità
● un’attenta descrizione delle funzioni proposte volta a garantire trasparenza verso la cittadinanza e semplicità di accesso al dato
● le eventuali modifiche (che si intendono senza ulteriori oneri) necessarie a garantire i servizi online ai cittadini
VOCE EV13 - INCLUSIONI
L’attività che i partecipanti devono prevedere nella offerta tecnica e nella scheda offerta economica include, per ogni XX.XX.:
● eventuale attività di sviluppo software
● le attività di implementazione e messa in opera della proposta
● il canone di assistenza e manutenzione per tutta la durata dell’appalto
EV14 - ARCHIVIAZIONE STORICA E GESTIONE DATI
Nelle piattaforme Conticki-CUP 2.0 sono memorizzati tutti i dati delle prescrizioni sanitarie e relativi stati (prescritto, presa in carico, erogato), i dati delle prenotazioni e delle agende, i dati delle posizioni debitorie di tutta la Sanità Toscana.
Ogni anno vengono transati milioni di messaggi pertanto dovranno essere previste delle azioni di “svecchiamento” del db in maniera tale da mantenere online solo il necessario e garantire un ottimo livello prestazionale delle query di ricerca. I dati archiviati dovranno rimanere accessibili in consultazione agli operatori delle XX.XX. (pertanto senza necessità di skill informatici). I servizi di archiviazione dei dati dovranno essere il più possibile automatizzati e il fornitore deve proporre un aggiornamento delle funzioni di archiviazione/logging che suggerisce di apportare al fine di ridurre le attuali ridondanze.
A tale scopo i partecipanti dovranno produrre:
● l’analisi delle possibili modalità di gestione del processo di svecchiamento del DB;
● il GANTT, le WBS e la proposta di check list di verifica di conformità;
VOCE EV14 - INCLUSIONI
L’attività che i partecipanti devono prevedere nella offerta tecnica e nella scheda offerta economica include, per ogni XX.XX.:
● eventuale attività di sviluppo software
● le attività di implementazione e messa in opera della proposta
● il canone di assistenza e manutenzione per tutta la durata dell’appalto
EV15 - SISTEMA DI MONITORAGGIO E REPORTISTICA MENSILE
Conticki e CUP 2.0 dispongono di una console di ricerca dei messaggi transitati sull’infrastruttura e relativo stato.
Attualmente non esiste un automatismo di monitoraggio: tale attività viene effettuata manualmente e si limita all’utilizzo della console di Conticki per verificare la presenza o meno di almeno un messaggio RFC per tipo/azienda. Non sono presenti alert proattivi su eventuali tempi di latenza sulla consegna ed invio dei messaggi. Non sono presenti report sulla messaggistica transitata nel sistema, errori, stato dei messaggi, etc.
Tutte queste informazioni sono vitali nell’attività di controllo e tuning del sistema.
Al fine di migliorare le prestazioni di ricerca e fruibilità del monitor dei messaggi è richiesto un progetto evolutivo del sistema che preveda lo scorporo ed indicizzazione di un subset di metadati significativi utilizzabili nelle ricerche (es. NRE, Codice Fiscale, IUV, etc.) dal messaggio xml che attualmente viene memorizzato in una unico campo del DB.
A tale scopo i partecipanti dovranno produrre:
● l’analisi delle possibili modalità di automazione del servizio di monitoraggio, tenendo conto della necessità di poter configurare valori-soglia differenti per ogni macro-zona/RFC e di invio automatico di alert via E-mail
● la proposta evolutiva di quanto in essere
● l’implementazione di report sia generali che di dettaglio dei messaggi transitati nel sistema e relativi stati
VOCE EV15 - INCLUSIONI
L’attività che i partecipanti devono prevedere nella offerta tecnica e nella scheda offerta economica include, per ogni XX.XX.:
● eventuale attività di sviluppo software
● le attività di implementazione e messa in opera della proposta
● il canone di assistenza e manutenzione per tutta la durata dell’appalto
EV16 - EVOLUZIONE PRE LISTE
La presa in carico dei cittadini che non trovano disponibilità di prestazioni specialistiche ambulatoriali nei tempi e nell’area di garanzia previsti dal PRGLA viene oggi gestita con procedure organizzative extra-CUP (tipicamente l’operatore CUP prende nota della prescrizione, si confronta con le strutture aziendali preposte ad individuare una disponibilità nei tempi e richiama il cittadino non appena completata la prenotazione); ritenendo che la strutturazione delle Pre Liste rappresenti una possibile evoluzione dell’ambito di progetto, è opportuno individuarne modalità e costi di attivazione.
A tale scopo i partecipanti dovranno produrre:
● una proposta progettuale corredata da GANTT, WBS e check list di verifica di conformità
● un’attenta descrizione delle funzioni proposte volta a garantire la piena trasparenza verso la cittadinanza e la semplicità di accesso al dato
● l’eventuale impatto sugli RFC di processo
● una proposta per la formazione e l’affiancamento per ciascuna exASL/AOU
VOCE EV16 - INCLUSIONI
L’attività che i partecipanti devono prevedere nella offerta tecnica e nella scheda offerta economica include, per ogni XX.XX.:
● eventuale attività di sviluppo software
● le attività di implementazione e messa in opera della proposta
● il canone di assistenza e manutenzione per tutta la durata dell’appalto
EV17 - MIGRAZIONE ASL TOSCANA CENTRO A CUP 2.0
La migrazione della ASL Toscana Centro avverrà contestualmente al cambio di CUP II livello nelle 4 realtà di Empoli, Prato, Pistoia e Firenze. Questo scenario non è mai stato analizzato e/o sperimentato in altra realtà e richiede una attenta valutazione preliminare volta a ridurre i rischi di progetto.
A tale scopo i partecipanti dovranno produrre:
● l’analisi delle possibili modalità di migrazione con GANTT e analisi SWOT dei vari scenari
● le eventuali modifiche ai tracciati in uso per la migrazione dei dati dai CUP locali (vedi ALLEGATI E: “Relazione TRACO-RFC 244-246_v1.0” e “TRACO v15 e relative DDL”)
● le modalità di controllo/verifiche/collaudi preliminari proposte nei vari scenari
● le eventuali modifiche al software necessarie all’attivazione su CUP 2.0 di tutte le agende oggi gestite sul CUP, ad esempio: Laboratorio, Odontoiatria, Screening, Agende per interni, etc.
● la proposta per la formazione e l’affiancamento per ciascuna Macro Zona di ASL Toscana Centro
● la proposta per come effettuare stress test pre migrazione
● il GANTT, le WBS e la proposta di check list di verifica di conformità
● le caratteristiche qualitative del PM e dei Team
VOCE EV17 - INCLUSIONI
L’attività che i partecipanti devono prevedere nella offerta tecnica e nella scheda offerta economica include, per ogni XX.XX.:
● eventuale attività di sviluppo software
● attività di installazione, configurazione, formazione e affiancamento all’avvio
● attività di recupero dati pregressi
● integrazione con i servizi al cittadino (TOTEM, Portale, APP ecc.)
● attività di test, collaudo e avvio per l’integrazione tra CUP 2.0 e il CUP di II livello
● canone di assistenza e manutenzione per tutta la durata dell’appalto
EV18 - MIGRAZIONE AOU CAREGGI A CUP 2.0
La migrazione della AOU Careggi avverrà contestualmente al cambio di CUP II livello nello scenario di una probabile adesione di AOUC alla gara svolta per ASL Toscana Centro. Questo scenario non è mai stato analizzato e/o sperimentato in altra realtà e richiede una attenta valutazione preliminare volta a ridurre i rischi di progetto.
A tale scopo i partecipanti dovranno produrre:
● l’analisi delle possibili modalità di migrazione con GANTT e analisi SWOT dei vari scenari
● le eventuali modifiche ai tracciati in uso per la migrazione dei dati dai CUP locali (cosiddette TRACO)
● le modalità di controllo/verifiche/collaudi preliminari proposte nei vari scenari
● le eventuali modifiche al software necessarie all’attivazione su CUP 2.0 di tutte le agende oggi gestite sul CUP, ad esempio: Laboratorio, Anatomia Patologica, Odontoiatria, Agende per interni, etc.
● la proposta per la formazione e l’affiancamento
● la proposta per come effettuare stress test pre migrazione
● il GANTT, le WBS e la proposta di check list di verifica di conformità
● le caratteristiche qualitative del PM e dei Team
VOCE EV18 - INCLUSIONI
L’attività che i partecipanti devono prevedere nella offerta tecnica e nella scheda offerta economica include, per ogni XX.XX.:
● eventuale attività di sviluppo software
● attività di installazione, configurazione, formazione e affiancamento all’avvio
● attività di recupero dati pregressi
● integrazione con i servizi al cittadino (TOTEM, Portale, APP ecc.)
● attività di test, collaudo e avvio per l’integrazione tra CUP 2.0 e il CUP di II livello
● canone di assistenza e manutenzione per tutta la durata dell’appalto
EV19 - MIGRAZIONE AOU XXXXX A CUP 2.0
La migrazione della AOU Xxxxx avverrà contestualmente al cambio di CUP II livello nello scenario di una probabile adesione di AOUM alla gara svolta per ASL Toscana Centro. Questo scenario non è mai stato analizzato e/o sperimentato in altra realtà e richiede una attenta valutazione preliminare volta a ridurre i rischi di progetto.
A tale scopo i partecipanti dovranno produrre:
● l’analisi delle possibili modalità di migrazione con GANTT e analisi SWOT dei vari scenari
● le eventuali modifiche ai tracciati in uso per la migrazione dei dati dai CUP locali (cosiddette TRACO)
● le modalità di controllo/verifiche/collaudi preliminari proposte nei vari scenari
● le eventuali modifiche al software necessarie all’attivazione su CUP 2.0 di tutte le agende oggi gestite sul CUP, ad esempio: Laboratorio, Odontoiatria, Agende per interni, etc.
● la proposta per la formazione e l’affiancamento
● la proposta per come effettuare stress test pre migrazione
● il GANTT, le WBS e la proposta di check list di verifica di conformità
● le caratteristiche qualitative del PM e dei Team
VOCE EV19 - INCLUSIONI
L’attività che i partecipanti devono prevedere nella offerta tecnica e nella scheda offerta economica include, per ogni XX.XX.:
● eventuale attività di sviluppo software
● attività di installazione, configurazione, formazione e affiancamento all’avvio
● attività di recupero dati pregressi
● integrazione con i servizi al cittadino (TOTEM, Portale, APP ecc.)
● attività di test, collaudo e avvio per l’integrazione tra CUP 2.0 e il CUP di II livello
● canone di assistenza e manutenzione per tutta la durata dell’appalto
EV20 - INTEGRAZIONE DIRETTA CUP 2.0/CONTICKI-IRIS
Il modello in essere prevede la creazione della posizione debitoria a carico dei CUP locali tramite il supporto dell’infrastruttura Conticki. Questo modello, con la diffusione di CUP 2.0 nelle XX.XX. e con il dispiegamento di PagoPA e della nuova fornitura per i pagamenti del SSR Toscano, rischia di appesantire il processo e di non garantire la migliore performance per il cittadino.
A tale scopo i partecipanti dovranno produrre:
● un proposta evolutiva per l’apertura delle posizioni debitorie su IRIS al momento della prenotazione su CUP 2.0 (pur mantenendo tale servizio a carico dei CUP locali per le accettazioni dirette), che tenga conto anche di eventuali nuove RFC e/o modifiche alle esistenti per allineare i CUP locali con i pagamenti avvenuti
● il GANTT, le WBS e la proposta di check list di verifica di conformità
VOCE EV20 - INCLUSIONI
L’attività che i partecipanti devono prevedere nella offerta tecnica e nella scheda offerta economica include, per ogni XX.XX.:
● attività di sviluppo software
● attività di installazione, test, configurazione, formazione e affiancamento all’avvio
● canone di assistenza e manutenzione per tutta la durata dell’appalto
EV21 - SVILUPPO FUNZIONALITÀ DI CASSA
Già oggi le farmacie dispongono tramite CUP 2.0 di una funzionalità di incasso semplificata, mentre gli operatori delle XX.XX. utilizzano due software diversi spesso contestualmente (CUP 2.0 per prenotare e il CUP II livello locale per effettuare gli incassi).
Uno scenario futuro vedrà il cittadino relazionarsi con la Sanità attraverso percorsi interamente automatizzati (ricetta dematerializzata, prenotazione Online, pagamento e prenotazione ticket di accoglienza Online, self accettazione tramite totem). In questo scenario il CUP II livello evolverà progressivamente ad un ruolo diverso, ovvero di orchestratore dei livelli di integrazione e cooperazione locale, più che di interfaccia per la gestione degli aspetti contabili.
E’ pertanto ragionevole ipotizzare che le funzionalità di cassa siano centralizzate su CUP
2.0 (ricordiamo anche che Conticki realizza già le funzionalità di gestione centralizzata del recupero crediti) con contestuale sostituzione del flusso SPA - o almeno di parte di esso - con i dati di erogato già oggi trasmessi con la RFC 231 dai CUP locali.
Ai partecipanti è pertanto richiesta una prima progettualità volta a contestualizzare questo obiettivo, tenendo presente che la progettazione e realizzazione di una funzione di cassa su CUP 2.0 deve poter poi operare non solo per le prenotazioni Cup 2.0 ma per qualsiasi incasso come avviene oggi sui CUP.
A tale scopo i partecipanti dovranno produrre:
● una proposta progettuale corredata di GANTT
● il tracciato proposto per la migrazione dei dati dai CUP locali
● l’eventuale impatto sugli RFC di processo
● la proposta per la formazione e l’affiancamento per ciascuna exAASS/AOU
● il GANTT, le WBS e la proposta di check list di verifica di conformità
● le caratteristiche qualitative del PM e dei Team
VOCE EV21 - INCLUSIONI
L’attività che i partecipanti devono prevedere nella offerta tecnica e nella scheda offerta economica include, per ogni XX.XX.:
● attività di sviluppo software
● attività di installazione, configurazione, formazione e affiancamento all’avvio
● attività di recupero dati pregressi
● il canone di assistenza e manutenzione per tutta la durata dell’appalto
Nota: E’ evidente che questa progettualità è di ampiezza e complessità maggiore rispetto alle precedenti, e che un futuro sviluppo in questo ambito dovrà passare per un confronto tra i vari attori in gioco (RT, Estar, XX.XX. e l’Aggiudicatario) che trasformi questa prima ipotesi in un progetto realmente esecutivo. La richiesta è però volta a valutare la capacità tecnica e la visione innovativa dei partecipanti, nonché a fornire al SSR una prima stima dei costi necessari per affrontare questo tipo di evoluzioni.
EV22 - PORTALE AL CITTADINO
E’ attualmente pubblicato il portale di prenotazione per i cittadini al link: xxxxx://xxxxxxx.xxxxxx.xxxxxxx.xx/
In futuro prevediamo la realizzazione di un nuovo portale sviluppato con tecnologie più moderne e che rispetti le linee guida DESIGN PA di Agid e le nuove tecnologie di autenticazione (es. OAuth2).
A tale scopo i partecipanti dovranno produrre:
● una prima proposta di progettazione
● il GANTT, le WBS
VOCE EV22 - INCLUSIONI
L’attività che i partecipanti devono prevedere nella offerta tecnica e nella scheda offerta economica include, per ogni XX.XX.:
● attività di sviluppo software
● attività di installazione, test, configurazione e avvio
● canone di assistenza e manutenzione per tutta la durata dell’appalto
TUNING/DBA, FORMAZIONE E AFFIANCAMENTO
Si ritiene fornitura opzionale un pacchetto di giornate di tuning/dba, formazione e affiancamento, eseguite da personale esperto e qualificato, come richiesto nella scheda offerta economica, che si ritengono aggiuntive rispetto a quanto previsto a canone (es. DBA) o incluso nelle singole MEV.
La modalità di acquisto di eventuali pacchetti e le relative modalità di erogazione e di fatturazione, sono analoghe a quanto illustrato per la Manutenzione Evolutiva e fanno riferimento alla procedura “ALLEGATO B - PA 45 2018 REV02 SOFTWARE CHANGE REQUEST”.
PENALI PER RITARDI NELLE ESECUZIONI CONTRATTUALI
In caso di ritardi nelle fasi di subentro o di consegna delle manutenzioni evolutive richieste, Estar ha la facoltà di applicare le seguenti penalità, previa valutazione insindacabile della gravità dell’inadempienza, del reiterare dei ritardi e dell’eventuale danno procurato al regolare svolgimento del servizio.
Penalità applicabili alla fase di subentro:
❖ Per ogni giorno solare di ritardo rispetto al termine previsto di 6 mesi per la presa in carico completa dei servizi, l’amministrazione si riserva di applicare una penale fino ad un massimo di €1.000/giorno IE
Penalità applicabili alla manutenzione evolutiva prevista nel bando (EV*):
❖ Per ogni giorno solare di ritardo rispetto al gantt proposto, l’amministrazione si riserva di applicare una penale fino ad un massimo di € 250/giorno IE se il ritardo è contenuto in un numero di giorni solari inferiore al 30% della durata complessiva del GANTT di ciascuna EV*
❖ Per ogni giorno solare di ritardo rispetto al gantt proposto, l’amministrazione si riserva di applicare una penale fino ad un massimo di € 500/giorno IE se il ritardo è contenuto in un numero di giorni solari superiore al 30% della durata complessiva del GANTT di ciascuna EV*
Per le penali sul servizio di assistenza e manutenzione, ivi inclusa la manutenzione evolutiva a consumo, si rimanda all’Allegato A1 e relative precisazioni al paragrafo ‘SERVIZIO DI ASSISTENZA E MANUTENZIONE’.
SERVIZIO DI ASSISTENZA E MANUTENZIONE
Il servizio di Assistenza e Manutenzione dovrà attenersi a quanto previsto dal C.S.A. ESTAR Manutenzione Applicativi (“ALLEGATO A1 - CAP. TECN. DEFINITIVO PER ASSISTENZA E MANUTENZIONE SW_v1.30”) con le integrazioni sotto descritte.
Cap 5 - Oggetto del Servizio
Sono da ritenersi inclusi tutti i moduli e le funzioni oggetto di fornitura (Conticki, CUP 2.0 modulo base, CUP 2.0 modulo ‘light’, funzioni di interoperabilità, integrazioni/RFC, viste per BI regionale ecc.). E’ esclusa qualsiasi forma di help desk al cittadino.
Par 5.1 - Copertura Oraria del Servizio
Stanti la centralità dell’infrastruttura Conticki nell’ambito del SSR e l’essenzialità dei servizi offerti da CUP 2.0, l’aggiudicatario dovrà garantire copertura oraria del servizio di tipo “ESTESO” per tutte le funzionalità e quotare economicamente l’estensione al servizio H24.
COPERTURA ORARIA DEL SERVIZIO | |
ESTESO, 7gg | dal lunedì alla domenica, dalle 7:30 alle 19:30, festivi inclusi |
H24, 365gg H24 | Tutti i giorni della settimana dalle 00:00 alle 23:59 festivi compresi |
Cap 6 - Attività previste dal servizio
Come descritto nei precedenti capitoli, CUP 2.0 estende la piattaforma Conticki aggiungendo la gestione di offerta e prenotazione di prestazioni specialistiche ambulatoriali a livello regionale. Presenta un modulo semplificato per l’erogazione dei servizi in farmacia (il cosiddetto CUP 2.0 ‘light’) comprensivo di una funzione di incasso analoga a quella in essere sui canali di pagamento automatico. Interopera coi CUP locali e con altri sistemi del SSR (es. CHD SISS, CAST).
L’elevata pervasività dei servizi offerti, unita alla eterogeneità dei soggetti che ne fruiscono (medici di medicina generale, medici specialisti, operatori CUP, farmacisti ecc.) ed all’alto livello di integrazione, comporta la necessità di prevedere un servizio di Assistenza Specialistica dedicato che funga da unico punto di accesso al supporto per tutte le categorie di utenti, di seguito SPoC - Single Point of Contact.
Il servizio SPoC dovrà orchestrare le seguenti attività:
● Servizio di Assistenza Specialistica di 1° e 2° livello su tutti i sistemi oggetto di fornitura
● Gestione dell’escalation verso HD di 2° livello su tutti i sistemi oggetto di fornitura
● Gestione dell’escalation verso HD di 2° livello terzi (CHD SISS, CAST, IRIS, applicativi integrati ecc)
● Servizio di Monitoraggio proattivo dell’intera infrastruttura (DB, AS, RFC e relative code invio/ricezione messaggi ecc.)
Fig. SPoC / Architettura
Fig. SPoC/Processo
Soffermando l’attenzione sull’Assistenza Specialistica di 1° e 2° livello, si precisa che sono da ritenersi inclusi anche:
● interventi formativi/informativi da remoto
● interventi sulle configurazioni delle applicazioni
● presa in carico delle mail automatiche di monitoraggio da terzi (es. TIX)
● presa in carico dei report di vulnerability assessment forniti periodicamente da ESTAR e RT/TIX
● presa in carico periodica dei piani di patching da concordare con ESTAR e RT/TIX
La fornitura dovrà comprendere l’acquisto e la gestione, per tutta la durata dell’appalto, dei certificati SSL sui frontend.
Il servizio dovrà inoltre includere la produzione di report periodici ad integrazione di quelli già indicati in Allegato A1. I report dovranno essere inviati al DEC entro le scadenze sotto riportate:
DEFINIZIONE DEL REPORT | PERIODICITÀ | DA PRODURRE ENTRO |
Elenco delle posizioni anagrafiche CUP 2.0 non sincronizzate con l’anagrafe unica regionale | mensile | Il 3° giorno lavorativo del mese successivo |
Numero accessi contemporanei giornalieri per AASS/zona | mensile | Il 3° giorno lavorativo del mese successivo |
Tempi di risposta (massimi, minimi, medi) delle principali query oggetto di monitoraggio | mensile | Il 3° giorno lavorativo del mese successivo |
Query che hanno evidenziato peggioramenti di performance e interventi correttivi posti in essere | mensile | Il 3° giorno lavorativo del mese successivo |
Episodi di interruzione dell’interoperabilità, per ciascuna RFC | mensile | Il 3° giorno lavorativo del mese successivo |
Tasso di crescita tablespace/DB | mensile | Il 3° giorno lavorativo del mese successivo |
Tasso di lock del DB | mensile | Il 3° giorno lavorativo del mese successivo |
Deve inoltre comprendere reportistica ad hoc per ticket inoltrati a terzi (es. solleciti ecc.)
E’ importante che il SPoC abbia un solo indirizzo mail e numero telefonico, un unico sistema di trouble ticketing accessibile al cliente per attività di verifica, un unico processo ed unica modalità di gestione di tutte le tipologie di ticket.
E’ richiesta scalabilità del perimetro di competenza del servizio SPoC, in quanto si ritiene che possa crescere con le esigenze di Progetto.
Cap 7 - Livelli di Servizio
Stante quanto sopra, è richiesto un livello di servizio aggiuntivo rispetto a quanto previsto in “ALLEGATO A1 - CAP. TECN. DEFINITIVO PER ASSISTENZA E MANUTENZIONE SW_v1.30”.
Livello di criticità | Descrizione della criticità | Tempi di risoluzione standard (*) | Tempi di risoluzione limite (**) |
GRAVITA’ S Assistenza Specialistica | Risposta dell’operatore tramite attività di supporto specialistico all’utilizzo delle procedure | Soluzione garantita entro 2 ore lavorative | Soluzione garantita entro 2 ore lavorative |
(*) il tempo di risoluzione deve rispettare i tempi indicati almeno nel 90% dei casi (**) il tempo di risoluzione deve rispettare i tempi indicati nel 100% dei casi
Anche nel caso della Assistenza Specialistica si considera il tempo che intercorre dalla data di segnalazione da parte dell’utente alla data di risoluzione della criticità all'interno del tempo di disponibilità del servizio contrattualizzato.
E’ altresì richiesto un livello di servizio aggiuntivo rispetto a quanto previsto in Allegato A1 anche per problematiche di competenza di fornitori terzi e per il servizio SPoC.
Livello di criticità | Presa in carico Valori Normali (*) | Presa in carico Valori Limite (**) |
GRAVITA’ SP Assistenza Specialistica Terzi e orchestrazione SPoC - prima attivazione ticket | 1 ora lavorativa | 4 ore lavorative |
GRAVITA’ SS Assistenza Specialistica Terzi e orchestrazione SPoC - solleciti per malfunzionamenti critici | 4 ore lavorative | 8 ore lavorative |
(*) da rispettare almeno nel 90% dei casi (**) da rispettare nel 100% dei casi
Par 9.2 - Penali manutenzione correttiva
Di seguito il prospetto delle penali per mancato rispetto degli SLA per la sola aggiunta della GRAVITÀ S non presente nell’ “ALLEGATO A1 - CAP. TECN. DEFINITIVO PER ASSISTENZA E MANUTENZIONE SW_v1.30”.
Livello di | Penali per mancato | Note |
criticità | rispetto SLA | |
GRAVITA’ S Assistenza Specialistica | €50,00 | il ritardo rispetto al valore limite verrà considerato giornata intera e verrà applicata la penale di €50,00 per ogni giorno di ritardo |
INDICE DEGLI ALLEGATI
1 Si ritengono parte integrante del presente capitolato i seguenti documenti:
ALLEGATI A - MANUTENZIONE E ASSISTENZA
ALLEGATO A1 - CAP. TECN. DEFINITIVO PER ASSISTENZA E MANUTENZIONE SW_v1.30
Delinea le caratteristiche del servizio di assistenza e manutenzione che l’Aggiudicatario dovrà garantire per tutta la durata dell’appalto. Illustra le peculiarità di un servizio di assistenza e manutenzione per un software gestionale, sia in termini di manutenzione ordinaria, sia in termini di manutenzione correttiva ed evolutiva. Esplicita i livelli di servizio attesi e la modalità di misurazione dei Service Level Agreement (SLA). Definisce le penali che il Cliente può applicare in caso di non rispetto dei livelli di servizio contrattualizzati.
Specifica le modalità di interazione nel caso di disservizi che abbiano un impatto rilevante ai fini del rischio clinico.
A2 ESEMPIO CALCOLO SLA
Fornisce a solo titolo di esempio un report di calcolo degli SLA che l’Aggiudicatario dovrà produrre in allegato alle fatture periodiche. E’ possibile ovviamente produrre reportistica più ampia e si precisa che quanto contenuto nell’esempio è il livello minimo richiesto.
ALLEGATI B - PROCEDURE ESTAR
PA 45/2018 “Software Change Request - Procedura Gestione Manutenzioni Evolutive e Normativa”
Modulo CHANGE REQUEST V2
La procedura definisce le modalità di gestione delle CHANGE REQUEST sui software in uso in Estar e nelle XX.XX., evidenziando il processo da attuare per la gestione delle attività che rientrano nell'ambito dei servizi di Manutenzione Evolutiva (MEV) sul software aggiudicatario per tutta la durata dell’appalto.
Rientrano in questa procedura anche le attività eseguite dai fornitori che, seppur non sempre inquadrabili nella tipologia ‘CHANGE REQUEST’, hanno un impatto sulla gestione organizzativa delle manutenzioni evolutive (es. attività sistemistiche, estrazioni ad hoc, migrazioni di infrastrutture e DB, formazione, modifiche ai flussi DOC e RFC, ecc.), pertanto la presente procedura sarà applicata ad ogni ambito di utilizzo delle giornate on site e in house comprese nella fornitura.
PA 46/2018 "Software lifecycle management";
La procedura regolamenta il ciclo di vita del software.
PA 47/2018 "Verifiche di conformità forniture software"
La procedura regolamenta le modalità di gestione del progetto e di esecuzione delle verifiche di conformità.
ALLEGATI C - PRIVACY
ESTAR- Allegato C.5 compliance privacy software
ALLEGATI D - REGOLAMENTI XX.XX.
ESEMPI DI REGOLAMENTI DELLA LIBERA PROFESSIONE DI ALCUNE XX.XX.
(i modelli definitivi saranno consegnati all’avvio del contratto) DELIBERA MODELLO COMPETITIVO ASL TOSCANA CENTRO
ALLEGATI E - DOCUMENTI TECNOLOGICI SPECIFICI
Codifiche CUP2.0_v7.0.xls CONTICKI_SIM CONSOLE_MUT_1.1.pdf
KIT TEST Agende.rar
KIT TEST Prenotazioni 18012019.7z NamingConvention-IRIS-Conticki_3.8.TAS.PDF
Preconticki MN_Descrizione_Interfaccia_WebService_PreConticki_42.pdf XxxXxxxxxxx wsdl versione 42.7z
Relazione TRACO-RFC 244-246_v1.0.xls
REQ SINC -Conticki Strutture per DWH_100.pdf RT_IRIS_MAN_GenerazioneAvvisi.pdf Specifiche ws prenotazione.7z
TRACO v15 e relative DLL.zip
Linee Guida Design PA Agid: xxxxx://xxx.xxxx.xxx.xx/xxxxx/xxxxxxx/xxxxx/xxxxxxxxxx_xxxxx/xxxxxx-xxxxxx.xxx
ALLEGATI F - ASSET TECNOLOGICO
CONTICKI_ModelloDiCooperazione_ATE_1.3.PDF RT Piattaforma Arpa
Vm_conticki.xlsx
Volume messaggi conticki SET19.xlsx Architettura SIM Conticki.pdf CONTICKI_Progettazione Tecnica_1.4.pdf CUP2 0_schema integrazione_v2 0.pdf CUP2.0 deploymentDiagram.jpg
Vari Schemi Dispiegamento Ambienti.PNG/JPG
ALLEGATI G - PNGLA E PRGLA
PNGLA:xxxx://xxx.xxxxxx.xxx.xx/xxxxxxx/xxxxxXxxxxx/xxxxxxxxxXxxxxxxxxxxxxXxxxxXxxxxx
.jsp?lingua=italiano&id=2824 PRGLA:
Delibera_n.604_del_06-05-2019.pdf Delibera_n.604_del_06-05-2019-Allegato-A.pdf
2 Si ritengono parte integrante del presente capitolato i documenti di definizione delle RFC pubblicati alla pagina Web:
xxxx://xxx.xxxx.xxxxxxx.xx/xXxxxxxxxxx/xxxxxxx/xxxxxxXxxxxXXX
ove si deve far riferimento all’ultima release vigente alla data di pubblicazione del presente bando, relativamente alle seguenti RFC:
RFC 246 di Processo del ciclo prescrittivo: prenotazione, presa in carico, erogazione
RFC 231 di gestione erogazione e-prescription
RFC 245 per il calcolo del ticket
RFC 244 delle Agende al fine di recepire le informazioni di base che consentano ai CUP locali di II livello di mantenere lo svolgimento delle funzioni di Cassa, Accettazione, Erogazione, Integrazione con i verticali
RFC 127 di gestione posizioni debitorie con IRIS
RFC 145 di gestione pagamenti con IRIS
RFC 75 di gestione di messaggistica SMS
3 Si ritengono parte integrante del presente capitolato i seguenti documenti di definizione dell’ambiente tecnologico di riferimento pubblicati alla pagina Web:
xxxx://xxxxxxx.xxxxx.xxxxxxx.xx/xxxxx.xxx/xxxxxxxxxxxxxx-xxx/
alla voce “Documenti Compliance ICT” ove si deve far riferimento all’ultima release vigente alla data di pubblicazione del presente bando.
● Linee Guida Tecnologiche. ll documento contiene le specifiche tecniche per la progettazione, l'acquisizione e l'implementazione di automazioni informatiche.
● CAST Specifica Interfaccia Applicativa EventHandler. Il documento fornisce una specifica di Interfaccia Applicativa di EventHandler compliant CAST, compatibile con l'RFC98v6.
● CAST Registry OID. Il documento contiene le informazioni necessarie al governo aziendale e regionale in riferimento allo scambio di informazioni relative al Registry degli OID previsto all'interno del progetto CAST.
● CAST Descrizione del modello. Il documento riassume e descrive l'infrastruttura di Cooperazione Applicativa Sanita' Toscana (CAST), definendo le regole minime per l'utilizzo dell'infrastruttura.
● CAST Specifiche Funzionali Interoperabilità ESB. Il documento descrive l'infrastruttura di Cooperazione Applicativa della Sanita' Toscana (CAST), definendone le regole per la realizzazione dei messaggi e l'utilizzo delle metologie.
● Regole d’uso della rete InterSST. Con l’acronimo INTERSST si intende l’infrastruttura di connettività della Sanità Toscana, vigente alla data di pubblicazione del file; il documento definisce le modalità con cui i fornitori ICT devono interagire con le reti dati delle Aziende Sanitarie.
● ANAGRAFE, Guida all'implementazione della RFC249. Il documento illustra le specifiche di implementazione del Servizio Unico di Accesso all'Anagrafe dei Soggetti SSR.
La documentazione comprende: Guida RFC 249 ver.1.8;
Allegato A ver.1.0 alla Guida RFC 249 - Linee guida per l'interoperabilità; Allegato B ver.1.0 alla Guida RFC 249 - Ruoli nei progetti.
La Guida RFC 249 si pone come uno strumento interpretativo della RFC 249 lato applicazioni verticali, ed ha lo scopo di chiarire come un verticale debba interfacciarsi via RFC 249 con il Servizio Unico di Accesso esposto dall'Anagrafe Pazienti Centrale (APC) attualmente sincronizzata via RFC 248 ("in circolarità") con altri APC MPI. L'Allegato A alla Guida RFC 249 ha l'obiettivo di fornire linee guida generali per consentire di gestire gli scenari di interoperabilità tra software dipartimentali nella fase di dispiegamento della RFC 249, descrivendo in particolare gli scenari più comuni, e evidenziando i comportamenti necessari per mantenere le integrazioni coerenti e sostenibili.
L'Allegato B alla Guida RFC 249 ha l'obiettivo di inquadrare i ruoli interni di ICT ESTAR rispetto alla interoperabilità anagrafica diretta e derivata, nell'ambito dei progetti del piano strategico ICT.
4 Si ritengono parte integrante del presente capitolato i file sorgenti reperibili all’indirizzo: xxxx://xxxxxxx.xxxxx.xxxxxxx.xx/xxxxx.xxx/xxxxxxxxxxxxxx-xxx/
alla voce “Documenti Generali/Progetto ContickiCUP20” ove si possono reperire sia i file sorgenti che l’intera documentazione del software a disposizione.