CAPITOLATO TECNICO PER LA FORNITURA DI UN SOFTWARE DI GESTIONE DELL' ASSISTENZA INTEGRATIVA E DELLA DISTRIBUZIONE PER CONTO DA DESTINARE ALLE AZIENDE SANITARIE DELLA REGIONE TOSCANA
- Allegato A alla CPM -
CAPITOLATO TECNICO PER LA FORNITURA DI UN SOFTWARE DI GESTIONE DELL' ASSISTENZA INTEGRATIVA E DELLA DISTRIBUZIONE PER CONTO DA DESTINARE ALLE AZIENDE SANITARIE DELLA REGIONE TOSCANA
PREMESSA
INDICE
1. RICOGNIZIONE ATTUALI SOFWARE DI “GESTIONE ASSISTENZA INTEGRATIVA E DISTRIBUZIONE PER CONTO” E VOLUMI DI ATTIVITA’
2. OGGETTO DEL CONTRATTO
3. REQUISITI FUNZIONALI (Caratteristiche del prodotto)
3.1 Creazione e gestione utenti
3.2 Tipologie di utenti da abilitare
3.3 Integrazioni
3.4 Estrazione e visualizzazione dei dati
3.5 Funzioni specifiche
3.5.1 Piattaforma per l’assistenza integrativa
3.5.1.1 Autorizzazione
3.5.1.2 Erogazione
3.5.1.3 Contabilità economica
3.5.2 Piattaforma per Distribuzione Per Conto (DPC)
3.5.2.1 Contabilità economica
3.6 Interoperabilità e RFC
3.6.1 Integrazione anagrafe unica regionale
3.6.2 Integrazione Conticki
3.6.3 Integrazione con e-prescription
4 FLUSSI
5 ARCHITETTURA E INFRASTRUTTURA DI RIFERIMENTO
6 SPECIFICHE TECNICHE E PERFORMANCE ATTESE
7 GESTIONE DELLE UTENZE E TRACCIAMENTO ATTIVITÀ
8 PROGETTO
9 MANUTENZIONE E ASSISTENZA
9.1 Descrizione dei Servizi e dei Livelli di Servizio
9.1.1.1 Livelli di criticità
9.1.1.2 SLA Richieste
9.1.1.3 Misurazione dei Livelli di Servizio
9.1.1.4 Manutenzione ordinaria
9.1.1.5 Manutenzione correttiva
9.1.1.6 Manutenzione normativa
9.1.1.7 Manutenzione evolutiva
9.1.1.8 Modalità di segnalazione del guasto
9.1.1.9 Punto Unico di Contatto (PUC)
9.1.1.10 Servizi di Reporting
9.1.1.11 Modalità di intervento
9.1.1.12 Servizi aggiuntivi
9.1.1.13 Acquisto del servizio
10 OMISSIS
11 OMISSIS
12 OMISSIS
13 OMISSIS
14 RECUPERO DATI PREGRESSI
14.1 Storico
14.2 Anno in corso
15 OMISSIS
16 PROVE, VERIFICHE E COLLAUDO
17 MODALITÀ DI FORNITURA DEL SOFTWARE
18 INSTALLAZIONE
19 FORMAZIONE
20 FASE DI AVVIAMENTO DEL CONTRATTO
21 COLLAUDO FINALE – TEST DI ACCETTAZIONE
22 TEMPISTICHE
23 OMISSIS
PREMESSA
La Regione Toscana, con DGRT n. 515 del 15/05/2017, ha approvato la revisione del Piano Strategico ICT per il triennio 2017 - 2019, prevedendo al riferimento n. T36 la realizzazione di un progetto inerente l'aggiudicazione di un applicativo per la gestione dell' Assistenza Integrativa e della Distribuzione per conto (DPC), da destinare alle Aziende Sanitarie della Regione Toscana.
L’obiettivo della presente gara è quindi quello di individuare il software di riferimento, che preveda un’unica installazione di prodotto multi aziendale, configurabile per azienda. Il software dovrà essere installato presso il Cloud di Estar (Tix o altro).
Questo obiettivo scaturisce dalla necessità di rendere omogenei i costi su tutto il territorio regionale, con possibilità di confronto fra area territoriali, di rendere agevole la gestione della mobilità sanitaria sia regionale che extra-regionale e di permettere una analisi a livello regionale in modo da poter valutare i consumi per benchmarking e quindi di garantire la continuità assistenziale all’interno di tutta la regione
In considerazione della complessità del progetto, si prevede la messa a regime del software in un tempo massimo di 60 giorni lavorativi dalla data di stipula del contratto di adesione alla Convenzione, con la possibilità di adesione scaglionata delle Aziende USL. secondo i due tipi di software a gara.
Si evidenzia che le prestazioni oggetto del presente capitolato hanno natura intellettuale consistendo nello sviluppo di un software e tipologie di manutenzione a canone e nella manutenzione evolutiva.
Tutti i dati e le informazioni afferenti alla gestione ricavabili dal presente programma restano di esclusiva proprietà dell’Azienda USL committente.
1 RICOGNIZIONE ATTUALI SOFTWARE DI "GESTIONE ASSISTENZA INTEGRATIVA E DISTRIBUZIONE PER CONTO" e VOLUMI DI ATTIVITA’
Nel presente capitolo si riportano alcuni dati relativi al contesto attuale, valutato attraverso gli attuali sistemi, al fine di permettere il dimensionamento complessivo del sistema unico di futura acquisizione.
I software attualmente utilizzati dalle strutture del Dipartimento Farmaceutico presenti sul territorio regionale sono i seguenti:
Software DPC – Tutti gli ambiti delle tre Aziende USL utilizzano il programma della ditta STUDIOFARMA denominato WebDPC
Software INTEGRATIVA :
Area | Azienda | Software | Fornitore |
Centro | USL TC – ExUSL 3 | Programma ad hoc locale | |
Centro | USL TC – ExUSL 4 | Programma ad hoc locale | |
Centro | USL TC – ExUSL 10 | Programma ad hoc locale | Distribuzione doppio canale farmacia: |
Distribuzione canale farmacia: WebCAre | Studiofarma | ||
Centro | USL TC – ExUSL 11 | Distribuzione canale farmacia: | Distribzione canale farmacia: |
WebCAre | Studiofarma | ||
Nord-Ovest | USL TNO - ExUSL1 | Distribuzione canale farmacia: | Distribzione canale farmacia: Studiofarma (solo celiachia) |
WebCAre | |||
Nord-Ovest | USL TNO - ExUSL2 | Distribuzione canale farmacia: | Distribzione canale farmacia: Studiofarma |
WebCAre | |||
Nord-Ovest | USL TNO - ExUSL5 | Distribuzione canale farmacia: | Distribzione canale farmacia: |
WebCAre | Studiofarma | ||
Nord-Ovest | USL TNO - ExUSL6 | Distribuzione canale farmacia: | Distribzione canale farmacia: |
WebCAre | Studiofarma | ||
Nord-Ovest | USL TNO - ExUSL12 | Distribuzione canale farmacia: | Distribzione canale farmacia: |
WebCAre | Studiofarma | ||
Sud-Est | USL TSE - ExUSL7 | Distribuzione canale farmacia: | Distribzione canale farmacia: |
WebCAre | Studiofarma | ||
Sud-Est | USL TSE - ExUSL8 | Distribuzione doppio canale farmacia: | Distribzione canale farmacia: |
WebCAre | Studiofarma | ||
Sud-Est | USL TSE - ExUSL9 | Distribuzione doppio canale farmacia: | Distribzione canale farmacia: |
WebCAre | Studiofarma |
Volumi di attività :
DPC ricette trattate anno 2016= 2.350.000 circa e n confezioni 3.864.000 circa Assistenza Integrativa: casi trattati per patologia anno 2016: 150.000 circa.
2. OGGETTO DEL CONTRATTO
Il presente Capitolato ha per oggetto la fornitura in locazione operativa di un software per la gestione della Assistenza Integrativa e la Distribuzione per Conto delle tre Aziende USL della Regione Toscana.
3. REQUISITI FUNZIONALI (Caratteristiche del prodotto)
La piattaforma deve avere funzionalità che consentano l’agevole gestione della erogazione della distribuzione per conto farmaci e della assistenza integrativa che in base ad accordi (aziendali o regionali) con le associazioni rappresentative delle farmacie, possono prevedere “distribuzione in nome e per conto”, “distribuzione a rimborso” oppure anche sistemi misti senza che ciò comporti oneri aggiuntivi.
Le funzionalità dovranno essere implementate in maniera parametrizzata in modo da soddisfare specifiche del committente, dando la possibilità di effettuare successive modifiche al fine di adeguarsi agli accordi stipulati e alle normative vigenti senza che ciò comporti oneri aggiuntivi.
La piattaforma può prevedere entrambe le linee di distribuzione DPC e integrativa o avere due linee di distribuzione divise: DPC Farmaci e integrativa con metodo DPC/rimborso/misto.
3.1 Creazione e gestione utenti
Gli utenti dovranno essere creati ed accedere alla procedura secondo le politiche di accesso ai sistemi della Regione Toscana. L’inserimento nei singoli profili sarà curato dal committente.
Il software, dove non esista un sistema centralizzato di gestione delle utenze, deve comunque essere predisposto ad integrarsi, non appena sia disponibile.
E’ richiesta la predisposizione di almeno 5 funzionalità:
• Inserimento nuovo utente
• Modifica utente
• Abilitazione utente
• Disabilitazione utente
• Reset password utente
Il sistema dovrà naturalmente gestire i ruoli, attribuibili a ciascun utente, e l’associazione dell’accesso alle funzionalità per ogni ruolo.
Dovranno inoltre essere realizzate almeno due viste con l'elenco degli utenti e l'elenco dei profili. L’accesso al sistema deve essere garantito anche in assenza di integrazione con i sistemi menzionati.
3.2 Tipologie di utenti da abilitare
Ciascun utente deve essere profilato in modo che ciascuna funzione di inserimento dati, modifica, visualizzazione, estrazione , analisi e ricerche possano essere abilitate o non abilitate secondo le indicazioni del committente. Fatto salvo che il committente possa chiedere alla ditta di aggiungere o eliminare profili utente, a seconda delle necessità, si riportano, a titolo esemplificativo e non esaustivo , alcuni profili di utenti che possono essere abilitati:
1. MMG/PLS
2. Medico specialista
3. Operatore Aziende Sanitarie
4. Grossisti
5. Esercizio sanitario / commerciali
6. Farmacie convenzionate
7. Ufficio Farmaceutico Aziende Sanitarie
8. Ufficio Farmaceutico Regionale
9. Organizzazioni sindacali provinciali/regionali.
L’accesso al sistema sarà consentito attraverso l’utilizzo di login e password. Le abilitazioni saranno gestite a livello ASL tenendo conto della normativa in materia di trattamento dei dati sensibili sanitari : il sistema deve memorizzare e loggare tutti gli accessi effettuati all’interno della piattaforma.
3.3 Integrazioni
La piattaforma deve prevedere l’integrazione con le banche dati e il relativo utilizzo dei dati che il committente ritiene utili al fine del corretto funzionamento e della validazione dei dati inseriti.
Alcune banche dati che certamente andranno integrate sono le seguenti, fermo restando la facoltà del committente di aggiungerne altre qualora venga ritenuto opportune e necessarie senza nessun onere aggiuntivo per l’azienda sanitaria. Alcune delle integrazioni potranno essere specifiche per la linea della piattaforma integrativa o distribuzione per conto:
• anagrafe regionale degli assistiti;
• anagrafe regionale dei medici specialisti e MMG/PLS;
• anagrafe farmacie con la previsione di campi non modificabili
• anagrafe xxxxxxxxx con la previsione di campi non modificabili
• anagrafe esercizi commerciali con la previsione di campi non modificabili
• dispositivi aggiudicati in gara aziendale/regionale (gestionali aziendali);
• piattaforme eventualmente adottate dalla Regione Toscana.
• sistema TS (estrazione dati e gestione della ricetta dematerializzata)
• dati derivanti dalla procedura per la gestione presidi per incontinenza domiciliare
• dati derivanti dalla procedura per la gestione della assistenza a pazienti affetti da morbo celiaco
• prevedere la possibilità di integrazione con i sistemi gestionali delle farmacie mediante specifiche tipo webservice.
• Nel caso di ticket dovuto dal paziente, il sistema dovrà invocare un servizio della piattaforma integrativa Conticki che calcolerà l’importo dovuto.
• Interfaccia gestionale delle aziende sanitarie per recupero prezzo medio ponderato
• banca dati del farmaco e del parafarmaco: tale banca dati deve essere concordata con il committente e deve essere acquistata e mantenuta aggiornata dall’aggiudicatario .
Deve essere previsto la possibilità di gestire l’inserimento dei prodotti anche in modo massivo.
3.4 Estrazione e visualizzazione dei dati
Tutti i dati alimentati nella piattaforma devono essere facilmente ricercabili, visualizzabili, analizzabili, estraibili, a disposizione degli utilizzatori nei formati dati più comuni (excel, open office, libre office, csv,). Inoltre tutti i dati devono essere estraibili dal committente con tracciato nativo e con tracciati record specifici anche alla luce della normativa regionale e nazionale .
La procedura deve mettere a disposizione dei cruscotti di sintesi parametrizzabili con i dati di spesa, del numero di confezioni, del numero di ricette/moduli, del numero dei pazienti trattati e del tipo di diagnosi per aggregazione territoriale e per tipologia di prescrittore AFT, MMG, PLS specialisti ecc., per tipo di magazzino, per farmacia , per tipo di prodotto, per tipo di erogatore, per centro erogatore e categoria.
Il sistema dovrà, inoltre, prevedere analisi di benchmark di confronto tra le Aziende USL della Regione Toscana.
3.5 FUNZIONI SPECIFICHE
La piattaforma deve prevedere sistemi per la gestione della distribuzione DPC e della assistenza integrativa.
3.5.1 Piattaforma per l'assistenza Integrativa
L’assistenza integrativa è attivata da una prescrizione medica redatta su ricettario del SSN o con moduli standard, che indicano tipologia dei prodotti e durata presunta del fabbisogno (fino ad un massimo di un anno).
La prescrizione medica di cui al punto precedente può essere spedita direttamente dai presidi aziendali oppure essere trasformata in una autorizzazione per il ritiro presso le farmacie o esercizi convenzionati.
Nel caso di consegne attraverso le farmacie/esercizi convenzionati la prescrizione viene acquisita dal personale preposto all’attività di front office del presidio aziendale per la pianificazione delle consegne .
3.5.1.1 Autorizzazione
La piattaforma deve prevedere la possibilità di registrazione dei dati di prescrizione, con eventuale possibilità di acquisire i documenti in formato immagine consegnati dall’utente e memorizzarli in apposito file server così che siano rintracciabili con il sistema di ricerca della piattaforma (per autorizzazione, per utente ecc)
La maschera di acquisizione dei dati deve prevedere i dati dell’utente, prelevati e validati dalla anagrafe aziendale (vedi integrazione dati), i prodotti prescritti, indicando , a seconda degli accordi, il codice ISO,
MINSAN, EAN e codice Nomenclatore e le quantità prescritte. Sulla base della prescrizione inserita e del periodo coperto da ciascuna dispensazione, la piattaforma calcola i piani di consegna, che contengono un numero di confezioni che approssima la quantità globale prescritta, in base al confezionamento. La maschera di data entry ai fini di registrare l’ammissione dell’utente all’assistenza e la generazione dei piani di consegna, così come le funzionalità da implementare sono modificabili in qualsiasi momento a richiesta del committente in linea con indicazioni regionali e/o obblighi normativi. Nel caso di gestione della distribuzione direttamente dai presidi dell’Azienda la piattaforma può omettere di generare il piano di consegna. Ciascun utente ha un tempo di inizio e fine del periodo autorizzato secondo la tipologia di prodotto autorizzato, all’interno del quale è possibile erogare i prodotti di ciascun tipo per singolo periodo di autorizzazione. Ciascun utente può essere associato ad un punto di erogazione (diretta mediante farmacia aziendale), in modo che sia possibile fare una previsione periodica dei fabbisogni di ciascun erogatore. I piani terapeutici potranno essere modificati dal personale autorizzato, dovranno essere consultabili anche se scaduti, e dovranno prevedere la possibilità di rinnovo automatico .
3.5.1.2 Erogazione
La piattaforma deve permettere di erogare prodotti soltanto a pazienti preventivamente ammessi alla assistenza nel periodo autorizzato. In caso di distribuzione diretta da parte dei presidi aziendali vengono registrati per l’utente i prodotti erogati e la quantità consegnata. Nel caso della consegna attraverso i centri erogatori viene registrato quanto dispensato che deve corrispondere al massimo al piano di consegna. I dati del piano di consegna sono visibili al centro erogatore su piattaforma web, richiamando o il paziente o il piano presentato dall’utente. La funzionalità in oggetto può essere in ogni momento modificata secondo indicazioni del committente, per ottenere la perfetta rispondenza alle modalità previste dalla normativa compresi gli accordi aziendali/regionali senza che ciò comporti ulteriori oneri aggiuntivi per il committente.
L’erogazione da parte dei centri erogatori può avvenire attraverso distribuzione a rimborso di prodotti di proprietà dei centri di distribuzione o distribuzione in nome e per conto di prodotti di proprietà della Azienda USL o in forma mista.
Nel caso di “distribuzione per conto” i prodotti distribuiti sono prelevati dai magazzini delle Aziende USL attraverso il distributore intermedio. La piattaforma deve prevedere la completa gestione e mappatura della filiera dei prodotti dall’approvvigionamento operato dalla Azienda USL (dal produttore ovvero dal centro unificato di acquisto), alla consegna ai distributori intermedi, fino alla consegna all’erogatore con la completa tracciatura del documento di trasporto. Deve essere prevista la eventuale gestione dei ministock di prodotti in farmacia e centri di distribuzione dei prodotti in DPC. Tale sistema di mappatura è analogo a quello previsto per i farmaci erogati in DPC. Anche nel caso di distribuzione diretta la piattaforma deve prevedere un analogo meccanismo, considerando il punto di distribuzione aziendale come un erogatore al pari del centro di erogazione territoriale.
3.5.1.3 contabilità economica
La piattaforma deve prevedere la possibilità di produrre la contabilizzazione mensile dei compensi da pagare per ciascun centro erogatore presente sul territorio della Regione Toscana, divisi per Azienda USL di residenza.
Tale contabilizzazione deve tenere conto del sistema di distribuzione adottato se “a rimborso” o “a distribuzione per conto”. Nel caso di sistema “a rimborso” deve essere computato il compenso sui prezzi previsti tenendo presente che il prezzo possa essere un prezzo netto IVA concordato, un prezzo al pubblico banca dati con sconto concordato lordo o netto IVA, un prezzo indicato da accordi regionali o eventuali prezzi liberi da parte del centro erogatore. Deve essere prevista anche una compensazione mensile per l’erogatore a scheda o presa in carico del paziente secondo accordi regionali.
Nella fatturazione deve essere prevista la applicazione di aliquote IVA agevolate per pazienti, anche diverse da quelle applicate sul prodotto dalla azienda produttrice o venditore intermedio .
Nel caso del sistema “distribuzione per conto” il compenso deve essere computato secondo le regole che vengono specificate nell’apposito accordo, ma che in generale terranno conto nel numero di erogazioni effettuate, numero di confezioni consegnate e/o del numero di pazienti serviti.
Con modalità che potranno essere stabilite in specifici accordi, il sistema potrà agire anche in maniera “mista”.
Le modalità di gestione della contabilità deve essere completamente parametrizzata in modo da implementare facilmente quanto previsto negli accordi aziendali al fine di generare automaticamente documenti di fatturazione e di rendicontazione contabile.
Per tutti gli utenti profilati deve essere possibile:
- Avere la disponibilità di Area Messaggi in cui è possibile comunicare informazioni agli altri utenti;
3.5.2 Piattaforma per la Distribuzione Per Conto (DPC)
La piattaforma per la gestione della DPC deve essere un’applicazione Web che gestisce la movimentazione di tutti i farmaci che vengono acquistati direttamente dalle Aziende USL , inviati ad un magazzino capofila e a magazzini satellite che approvvigionano le farmacie convenzionate le quali erogano i suddetti farmaci per conto dell’Azienda USL , e deve essere operativo e tempestivamente accessibile da parte di tutti gli operatori abilitati.
Il sistema deve presentare le funzionalità sotto riportate che saranno attivabili in base al profilo dell’utente:
1) Visualizzazione dell’elenco dei medicinali inclusi nell’elenco DPC vigente (minsan, specialità, principio attivo, ATC, codice complementare, data di inizio e fine distribuzione, equivalenze , livello di distribuzione, eventuali messaggi legati al prodotto, prevalenza, informazioni da banca dati relative a revoche, lotti invendibili, note aifa, limitazioni prescrittive e particolarità) e possibilità di estrazione dell’elenco DPC da banche dati regionali o di area vasta;
2) Inserimento e aggiornamento dei medicinali inclusi nell’elenco DPC vigente per tempo: possibilità di creare all’interno della lista di medicinali inclusi nell’elenco DPC vigente per tempo relazioni di equivalenza anche tra più medicinali ed evidenziare alle farmacie i prodotti sostituibili tra loro;
3) Inserimento e aggiornamento dei prezzi di acquisto/Estar per confezione e relativa data di inizio validità. Consultazione ed esportazione sia dei prezzi vigenti per tempo sia dello storico;
4) Visualizzazione elenco dei grossisti capofila e distributori intermedi con possibilità per la farmacia di selezionare quelli di riferimento e con possibilità di indicarne anche la priorità. Per la farmacia in ogni momento deve essere possibile accedere all’area grossisti capofila /distributori intermedi e modificare la selezione e/o le priorità scelte;
5) Ricerca dati farmacia da anagrafica delle farmacie. Le informazioni da inserire in anagrafica delle farmacie devono essere a discrezione della Regione /Azienda USL. Deve essere prevista la duplicazione della farmacia per cambio titolarità con trasferimento di ministock e ricette aperte e caratteristiche della farmacia;
6) Gestione Ricetta. Inserimento manuale o con lettura ottica dei dati della ricetta: possibilità di accettare ricette de-materializzate e in collegamento con sistema TS;
6.a) Codice ricetta: con allert se la ricetta risulta emessa da regione diversa o se è già stata erogata da un’altra farmacia a livello regionale, con previsione del blocco dei passaggi successivi ;
6.b) Codice fiscale assistito, codice STP, codice ENI o PSU: verifica della correttezza formale del codice inserito, blocco della spedizione della ricetta se il codice dell’assistito non è formalmente corretto;
6.c) Tipologia di esenzione, se presente;
6.d) ASL o Provincia di residenza dell’assistito
6.e) Data di prescrizione: allert e possibilità di blocco della spedizione se la ricetta risulta scaduta con data di prescrizione antecedente i 30 giorni rispetto a data di inserimento;
7) Selezione dei prodotti farmaceutici da ordinare e la loro quantità: devono essere visibili e selezionabili i prodotti inclusi nell’elenco dei farmaci DPC con visualizzazione di tutte le informazioni sul farmaco reperibili in banca dati, con possibilità di indicare eventuale clausola di sostituibilità. Nel caso in cui il prodotto indicato sulla ricetta non sia disponibile tra i prodotti dispensabili in DPC ma esista un prodotto equivalente sostituibile, il sistema deve selezionare in automatico l ‘equivalente avvisando della sostituzione con messaggio;
8) Emissione di “notifica mancante” solo nel caso di indisponibilità dei farmaci DPC: essa deve essere memorizzata, stampabile e riportare n° della notifica, codice e descrizione della farmacia, codice della ricetta, minsan e descrizione del medicinale, il dettaglio delle date in cui si è verificata la mancanza; consultazione delle “notifiche prodotti mancanti” generate dalle farmacie e totali notifiche per prodotto;
9) Possibilità di controllo incrociato tra farmaco inserito a sistema e farmaco in consegna: possibilità di blocco della spedizione della ricetta in caso di difformità;
10) Spedizione della ricetta con rilevazione ottica del codice minsan e del codice di targatura del farmaco con indicazione obbligatoria della data di spedizione: se la data di spedizione è superiore ai 30 giorni rispetto alla data di prescrizione deve essere prevista la possibilità di blocco della spedizione;
11) Calcolo Ticket: nei casi previsti dalla normativa, il sistema deve mostrare l’importo del ticket / quota di compartecipazione risultante dal sistema ConticKi/TS. Il sistema deve gestire le specifiche legate a eventuali ESENZIONI riconosciute all’assistito;
12) Modifica o eliminazione di una ricetta;
13) Possibilità di gestione della ricetta dematerializzata secondo normativa vigente con collegamento a sistema TS .
14) Possibilità di annullare un ordine già inviato prima della consegna del prodotto e gestione dell’ eventuale reso a magazzino/ministock;
15) Gestione Ministock. Per i prodotti a ministock devono essere riportate le seguenti informazioni: quantità disponibile e presente in farmacia , quantità ordinata a magazzini, quantità in arrivo che il magazzino sta spedendo, la quantità massima attribuita alla farmacia per ciascun prodotto, la quantità che fa scattare il riordino. Gestione resi dei prodotti a ministock: deve essere previsto oltre al reso per scaduti, rotti o non vendibili anche il reso per i prodotti non movimentati trascorso un determinato intervallo di tempo dal ricevimento degli stessi parametrizzabile. Possibilità di stabilire i prodotti a ministock in base ad un elenco, in base al consumato/rotazione con aggiornamenti automatici;
16) Gestione resi. Possibilità di evidenziare e trasmettere i dati relativi ai prodotti da rendere al magazzino/grossista intermedio, specificando codice ricetta, causale, lotto e scadenza del prodotto, con possibilità di esportazione e stampa del file generato. Visualizzazione attraverso appositi campi di ricerca di tutti i dati relativi ai prodotti resi con distinzione tra resi già effettuati e prodotti ancora da rendere. Deve essere possibile visualizzare lo storico dei resi effettuati fino almeno 5 anni;
17) Consultazione dei Documenti di Trasporto (bolla) emessi nei confronti della farmacia. Il sistema deve permettere di confermare le bolle tramite lettore ottico sia per intero se i prodotti ricevuti sono esattamente quelli in bolla oppure per singolo prodotto se i prodotti sono in eccesso o in difetto rispetto a quelli dichiarati in bolla dal grossista. In caso di anomalie tra i farmaci consegnati e la bolla elettronica deve essere prevista la “conferma con anomalie”, visualizzazione delle anomalie verificatesi e gestione delle operazioni di correzione necessarie;
18) Gestione dell’inventario dei magazzini e dei prodotti a ministock delle farmacie e dei magazzini. Possibilità di visualizzazione per singolo utente o generali in base al profilo del richiedente. Possibilità di esportazione file giacenze in formato elettronico.
19) Consultazione delle giacenze in tempo reale aggregate per Regione, per Aziende USL ,per singolo grossista distributore, per singola farmacia, distinte per principio attivo e specialità medicinale movimentata;
20) Calcolo della proposta di riordino per l’intervallo di date scelto (il numero dei giorni di copertura deve essere modificabile): il calcolo della proposta di riordino si deve basare sulla media giornaliera del consegnato alle farmacie evidenziando anche le notifiche di ogni singolo prodotto, moltiplicato per i giorni di copertura richiesti e tenuto conto della giacenza dell’intera raggiera comprensivo dei prodotti ordinati. Visualizzazione della proposta di riordino (singolo prodotto e quantità), eventuale modifica e conferma definitiva. Il report sia della copertura sia della proposta di riordino deve essere esportabile in formato elettronico e stampabile;
21) Calcolo automatico o manuale della ridistribuzione dei prodotti dal grossista capofila ai grossisti satelliti. Visualizzazione della ripartizione con i grossisti destinatari e le quantità per ogni singolo prodotto ridistribuite, eventuale modifica e conferma definitiva;
22) Calcolo automatico o manuale della ridistribuzione alle farmacie dei prodotti a ministock per ciascuna farmacia e per ciascun singolo prodotto con possibilità di personalizzazione;
23) Registrazione da parte del magazzino capofila (bolla di carico) dei farmaci acquistati dalle Aziende USL attraverso lettura ottica dei codici a barre e aggiornamento automatico delle giacenze con registrazione di lotto e scadenza del farmaco e codice di targatura;
24) Registrazione delle operazioni di ridistribuzione delle confezioni di medicinali dal grossista capofila a distributori intermedi satellite attraverso lettura ottica dei codici a barre e aggiornamento automatico delle giacenze con possibilità di recupero farmaci dalla filiera dei distributori;
25) Registrazione delle operazioni di ridistribuzione delle confezioni di medicinali alle farmacie; 26) Visualizzazione dell’ordine inviato dalla farmacia : esportazione e stampa;
27) Produzione dei relativi Documenti di Trasporto: consultazione , esportazione e stampa;
28) Segnalazione dei prodotti prossimi alla scadenza;
29) Visualizzazione del “Giornale di Magazzino” ;
30) Elaborazione e visualizzazione dell’andamento della spesa in base al costo di acquisto/ESTAR , del numero di confezioni, del numero di ricette del numero di assistiti trattati, del ticket riscosso, del costo del servizio complessivo aggregato sia per principio attivo sia con possibilità di scendere al dettaglio della singola specialità medicinale. I dati devono poter essere visualizzati come dato aggregato per Regione Toscana, per Aziende USL eroganti, per ex ASL, per Residenza (provincia e regione) dell’assistito;
Per tutti gli utenti profilati deve essere possibile:
- Avere la disponibilità di Area Messaggi in cui è possibile comunicare informazioni agli altri utenti;
3.5.2.1 contabilità economica
Contabilizzazione ricette : tale funzionalità deve permettere di calcolare l’importo che le Aziende USL devono rimborsare alle farmacie per il servizio reso. Deve essere consentita una sola volta al mese in un intervallo di giorni predefinito. Nel caso in cui l’ultimo giorno utile sia festivo il programma deve prevedere
automaticamente la contabilizzazione solo il giorno immediatamente successivo. Deve essere generata una predistinta che visualizzi tutte le ricette che possono essere contabilizzate con possibilità di escludere quelle che non si vogliono contabilizzare e rimandare la contabilizzazione in un altro momento sempre nell’intervallo previsto (nei mesi successivi). Deve essere generato il documento contabile definitivo comprendente le ricette selezionate dalla farmacia con possibilità di esportazione del documento contabile generato e del relativo dettaglio dei farmaci, per singola ricetta, che concorre alla composizione del documento contabile. Deve essere prevista l’estrazione di un file con i dati di tariffazione per l’invio dei dati relativi all’articolo 50 della legge 326/2003: deve essere prevista la possibilità di invio delle ricette spedite al sistema TS secondo le indicazioni SOGEI.
La fatturazione effettuata dal sistema deve essere resa possibile anche ai centri di tariffazione, associazioni sindacali, commercialisti indicati in anagrafe dalla farmacia con numerazione automatica / manuale;
Il sistema deve prevedere:
- la possibilità di emettere la fattura anche in formato elettronico e deve permettere la consultazione delle farmacie che non hanno contabilizzato in un dato periodo mobile.
-Consultazione ed esportazione in formato elettronico delle ricette contabilizzabili aggregabili secondo intervallo temporale mobile e per singola farmacia ,per Regione, per Azienda USL;
3.6 Interoperabilità e RFC
Tutte le integrazioni di seguito descritte dovranno comunque essere implementate nel rispetto di quanto indicato negli allegati: ALLEGATO B Linee_guida_IPF_v04.pdf, ALLEGATO D InterSST_Regole_uso_v.1.0 e gli allegati relativi alla Cooperazione Applicativa della Sanità Toscana (CAST) ALLEGATO C CAST-info.01.pdf, ALLEGATO C CAST-RFC-V1.0.0.pdf, ALLEGATO C CAST-SF-EventHandler-V1.1.0.pdf e ALLEGATO C CAST-SF-
V1.3.2.pdf (verificando l’esistenza di eventuali versioni aggiornate al momento dell’avvio del progetto).
I dettagli tecnici delle integrazioni devono essere oggetto dell’offerta tecnica al presente capitolato in termini di soluzione proposta e secondo le modalità di integrazione rese necessarie sulla base dei fornitori dei servizi invocati.
I costi delle integrazioni sono da considerarsi a carico dell’aggiudicatario del presente capitolato, non sono compresi i costi di fornitori terzi coinvolti. Con riferimento alle linee guida area IPF V04 si precisa che per quanto riguarda le integrazioni dei domini terzi si deve fare riferimento a quanto esplicitato nel paragrafo 5.1.1.1
3.6.1 Integrazione anagrafe unica regionale
Il sistema deve prevedere un unico archivio anagrafico per la gestione dei pazienti e consentire di disporre subito di tutte le informazioni raccolte nella storia dell’assistito.
Il sistema utilizzerà l'Anagrafe Unica Regionale come archivio dei dati anagrafici degli assistiti e più in generale di tutti i soggetti, correttamente identificati.
La comunicazione con tale archivio è definita secondo gli scenari dell' RFC 249 di Regione Toscana. La documentazione di riferimento è la seguente:
• RFC 249 disponibile su xxxx://xxx.xxxx.xxxxxxx.xx/xXxxxxxxxxx/xxxxxxx/xxxxxXXX --> Verificare in fase progettuale l’ultima versione da implementare (Standard);
• Guida implementazione RFC 249 lato verticali: il PM del Dipartimento ICT e TS di ESTAR redige e tiene aggiornata il documento (la versione allegata al presente capitolato è la1.7:ALLEGATO F Guida_Implementazione_RFC249_ServizioUnicoAccesso_AnagrafeUnicaSoggettiSSR_1.7. pdf).
3.6.2 Integrazione Conticki
Nel caso di ticket dovuto dal paziente, la procedura dovrà integrarsi con la piattaforma Conticki, che calcolerà l’importo dovuto.
Tale integrazione dovrà essere definita secondo gli scenari dell'RFC 246 di Regione Toscana. La documentazione di riferimento è la seguente:
• RFC 249 disponibile su xxxx://xxx.xxxx.xxxxxxx.xx/xXxxxxxxxxx/xxxxxxx/xxxxxXXX --> Verificare in fase progettuale l’ultima versione da implementare.
• Guida implementazione RFC 246 lato verticali: il PM del Dipartimento ICT e TS di ESTAR redige e tiene aggiornato il documento (vedi ALLEGATO H) .
3.6.3 Integrazione con e-prescription
La procedura dovrà recuperare le prescrizioni elettroniche erogate agli assistiti da parte dei medici. A tal fine si dovrà prevedere l’integrazione con l’RFC 231, che gestisce l’erogazione delle prescrizioni. La documentazione di riferimento è la seguente:
• RFC 231 disponibile su xxxx://xxx.xxxx.xxxxxxx.xx/xXxxxxxxxxx/xxxxxxx/xxxxxXXX --> Verificare in fase progettuale l’ultima versione da implementare;
• Guida implementazione RFC 231 lato verticali: il PM del Dipartimento ICT e TS di ESTAR redige e tiene aggiornato il documento (vedi ALLEGATO L) .
4. FLUSSI
La procedura oggetto del presente capitolato deve prevedere la produzione e la relativa estrazione dei flussi informativi FED e DES (Allegato I) come richiesto da Regione Toscana secondo le specifiche riportate nella delibera regionale n. 1375 del 27-12-2016 “Modifiche e integrazioni al manuale FLUSSI D.O.C.” che definisce i tracciati dei flussi in questione, in particolare Allegato A e Allegato D rispettivamente e s.m..
A completamento di quanto esposto, deve esserci sempre attinenza con quanto descritto negli allegati:
ALLEGATO B Linee_guida_IPF_v04.pdf, ALLEGATO D InterSST_Regole_uso_v.1.0 e gli allegati relativi alla Cooperazione Applicativa della Sanità Toscana (CAST) ALLEGATO C CAST-info.01.pdf, ALLEGATO C CAST- RFC-V1.0.0.pdf, ALLEGATO C CAST-SF-EventHandler-V1.1.0.pdf e ALLEGATO C CAST-SF-V1.3.2.pdf
5. ARCHITETTURA E INFRASTRUTTURA DI RIFERIMENTO
L’infrastruttura da utilizzare per il software oggetto del presente capitolato sarà messa a disposizione da ESTAR sia in termini di hardware che in termini di rete. I sistemi proposti dovranno prevedere un ambiente per ogni Azienda USL, oltre ad uno o più ambienti master (di livello regionale e/o di area vasta) ed i relativi ambienti di test.
Al fine di perseguire l’obiettivo di attivare modalità omogenee di progettazione e realizzazione dei sistemi informativi delle Aziende USL del SISRT (DGRT 752/2013), l’architettura e l’infrastruttura complessiva del sistema proposto, dovranno essere aderenti a quanto descritto negli allegati:
ALLEGATO B Linee_guida_IPF_v04.pdf e ALLEGATO D InterSST_Regole_uso_v.1.0.pdf e gli allegati C relativi all’infrastruttura CAST.
6. SPECIFICHE TECNICHE E PERFORMANCE ATTESE
Al fine di garantire un sistema che sia performante secondo le attese dell’utenza dello specifico ambito, il fornitore dovrà monitorare il sistema ed agire eventualmente a rettifica della configurazione dei sistemi affinché questi rispondano in 1 secondo sulle ricerche puntuali e al massimo 5 secondi nelle ricerche operative alle operazioni svolte dagli utenti.
Gli utenti coinvolti nell’erogazione dei servizi in oggetto di questo capitolato sono stimati in 1.800 per la distribuzione per conto, e 3.000 per l’assistenza integrativa.
7. GESTIONE DELLE UTENZE E TRACCIAMENTO ATTIVITÀ
Tutte le operazioni svolte dagli utenti dovranno essere tracciate riportando, oltre naturalmente alle informazioni relative all’utente ed alla tipologia di operazione effettuata su uno specifico dato/informazione, la data e l’ora di esecuzione. Tali informazioni dovranno essere rese consultabili solamente ad utenti abilitati.
8. PROGETTO
L’esecuzione del progetto dovrà avvenire secondo quanto indicato nello specifico allegato:
ALLEGATO A Allegato Project management – v3.pdf.
Il software con le caratteristiche funzionali richieste e gli eventuali adeguamenti, con particolare rilevanza all’attinenza alle linee guida ed agli specifici allegati tecnologici, dovrà essere disponibile entro 60 giorni lavorativi dalla data di stipula del contratto di Convenzione.
Le ditte partecipanti alla presente gara dovranno rendere disponibile alla Commissione un link cui accedere per visionare in demo il prodotto software offerto, ed un contatto per l’eventuale necessità di supporto all’accesso alla demo.
9. MANUTENZIONE E ASSISTENZA
Nei paragrafi seguenti sono dettagliate le attività richieste alla ditta appaltatrice nell’ottica di fornire un completo ed adeguato servizio di manutenzione ed assistenza, come richiesto dal presente capitolato.
Si precisa che l’Ente Appaltatore dovrà fornire ad ESTAR l’elenco dei propri tecnici assegnati a tale servizio comunicando relativo contatto e-mail e codice fiscale necessari alla profilazione per l’eventuale accesso agli apparati/software con i diritti assegnati.
Inoltre si evidenzia che il personale della Ditta Appaltatrice dovrà essere preventivamente autorizzato dall’ESTAR per poter accedere ai locali dove sono locati gli apparati qualora se ne verificasse la necessità.
Gli obiettivi della Assistenza sono così definiti:
• facilitare le diverse categorie di Utenti nell’utilizzo operativo e funzionale dei mezzi informativi e dei sistemi e servizi previsti;
• fornire in modo esaustivo tutte le informazioni e gli strumenti di supporto richiesti dagli Utenti per risolvere i problemi in modo tempestivo ed efficace;
• offrire agli Utenti tutte le informazioni che l’Azienda USL ritiene opportuno far conoscere in merito alla disponibilità di nuovi servizi o alla modifica di servizi esistenti;
• fornire manuali d'uso periodicamente aggiornati;
• garantire, alle strutture di controllo preposte, la verifica costante della qualità del servizio erogato e la conoscenza sia delle necessità che dello stato di soddisfazione degli Utenti sia dell’utilizzo che nei servizi;
• identificare e segnalare all’Azienda sanitaria la necessità di formazione, senza oneri aggiuntivi, sulla base delle informazioni ricevute dagli utilizzatori, al fine di adeguare o mantenere la competenza degli utenti e degli operatori sui servizi supportati.
Gli obiettivi della Manutenzione sono così definiti:
• mantenere operative le soluzioni software attraverso attività che assicurino in via continuativa la rimozione dei malfunzionamenti;
• risolvere, anche con eventuali soluzioni temporanee, le criticità del software o dei flussi estratti da correggersi in via definitiva con il rilascio di patch/release correttive;
• assicurare il miglioramento tempestivo delle funzionalità e delle prestazioni;
• garantire l’evoluzione tecnico funzionale della soluzione software;
• assicurare l’aggiornamento periodico della soluzione, attraverso il miglioramento della funzionalità, dell’affidabilità e dell’efficienza dei prodotti.
9.1 Descrizione dei Servizi e dei Livelli di Servizio
In questo paragrafo vengono dettagliatamente descritti i servizi oggetto dell’appalto ed i profili di servizio integranti l’offerta (SLA-Service Level Agreement) e che sono richiesti dal Committente.
9.1.1 Livelli di criticità
L'erogazione di servizi di manutenzione, assistenza e supporto da parte della Ditta Aggiudicataria deve essere orientata alla continuità del servizio offerto. Pertanto è necessario effettuare delle distinzioni di criticità tra le varie tipologie di errore/malfunzionamento in cui si potrà incorrere e a cui saranno associati SLA diversi.
Ad ogni oggetto coperto da manutenzione va associato un livello di criticità. Sono identificati i seguenti 2 livelli:
• complesso: il malfunzionamento causa fermo operativo della procedura che non permette tutte le funzionalità escluso gravità critica di cui al punto seguente.
• critico: Il malfunzionamento causa fermo operativo della procedura con impossibilità di erogare servizio al cittadino
Lo SLA riporta il livello di criticità associato ad ogni oggetto compreso nella manutenzione, ovvero sancisce i tempi massimi di soluzione degli interventi di manutenzione correttiva.
Di seguito, a scopo chiarificatore, si descrivono i parametri che caratterizzano le SLA:
• SLA-Accettazione: indica il tempo di attesa dell’utente sulla richiesta di intervento; tale tempo deve essere pressoché nullo
• SLA-Presa in Carico: indica il tempo che intercorre dalla segnalazione dell’errore a quando un tecnico prende in carico il problema.
• SLA-Risoluzione: indica il tempo che intercorre dalla presa in carico del problema alla sua risoluzione. Il tempo di risoluzione del problema si intende a partire dall'istante di accettazione della chiamata. La modalità di intervento è discrezionale per la Ditta fornitrice nella misura in cui essa consenta l'erogazione del servizio e la risoluzione del problema entro e non oltre le tempistiche previste dal livello di SLA prescelto per il sottosistema oggetto dell'intervento stesso, e consistentemente con le tipologie di intervento specificate dal Committente per tale sottosistema. Laddove richiesto, la Ditta aggiudicataria si può avvalere di un servizio di Help Desk al fine di risolvere problematiche comuni risolvibili dall'utente con l'aiuto di un operatore, oppure, ove specificamente consentito dall'Azienda USL/ESTAR, si può avvalere di un servizio di assistenza remota per risolvere problemi per i quali non è necessario un intervento on site.
Si rende noto e si evidenzia che l’Ente Appaltante accetta che ci sia una percentuale minima (vedi paragrafo successivo) di casi in cui le SLA non vengono garantite, superata la quale verrà attivato il meccanismo delle penali.
9.1.2 SLA Richieste
Nell’ambito di questo capitolato si richiede alla Ditta aggiudicataria di essere in grado di fornire due livelli di SLA, a seconda che l’errore/malfunzionamento sia:
• Critico
• Complesso
Di seguito la tabella riassume i parametri che caratterizzano i livelli di Servizio offerti:
Livello di Criticità | Descrizione della Criticità | SLA- Risoluzione Standard * | SLA- Risoluzione Limite ** | SLA- Accettazion e | SLA- Presa in Carico |
GRAVITA' 1 CRITICO | Fermo operativo della procedura con impossibilità di erogare servizio al cittadino | Soluzione garantita entro 2 ore lavorative | Soluzione garantita entro 4 ore lavorative dalla presa in carico | Immediata | Immediata |
GRAVITA' 2 COMPLESSO | Fermo operativo della procedura che non permette tutte le funzionalità escluso gravita1 | Soluzione garantita entro 8 ore lavorative | Soluzione garantita entro 12 ore lavorative dalla presa in carico | Immediata | Immediata |
* il tempo di risoluzione deve rispettare i Tempi indicati almeno nel 90% dei casi su base mensile.
** il tempo di risoluzione deve rispettare i Tempi indicati nel 100% dei casi su base mensile.
Si evidenzia che rientrano negli SLA anche le chiamate di assistenza e manutenzione successive all'installazione di una nuova release o di un aggiornamento di ambienti tecnologici, server, etc....
Per il calcolo dei livelli di servizio 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 (solo per un servizio H24x365GG il calcolo del tempo di risoluzione non deve prevedere interruzioni).
Nel caso in cui il fornitore della manutenzione riscontri che la risoluzione della problematica sia completamente di competenza di fornitori terzi tali chiamate possono essere escluse dal Calcolo degli SLA, ma devono comunque essere riportate – in elenco a parte – nella rendicontazione trimestrale che deve sempre contenere TUTTE le chiamate aperte dal Cliente.
Si evidenzia che nel caso in cui il fornitore della manutenzione riscontri che la risoluzione della problematica sia completamente di competenza di terzi sono definiti dei livelli di servizio diversi che devono comunque essere rispettati. Si prevedono infatti i seguenti livelli di servizio per la sola presa in carico del problema (si intende per Tempo di presa in carico il tempo che intercorre tra la ricezione della segnalazione di un problema e il re-inoltro della segnalazione a terzi). Nel caso di integrazioni con terze parti, dove la ricerca del problema viene di norma fatta in modo congiunto tra le parti, la chiusura del ticket per escalation a terzi non esonera il fornitore dall’effettuare tutte le attività necessarie a supporto [informazioni, dati, test ecc..] raccordandosi direttamente con le software house interessate.
* da rispettare almeno nel 90% dei casi
**da rispettare nel 100% dei casi
9.1.3 Misurazione dei livelli di servizio
Questa attività si rende necessaria per il controllo sulla conduzione del contratto e il monitoraggio del servizio offerto all’utente.
A questo proposito:
• il personale di ESTAR e delle Aziende USL deve avere la possibilità monitorare i ticket, compresi gli avanzamenti di stato, presenti nella piattaforma di trouble-ticketing del fornitore;
• il Direttore dell’Esecuzione per le diverse Aziende USL effettuerà la verifica del rispetto dei livelli di servizio e il calcolo delle eventuali penali;
• la verifica dei livelli di servizio avverrà trimestralmente a partire dalla reportistica inviata dal fornitore;
• Il Fornitore deve fornire il Rapporto sui Livelli di Servizio e il Rapporto sull’Attività erogata trimestralmente, entro i primi 5gg lavorativi del mese successivo, da allegare alla fattura con un format che deve contenere ALMENO le informazioni e i conteggi.
Il Direttore dell’Esecuzione (DEC) analizzerà i dati forniti verificando la completezza e la correttezza dei dati forniti a suo giudizio. Il Direttore dell’Esecuzione si riserva di effettuare verifiche a campione sulle chiamate effettuate e sui tempi di chiusura indicati nei report.
Il mancato rispetto dei livelli di servizio concordati potrà dare luogo all’addebito di penali come esplicitato di seguito.
9.1.4 Manutenzione ordinaria
Deve essere garantita senza oneri aggiuntivi la manutenzione di tipo ordinario che comprende tutti gli interventi sul Programma volti a consentire il corretto funzionamento con altri software presenti sulla postazione e con i sistemi operativi aggiornati rispetto a quelli previsti dal contratto di licenze, anche sulla base di segnalazioni ricevute.
È realizzata ciclicamente su base temporale, ovvero a scadenze regolari. Le linee guida distinguono due tipi di manutenzione ordinaria:
• programmata, ovvero basata sul tempo, che prevede interventi con cadenza regolare e verifiche determinate da elenchi prefissati;
• di revisione, ovvero finalizzata ad assicurare aderenza delle procedure all’evoluzione dell’ambiente tecnologico, ad es: aggiornamento di versioni del sw di base.
Rientra nella manutenzione ordinaria tutta l’attività di profilazione utenti e comunque di generica configurazione (parametri, dizionari) laddove il software non sia dotato di funzionalità applicativa o nel caso in cui i moduli da utilizzare risultino oggettivamente difficili da utilizzare in termini di rapporto tra il dato da immettere il numero di passaggi da fare nell’applicativo.
9.1.5 Manutenzione correttiva
Deve essere garantita senza oneri aggiuntivi la manutenzione correttiva che prevede l’attività di manutenzione realizzata in risposta a malfunzionamenti e/o non rispondenza a specifiche applicative o di flussi, sulla base dei test o delle segnalazioni fatte, da realizzarsi entro i tempi previsti dagli SLA contrattualizzati. Rientrano nella manutenzione correttiva tutti gli interventi necessari alla sistemazione dei dati sul database laddove la causa sia direttamente imputabile ad un malfunzionamento dell’applicativo o ad una integrazione con altri software.
9.1.6 Manutenzione normativa
Deve essere garantita senza oneri aggiuntivi la manutenzione normativa che prevede l'effettuazione degli interventi che si rendono necessari per garantire il rispetto della normativa europea, nazionale, regionale ed aziendale del sistema oggetto del presente capitolato. Tale manutenzione è comunque dovuta dal fornitore entro tempi da concordare con la stazione appaltante
In tal senso la Ditta Aggiudicataria dovrà provvedere ad applicare le modifiche necessarie al prodotto offerto in modo da renderlo perfettamente aggiornato, sia dal punto di vista tecnico che legale. In questo contesto sono da considerarsi comprese anche tutte le attività relative all’adeguamento/aggiornamento delle basi dati/archivi utilizzati dall’applicazione oggetto dell’appalto.
9.1.7 Manutenzione evolutiva
La manutenzione evolutiva dovrà essere realizzata programmando interventi mirati all'evoluzione dei sistemi, al turning delle performances, all'adeguamento tecnologico, al coordinamento funzionale con altri sistemi/servizi.
9.1.8 Modalità di segnalazione del guasto
Fondamentale per la corretta gestione del servizio di manutenzione è la realizzazione di un efficiente servizio di comunicazione tra la stazione appaltante e l’esecutore della manutenzione attraverso un punto unico di contatto (PUC) per tutte le problematiche connesse all’utilizzo del software oggetto del presente appalto.
Tale servizio deve essere disponibile per accettazione delle chiamate ed esecuzione dei necessari interventi a copertura degli orari riportati di seguito:
• Dal lunedi al sabato ore 8.00 alle ore 20.00
9.1.9 Punto Unico di Contatto (PUC)
La ditta Aggiudicataria deve fornire un Punto Unico di Contatto che avrà il compito di ricevere tutte le richieste del Committente sia relative ai nuovi sviluppi che alle segnalazioni di errore e malfunzionamento. Il suddetto PUC potrà essere contattato:
• via telefono (numero verde)
• via e-mail
• via applicazione web
9.1.10 Servizi di reporting
La ditta aggiudicataria deve prevedere dei metodi di accesso ai servizi di reporting; il fornitore deve infatti predisporre una serie di reports in formato elettronico, che la stazione appaltante possa rielaborare, sull'andamento della manutenzione, da aggiornare almeno una volta ogni mese solare. Confronta punto 9.1.3
9.1.11 Modalità di intervento
Si richiede che il fornitore, nell’ambito delle attività di manutenzione/assistenza, sia in grado di intervenire nei seguenti modi:
• intervento da remoto in totale autonomia
• intervento da remoto con supporto di altre risorse
• intervento on-site in totale autonomia
• intervento on-site con supporto di altre risorse
La scelta della modalità di intervento per ogni singolo caso è demandata al fornitore stesso purché il problema venga risolto nel rispetto delle SLA richieste (vedi cap 9.1.2)
L'impossibilità di intervento da remoto, qualsiasi sia la causa, non può costituire in alcun caso motivo di modifica dei tempi di intervento garantiti. In tali situazioni, l'aggiudicatario deve garantire l'immediato intervento on-site.
Qualsiasi intervento, da remoto oppure on-site, deve essere concordato con i sistemisti della stazione appaltante, che devono garantire accesso al site se necessario ed attivarsi quali coordinatori dell’intervento, e deve generare a carico dell'aggiudicatario un completo report in formato elettronico da inoltrare in tempo reale alla stazione appaltante.
L’aggiudicatario deve comunicare alla stazione appaltante anche la risoluzione della problematica con la descrizione del problema riscontrato.
9.1.12 Servizi aggiuntivi
• Manutenzione Evolutiva del software in esercizio e Attività Sistemistiche, DBA, etc...
• Attività di Formazione e Addestramento
• Gestione del RDMBS/DB Server e/o degli application server
Nel caso di servizi aggiuntivi la proposta della ditta aggiudicataria, ferme restando le quotazioni economiche offerte in sede di gara, sarà preventivamente oggetto di analisi di coerenza e congruità complessiva da parte del RES in relazione all’intervento da realizzare.
Quanto sopra descritto, dovrà essere conforme naturalmente a quanto descritto ALLEGATO B Linee_guida_IPF_v04.pdf; la descrizione invece della modalità di gestione delle MEV (Manutenzioni evolutive) trova la sua descrizione nell’ ALLEGATO G CAM_Procedura_Gestione_Manutenzione_Evolutiva.pdf
9.1.13 Acquisto del servizio
Le Aziende USL non assumono alcun impegno per l’acquisto di attività di Manutenzione Evolutiva o di altro servizio aggiuntivo.
L’indicazione dell’impegno per tipologia di figura professionale deve intendersi unicamente allo scopo di determinare una quantità di giorni uomo che sarà considerata dal committente disponibile e utilizzabile fino ad esaurimento. I giorni uomo disponibili si ridurranno con l’addebito a consuntivo, da parte del fornitore, dei servizi formalmente richiesti con un ordine specifico. Qualora sia necessario impiegare un numero di giorni uomo superiore rispetto a quanto previsto, dovranno essere definiti specifici accordi per la quota eccedente.
Gli interventi di Manutenzione Evolutiva sono regolati dalla Procedura Autorizzativa della Manutenzione Evolutiva riportata nell’ ALLEGATO G
CAM_Procedura_Gestione_Manutenzione_Evolutiva.pdf che costituisce parte integrante del presente Contratto.
La manutenzione evolutiva può essere fatturata dal Fornitore solo ad avvenuto collaudo positivo per le modifiche al software o a fronte di rendicontazione firmata delle attività svolte On Site.
10. OMISSIS
11. OMISSIS
12. OMISSIS
13. OMISSIS
14. RECUPERO DATI PREGRESSI
14.1 Storico
Garantire la consultazione di tutti i dati relati alle registrazioni e accessi agli attuali sistemi di tutte le Aziende ed ex Aziende USL (come organizzate prima dell’01/01/2016) nei cinque anni solari precedenti alla data dell’effettiva attivazione del presente contratto. La consultazione di cui sopra dovrà essere completa di tutti i dati relativi.
Le procedure di importazione/consultazione dovranno mantenere la semantica dei dati originali. I dati dovranno essere consultabili mediante un’unica interfaccia valida per tutte le attuali Aziende USL.
14.2 Anno in corso
Migrazione dei dati e documenti degli ultimi 12 mesi precedenti sul nuovo sistema per tutte le Aziende USL. Si richiede che il fornitore entrante si accolli i costi derivanti dall’importazione di tutti i dati relativi ai sistemi in dismissione. Per quanto riguarda il popolamento iniziale dei dati si deve fare riferimento al paragrafo 6.2.1.1 delle allegate linee guida area IPF V04.
15. OMISSIS
16. PROVE, VERIFICHE E COLLAUDO
Dopo l’installazione, sarà eseguito un collaudo per azienda, che dovrà verificare la corrispondenza di tutte funzioni e quanto previsto nel capitolato tecnico d’appalto.
La procedura di collaudo dovrà essere redatta dal fornitore, e sarà definitiva solo con la validazione finale da parte del Committente che potrà richiedere le modifiche e gli aggiornamenti ritenuti necessari sulla procedura in oggetto. In caso di esito positivo sarà redatto verbale di avvenuto collaudo della procedura, sottoscritto dalle parti. In caso di esito negativo l’Azienda committente può esercitare la facoltà di:
• richiedere alla Ditta fornitrice, senza oneri ulteriori, programmi aggiuntivi idonei a porre il prodotto in grado di superare le prove di collaudo che dovranno essere realizzati entro 15 giorni lavorativi dalla fine installazione
• risolvere il contratto per tutta o per la parte di fornitura non accettata al collaudo. Le differenze di costo saranno chieste a rivalsa
La consegna, l’installazione e la messa in funzione dei prodotti sono a carico della ditta fornitrice e debbono avvenire nel pieno rispetto delle tempificazioni previste nel progetto tecnico redatto dal fornitore e delle successive pianificazioni esecutive concordate con le Aziende USL.
17. MODALITA’ DI FORNITURA DEL SOFTWARE
Tutto il software, sia applicativo che di base, i suoi prerequisiti e gli eventuali tool ritenuti necessari dovranno essere corredati di eventuale licenza d’uso. L’applicazione oggetto del presente capitolato, dovrà essere fornita come software con licenza d’uso illimitata, indipendente quindi dal numero di apparecchiature e postazioni su cui il software e’ installato e dal numero delle utenze.
18. INSTALLAZIONE
La Ditta aggiudicataria dovrà provvedere all’installazione dei moduli software oggetti del presente appalto, e di tutti i moduli aggiuntivi necessari al funzionamento della procedura entro 45 giorni lavorativi dalla data di stipula contratto di adesione alla convenzione.
Per ogni modulo installato, dovranno essere prodotte la documentazione tecnica e i manuali operativi. Tutte le spese di installazione, comprese quelle di personale, le spese di viaggio e di trasferta e tutti i servizi necessari per l'avvio del sistema informativo offerto devono considerarsi inclusi e dovranno essere descritti e quantificati. Tra questi servizi dovranno essere inclusi: l'installazione di tutti i componenti offerti, la configurazione dei sistemi, la preparazione delle banche dati, le attività di test e collaudo.
La fase di installazione si intenderà completata con la stesura del relativo verbale di installazione sottoscritto da entrambe le parti.
19. FORMAZIONE
Dovranno essere previste 8 gg di formazione per ciascuna Azienda USL il cui costo è compreso nel budget allocato per questo capitolato. La formazione dovrà essere effettuata nella sede che verrà individuata dall’ente appaltatore prima della messa in produzione della procedura.
Deve essere previsto inoltre un corso FAD che sarà valutato in sede di aggiudicazione .
20. FASE DI AVVIAMENTO DEL CONTRATTO
Si definisce fase di avviamento del contratto un periodo pari al massimo a 60 giorni lavorativi a partire dalla stipula del contratto di adesione alla convenzione.
Entro questo periodo:
• la Ditta Aggiudicataria dopo aver contattato il fornitore terze parti responsabile dell’applicazione di Anagrafe Centralizzata sviluppa per quel che le compete il software necessario all’integrazione
• la Ditta Aggiudicataria installa l’applicazione sul server messo a disposizione dal Committente
• la Ditta Aggiudicataria effettua i test funzionali e di robustezza sul software installato
• la Ditta Aggiudicataria effettua, congiuntamente al fornitore terze parti (..), i test di integrazione con l’applicazione di Anagrafe Centralizzata
• la Ditta Aggiudicataria completa le attività di formazione
In ogni caso, al termine della fase di avviamento, le parti formalizzeranno nel verbale di avvio servizio tutti gli elementi gestionali e tecnico-operativi necessari alla prosecuzione delle attività dei Servizi Integrati nel rispetto delle indicazioni emerse durante tale fase.
21. COLLAUDO FINALE - TEST DI ACCETTAZIONE
Dopo l’installazione e le altre attività descritte nel precedente capitolo, sarà valutata la corrispondenza delle funzioni a quanto previsto nel capitolato tecnico d’appalto e sarà effettuato un collaudo finale per azienda USL.
Il collaudo finale verrà eseguito sulla base della versione del Piano di Test Finale e Xxxxxxxx che, preparata dalla Ditta Aggiudicataria, è stato preventivamente validata e accettato dal Committente in fase di gara.
In caso di esito positivo sarà redatto verbale di avvenuto collaudo della procedura, sottoscritto da entrambe le parti (azienda USL e fornitore). In caso di esito negativo il Committente può esercitare la facoltà di:
• richiedere alla Ditta fornitrice, senza oneri ulteriori, programmi aggiuntivi idonei a porre il prodotto in grado di superare le prove di collaudo che dovranno essere realizzati entro 15 giorni dall’installazione.
• risolvere il contratto per tutta o per la parte di fornitura non accettata al collaudo. Le differenze di costo saranno chieste a rivalsa
La consegna, l’installazione e la messa in funzione dei prodotti sono a carico delle ditte fornitrici e debbono avvenire nel pieno rispetto delle tempistiche previste nel progetto tecnico redatto dal fornitore e delle successive pianificazioni esecutive concordate con l’Azienda USL.
22. TEMPISTICHE
In questo paragrafo vengono schematizzate le principale scadenze temporali che vincolano il fornitore nell’erogazione del servizio e che devono essere considerate date vincolanti nella preparazione del GANTT di attività che dovrà essere fornito in sede di gara.
Si fa osservare come tutte le attività previste nel GANTT di massima che segue sono previste concludersi in 60 giorni lavorativi.
Eventuali ritardi (calcolati in giorni) saranno rimesse alla Ditta Aggiudicataria; per maggiori informazioni sull’entità delle penali vedere lo specifico capitolo.
23. OMISSIS