Capitolato Tecnico

Capitolato Tecnico

Piattaforma

informatica in cloud

per la

gestione degli studi clinici

Sommario

PARTE PRIMA – PRESCRIZIONI TECNICHE 4

1. Obiettivi e finalità 4

2. Oggetto della Servizio e durata 5

3. Requisiti funzionali 7

3.1. Requisiti funzionali generali 7

3.2. Requisiti per il sistema eCRF 8

3.3. Requisiti funzionali specifici 8

4. Requisiti non funzionali 9

4.1. Aspetti generali 9

4.2. Architettura tecnologica del Sistema oggetto del Servizio 11

4.3. Servizio di migrazione delle banche dati esistenti e di recupero documenti/dati pregressi dai

sottosistemi del SIA 11

4.4. Integrazioni con altri componenti del Sistema Informativo Aziendale 12

5. Descrizione dei servizi di assistenza e manutenzione 14

5.1. Generalità 14

5.2. Manutenzione Evolutiva 17

5.3. Attività straordinarie 18

PARTE SECONDA – SPECIFICHE DI GESTIONE PROGETTO 19

6. Proposta progettuale 19

7. Prodotti e tempistiche 22

8. Pianificazione del progetto 24

8.1. Analisi e Progetto Esecutivo 24

8.2. Implementazione della Piattaforma 25

8.3. Avviamento e Tuning 25

8.4. Completamento 26

8.5. Chiusura della fase di sviluppo e Collaudo Finale 26

8.6. Exit 27

9. Risorse Gestionali di Progetto 28

10. Orari di servizio 29

10.1. SLA e Penali 29

APPENDICE 1 35

APPENDICE 2 37

APPENDICE 3 - Architettura del Sistema Informativo Aziendale 38

APPENDICE 4 44

PARTE PRIMA – PRESCRIZIONI TECNICHE

1. Obiettivi e finalità

Il progetto ha come finalità la gestione informatizzata degli studi clinici condotti nella Fondazione IRCCS Istituto Nazionale dei Tumori (INT), promossi e sponsorizzati sia da esterni che dalla Fondazione INT stessa, in tutti i loro aspetti gestionali, amministrativi, regolatori, economici, nonché nella loro conduzione clinica, fino alla chiusura.

Attraverso una piattaforma informatizzata, da utilizzare come servizio in cloud (SaaS), si potranno de-

materializzare i vari processi di ideazione, fattibilità e pianificazione, approvazione, attivazione,

conduzione, rendicontazione e chiusura degli studi clinici, gestendone i contenuti e le informazioni in modo strutturato, codificato, efficiente e facilmente accessibile al personale autorizzato, garantendo nel contempo un elevato livello di integrazione, tracciabilità, privacy, affidabilità e permettendo l’estrazione e l’analisi dei dati originati a scopo di ricerca o di monitoraggio e rendicontazione.

L’implementazione di tutto quanto richiesto, dettagliato nel presente capitolato, e di seguito indicato con “piattaforma per studi clinici”, consentirà di ottenere benefici sia in termini di accesso all’informazione sia in termini di gestione del flusso di lavoro delle diverse strutture che concorrono alla realizzazione degli studi clinici.

Più in particolare si possono ipotizzare i seguente benefici:

• semplificare e migliorare i processi

• evitare le ridondanze

• abbreviare i tempi di approvazione, apertura e realizzazione degli studi clinici

• migliorare il controllo e la gestione della fatturazione e rendicontazione

• migliorare le attività di gestione e trattamento del paziente in studio.

2. Oggetto della Servizio e durata

Il capitolato ha come oggetto l’utilizzo di una piattaforma per studi clinici, come servizio in cloud (SaaS), che rispetto al processo globale e al flusso delle attività specifiche delle varie strutture coinvolte, risponda ai seguenti requisiti comuni:

• ampia integrazione e scambio di informazioni con la Cartella Clinica Elettronica (CCE) e con gli applicativi gestionali in uso, con particolare riguardo all’ERP (Oracle Application)

• possibilità di importare dati da Db già in uso nelle varie strutture, con i quali sono attualmente gestiti e monitorati gli studi

• possibilità, per ogni modulo della piattaforma, di inserimento dati in ognuna di queste modalità:

a) manualmente, b) tramite upload di file preformattati c) tramite collegamento diretto con altri Db o piattaforme preesistenti in INT

• possibilità di estrarre i dati e le informazioni inserite in formati idonei al trattamento con

software di analisi attraverso cruscotti/dashboard per analisi statistiche e reporting ad hoc per tutti i livelli interessati (dal Principal Investigator (PI) alle Direzioni strategiche)

• possibilità di controllo di scadenze (es: fatturazione, polizze assicurative, consensi informati, etc) attraverso “alert” automatici

• controlli di qualità di primo e secondo livello intrinseci alla piattaforma per il corretto

inserimento dei dati e controlli di qualità specifici definiti dai singoli utenti

• condivisione e trasparenza delle attività e responsabilità nel processo globale.

• Possibilità di sviluppo di eCRF (case report form) per la raccolta dei dati nell’ambito degli studi clinici, con eventuale integrazione e scambio di informazioni con la Cartella Clinica Elettronica

Oltre a questi requisiti comuni, la piattaforma per studi clinici dovrà soddisfare i requisiti specifici identificati dalle strutture che intervengono a vario titolo nel processo, e esplicitati nell’appendice 1.

Il progetto di realizzazione della piattaforma per studi clinici si svilupperà su un periodo di 4 anni, a partire

dalla firma del contratto, comprensivo della definizione della struttura della piattaforma, della sua

integrabilità, della pianificazione di utilizzo progressivo da parte delle varie strutture coinvolte, dell’avvio di una fase pilota, con l’upload delle informazioni già presenti nei Db esistenti, l’interfaccia con la Cartella Clinica Elettronica e la progressiva implementazione da parte delle diverse strutture, a partire da quelle il cui ruolo nel processo è di gestione documentale fino a quelle che gestiscono i trattamenti dei pazienti in studio.

La disponibilità della piattaforma

per studi clinici e la sua implementazione

nelle strutture che la

utilizzeranno dovrà rispettare le tempistiche definite al Capitolo “Prodotti e tempistiche”. Si richiede la gestione, l’assistenza, la manutenzione e l’aggiornamento di quanto in oggetto, come di seguito descritto e specificato nel presente Capitolato Tecnico.

Laddove non specificato diversamente nel presente Capitolato, le licenze d’uso devono essere disponibili

per tutto il periodo di contratto, in numero sufficiente per garantire il corretto funzionamento

dell’organizzazione degli studi clinici e del Sistema Informativo Aziendale nel suo insieme.

Nel caso in cui nel corso della durata contrattuale il numero di licenze d’uso non garantisse il normale funzionamento della piattaforma per studi clinici nella sua massima estensione prevista, sarà cura del Fornitore provvedere alla loro integrazione, a titolo gratuito, della quantità di licenze necessarie a ristabilire le condizioni di regolarità della piattaforma per studi clinici.

Deve essere garantito dal Fornitore l’aggiornamento di tutte le componenti software della piattaforma

all’ultima versione disponibile, senza oneri da parte della Fondazione, ivi comprese le major release.

Nel proseguo verranno declinati i seguenti punti:

a) requisiti funzionali (generali

presente Capitolato Tecnico.

e specifici): sono descritti nel Capitolo 3 “Requisiti funzionali” del

requisiti non funzionali: sono descritti nel Capitolo 4 “Requisiti non funzionali” del presente Capitolato Tecnico.

b) servizi di assistenza, gestione operativa e manutenzione: sono descritti nel Capitolo 5 “ Descrizione dei Servizi” del presente Capitolato Tecnico.

È facoltà del Proponente in fase di offerta ampliare, nel perimetro della propria proposta, la gamma di servizi offerti.

Tutto quanto richiesto nel presente capitolo deve essere dettagliato dal Proponente in un documento chiamato PROGETTO TECNICO-ORGANIZZATIVO.

Il servizio oggetto di gara dovrà osservare la vigente normativa in materia di protezione dei dati personali, dettata in particolare dal D.Lgs. 196/03 e s.m.i. e dal Regolamento Generale sulla protezione dei dati

personali UE 2016/679 (in breve «GDPR», General Data Protection Regulation), nonché le linee guida

regionali in materia di documenti elettronici che dovranno essere oggetto di validazione.

Le Appendici indicate nel seguito sono parte integrate del Capitolato Tecnico.

3. Requisiti funzionali

3.1.Requisiti funzionali generali

È richiesta una piattaforma per studi clinici completa di tutte le funzionalità necessarie al corretto supporto dei processi, flussi informativi e dati relativi agli studi clinici condotti presso la Fondazione per la gestione integrata della ricerca clinica.

Verrà valutata la flessibilità e copertura funzionale della piattaforma per studi clinici in termini di supporto esaustivo al flusso delle attività/funzionalità di gestione proprie delle Strutture coinvolte a vario titolo e in vari momenti nel processo di gestione degli studi e relativi flussi amministrativi, di interconnessione per la gestione di attività comuni, di integrazione con i moduli e gli applicativi già esistenti nel Sistema Informativo Aziendale, non oggetto di sostituzione, e di possibilità di estrazione di dati e informazioni ai fini di ulteriore ricerca o reportistica (cruscotti-dashboard).

Si richiedere che vengano tracciati gli accessi e le operazioni effettuate da ciascun utente/operatore che agisca attraverso la piattaforma in oggetto.

Sono requisiti funzionali generali:

• ampia integrazione e scambio di informazioni con la Cartella Clinica Elettronica (CCE) e con gli applicativi gestionali in uso, con particolare riguardo all’ERP (Oracle Application)

• possibilità di importare dati da Db già in uso nelle varie strutture, con i quali sono attualmente gestiti e monitorati gli studi

• possibilità, per ogni modulo della piattaforma, di inserimento dati in ognuna di queste modalità: a) manualmente, b) tramite upload di file preformattati c) tramite collegamento diretto con altri Db o piattaforme preesistenti in INT

• possibilità di estrarre i dati e le informazioni inserite in formati idonei al trattamento con software di analisi attraverso cruscotti/dashboard per analisi statistiche e reporting ad hoc per tutti i livelli interessati (dal PI alle Direzioni strategiche)

• possibilità di controllo di scadenze (es: fatturazione, polizze assicurative, consensi informati, etc) attraverso “alert” automatici

• controlli di qualità di primo e secondo livello intrinseci alla piattaforma per il corretto inserimento dei dati e controlli di qualità specifici definiti dai singoli utenti

• condivisione e trasparenza delle attività e responsabilità nel processo globale

3.1.1. Ricerca, estrazione di dati e informazioni con query

• Estrazioni personalizzabili dagli utenti delle varie Strutture (campi estratti “and/or”, filtri,

ordinamenti) con anche la possibilità di concatenare più campi (es. da check-list) in un unico campo testuale;

• Estrazioni statistiche personalizzabili dagli utenti che consentano di effettuare

raggruppamenti/conteggi/somme/etc. al fine statistico (es: calcolo numero di casi inseriti in un protocollo di studio o conteggio del numero di studi con determinato farmaco e/o con determinate companies);

• Generazione di documenti da condividere con i diversi utenti della piattaforma (es. fac-simili comunicazioni, fatture/storni) con archiviazione automatica di tali documenti.

• Livello di accesso alle query per gruppo di utenti selezionabile da configurazione sistema;

• Ricerca per testo e per campi codificati (anche delle check-list);

• Possibilità di esportazione dati con creazione di tabelle Excel e file di testo separato (CSV);

• Possibilità di estrazioni su indicatori di qualità e di tempistiche;

• Possibilità di ricercare in tutto l’archivio, compreso l’import da storico e database esistenti, con possibilità ricercare queste fonti dati in modo differente (marcate in fase di import);

• Il Fornitore predisporrà tutte le query e le configurazioni necessarie a soddisfare le esigenze del personale delle Strutture coinvolte durante tutta la fase di esecuzione del contratto.

3.2. Requisiti per il sistema eCRF

Il sistema di eCRF deve essere un sistema di semplice utilizzo per l’utente e deve rispondere ai requisiti di qualità richiesti in ambito della gestione degli studi clinici:

• Piattaforma validata e possibilità di validazione studio specifica con produzione di un study validation report;

• Conformità ai requisiti FDA Annex 11 and CFR 21 Part 11;

• Conformità al regolamento Europero 2016/679 (GDPR);

• Sistema semplice, intuitivo e flessibile con eventuale possibilità di “customization” interna;

• Sistema di randomizzazione integrato;

• EDIT CHECK;

• E -QUERY: Sistema integrato di gestione del cambiamento del dato;

• Audit trail esportabile con logiche di esplorazione;

• Integrazioni di dizionari Medra e CTC AE;

• Accessi profilati.

3.3.Requisiti funzionali specifici

In APPENDICE 1 parte integrante del presente Capitolato, sono descritte le Strutture e le attività da loro svolte nel processo organizzativo di riferimento: le attività sintetizzate sono da ritenersi indicative ai fini della stesura corretta e completa di una proposta di piattaforma per studi clinici che includa tutti i flussi operativi e le attività delle varie Strutture, e ne soddisfi le richieste specifiche, esplicitate in Appendice 1.

In fase di implementazione del progetto gli applicativi della piattaforma dovranno essere adattati alla realtà

organizzativa esistente delle varie priorità e tempistiche prefissate.

Strutture e alle loro richieste specifiche, in fasi successive, secondo

All’interno del PROGETTO TECNICO-ORGANIZZATIVO il Fornitore dovrà descrivere nella

“Proposta di Procedura di Processo” come l’introduzione della piattaforma per studi clinici modificherà il processo organizzativo e gestionale attuale, evidenziando le tempistiche di implementazione e gli impatti sull’organizzazione delle attività in essere per ogni singola struttura coinvolta.

.

4. Requisiti non funzionali

4.1.Aspetti generali

Il Regolamento generale sulla protezione dei dati personali UE 2016/679 stabilisce che qualora un trattamento debba essere effettuato per conto del Titolare, quest’ultimo ricorre unicamente a responsabili del trattamento che presentino garanzie sufficienti per mettere in atto misure tecniche e organizzative adeguate in modo tale che il trattamento soddisfi i requisiti del Regolamento e garantisca la tutela dei diritti dell’interessato.

Il concetto di affidabilità tocca temi fondamentali che il Fornitore deve garantire ed esplorare in sede di progettazione, quali:

• Conformità al Regolamento, secondo il principio di “privacy by design e privacy by default”,

• Memoria storica immodificabile ma annotabile,

• Controllo e tracciamento

degli accessi e delle modifiche (con numerazione della versione dei

documenti in caso di documenti validati o firmati digitalmente),

• Alta disponibilità (dati disponibili anche in caso di cadute locali di rete informatica, rete elettrica, guasto di singoli dispositivi quali server, storage, ecc.),

• Accesso al dato sempre aggiornato (evitare diverse copie non sincronizzate di dati – unicità logica del dato).

Il Fornitore della piattaforma per studi clinici deve proporre la soluzione ritenuta più idonea al contesto. Tutte le eventuali licenze software (database, applicazione) richieste per garantire la continuità di servizio sono a carico dell’Aggiudicatario.

Dal punto di vista dell’architettura applicativa la piattaforma per studi clinici deve:

• Avere una struttura modulare finalizzata all'utilizzo delle sue funzionalità nell'ambito della rete aziendale;

• Avere una struttura modulare finalizzata alla profilazione degli accessi,

• Garantire l’accesso in mobilità attraverso comunicazione con protocollo TCP/IP HTTPS e tecnologie standard;

• Avere un’architettura web-based multi browser, con possibilità di lavorare in mobilità su PC o tablet (Android, IOS, Windows);

• Supportare le interazioni

tra applicativi tramite cambio di contesto (ovvero con passaggio di

parametri chiave quali operatore, paziente e unità operativa) secondo modalità standard e facilmente implementabili come HL7-CCOW.

Il Fornitore deve garantire la disponibilità a rivedere le proprie interfacce se queste risultassero

eccessivamente complesse e di

difficile comprensione e uso per gli utenti.

È importante che le

interfacce della piattaforma per studi clinici risultino quanto più omogenee per facilitare l’uso. L’interfaccia grafica deve essere pensata per essere compatibile con la dotazione hardware della Fondazione (si veda APPENDICE 3 - Architettura del Sistema Informativo Aziendale). Deve inoltre essere garantita la compatibilità con Windows >=7 e con Microsoft Internet Explorer >=11.

Il Fornitore deve adottare e seguire appropriate procedure di analisi del rischio sui servizi/soluzioni IT

erogati. L’analisi del rischio dovrà essere condotta almeno annualmente e i risultati dovranno essere

condivisi con la Fondazione.

Considerato che l’erogazione dei servizi/soluzioni IT da parte del Fornitore comporta il trattamento di dati personali, tale trattamento è soggetto all’applicazione delle normative e delle disposizioni, sia interne sia europee, che interessano tale ambito, a partire dal “GDPR”. A tale proposito, il Fornitore riconosce e garantisce di aver fatto tutto quanto necessario al fine di conformarsi alla normativa e alle disposizioni applicabili in materia di tutela dei dati personali e/o appartenenti a categorie particolari e che qualunque operazione che comporti il trattamento dei medesimi dati da parte del Fornitore, come specificato dal presente capitolato, saranno eseguite in piena conformità al GDPR e alla normativa vigente. Nel trattamento di dati personali di cui la Fondazione è titolare realizzato in ottemperanza a quanto indicato nel presente capitolato, il Fornitore, tra gli obblighi su di esso incombenti e meglio specificati nell’atto di designazione quale Responsabile del trattamento, dovrà in particolare:

• accettare la nomina a Responsabile del trattamento dei dati personali, in relazione ai dati utilizzati per lo svolgimento del servizio affidatogli, assumendo, per l’effetto, tutti gli oneri e le responsabilità derivanti dall’assunzione di tale incarico;

• implementare tutte le misure di sicurezza in conformità alle vigenti normative nazionali ed europee in tema di protezione dei dati personali (osservando in particolare i principi di privacy by design e by default);

• nominare, all’interno del

suo organigramma, le persone autorizzate al

trattamento, tra cui gli

amministratori di sistema coinvolti nella gestione dei sistemi e implementare tutte le misure di

sicurezza in conformità al Provvedimento del Garante della Privacy sull’operato degli amministratori di sistema;

• su richiesta della Fondazione, riferire allo stesso sulle misure di sicurezza adottate;

• informare tempestivamente la Fondazione di qualsiasi circostanza rilevante in relazione al trattamento dati della Fondazione realizzato in esecuzione di quanto richiesto dal presente capitolato.

Il Fornitore deve garantire che in fase di progettazione di nuovi sistemi informativi o servizi, o miglioramenti ai sistemi informativi o dei servizi esistenti, sia eseguito un security assessment e che i controlli di sicurezza da esso scaturiti siano inclusi nei requisiti del sistema/servizio.

Il Fornitore si impegna a consegnare copia cartacea ed elettronica di tutta la documentazione utente ed amministrativa del sistema in oggetto, prima della messa in esercizio del sistema stesso, correttamente personalizzata per la propria installazione, comprensiva del dettaglio della configurazione adottata.

Il Fornitore deve garantire che durante lo svolgimento di tutte le attività collegate al servizio/soluzione IT erogato, la documentazione aziendale venga adeguatamente mantenuta, in conformità con le best practice, e che la stessa sia protetta contro accesso, uso, perdita, alterazione o distruzione impropria.

Per tutta la durata del presente contratto e successivamente alla cessazione del medesimo, per qualsiasi causa intervenuta, il Fornitore si obbliga a:

• mantenere riservati i fatti, documenti, progetti, dati e informazioni (intesi nella più ampia accezione dei termini) di cui verrà a conoscenza e/o disporrà in relazione al e/o in esecuzione del presente contratto (di seguito: Informazioni);

• non utilizzare le Informazioni per scopi diversi, in tutto o in parte, da quelli contemplati dal presente contratto;

• non divulgare o altrimenti rendere note a terzi le Informazioni, in mancanza di specifica autorizzazione.

Qualsiasi deroga alle disposizioni definite deve essere valutata ed eventualmente concessa dalla Fondazione in forma scritta.

4.2. Architettura tecnologica del Sistema oggetto del Servizio

La soluzione proposta deve essere in cloud (SaaS) così strutturata:

• la soluzione deve essere (Explorer, Mozilla, Crome);

obbligatoriamente Web Based e fruibile dai più comuni browser

• connessione VPN con linea fisica dedicata tra il Fornitore e l’Ente;

• sito di test (sempre in modalita cloud SaaS) in cui poter all’occorrenza effettuare tutte le modifiche ed implementazioni di nuove funzionalità prima di essere messe in produzione;

• alta affidabilità della soluzione

o sistema di disaster recovery

o sistema di backup dei dati

4.3.Servizio di migrazione delle banche dati esistenti e di recupero documenti/dati pregressi dai sottosistemi del SIA

Al fine di assicurare la continuità operativa ai processi amministrativi e sanitari della Fondazione, il progetto prevede che vengano acquisiti dati/archivi attualmente gestiti da quelle applicazioni che sono oggetto di sostituzione con nuovi moduli/strumenti. Questo è da dettagliare in un Piano di Migrazione preliminare, che l’aggiudicatario deve predisporre nel PROGETTO TECNICO-ORGANIZZATIVO, nel rispetto delle linee guida che seguono, con l’ausilio della Fondazione, nella fase di analisi e progettazione (si veda PARTE SECONDA – SPECIFICHE DI GESTIONE PROGETTO del presente Capitolato Tecnico). Il Piano di Migrazione verrà poi dettagliato maggiormente nel PROGETTO ESECUTIVO.

Gli oggetti del processo di migrazione sono a titolo indicativo

• Pratiche –WEB ; Emendamenti e notifiche

• Database del Clinical Trials Center

• Tariffario delle sperimentazioni cliniche

• Modulistica in uso nelle varie strutture coinvolte (elencate in Appendice1),

• Documenti amministrativi dalle bozze al documento finale (contratto, MTA, lettera contratto...),

• Modulistica varia in uso presso le strutture per la gestione degli studi clinici

In generale, le attività di analisi e la predisposizione dei programmi di estrazione/importazione dati rientrano nel perimetro di gara che, come detto, devono chiaramente essere svolte congiuntamente da referenti del

Fornitore Aggiudicatario e della Fondazione. L’Aggiudicatario deve assicurare in fase di progetto

l’assistenza tecnica nelle fasi di trasferimento dei dati e nei controlli di conformità.

A livello generale, i caricamenti “una tantum” richiesti devono essere eseguiti dall’Aggiudicatario prima della messa in esercizio della soluzione oggetto di gara e non devono richiedere alla Fondazione alcun onere

economico aggiuntivo.

4.4.Integrazioni con altri componenti del Sistema Informativo Aziendale

La soluzione proposta si deve interfacciare con i principali sistemi presenti nella Fondazione (APPENDICE 3 - Architettura del Sistema Informativo Aziendale) inclusa soprattutto la Cartella Clinica Elettronica (APPENDICE 4) in modo da consentire agli operatori di accedere dalla piattaforma per studi clinici a tutte le informazioni clinicamente rilevanti per il paziente. La piattaforma per studi clinici deve consentire di accedere direttamente ai contenuti di interesse attraverso cambio di contesto verso l’applicativo che detiene il dato/documento.

Più nel dettaglio la piattaforma per studi clinici si deve interfacciare con i seguenti sistemi:

• Active Directory aziendale.

la piattaforma per studi clinici deve integrarsi, tramite protocollo LDAP all’Active Directory

aziendale per l’autenticazione degli utenti;

• Anagrafica Aziendale (BAC).

la piattaforma per studi clinici deve garantire, tramite protocollo HL7,

l’allineamento dei dati

anagrafici dei pazienti; devono essere gestite le operazioni di inserimento, aggiornamento e unificazione di un’anagrafica.

• Repository/archivio Documenti.

la piattaforma per studi clinici deve garantire, tramite web services o protocollo HL7,

l’archiviazione di tutti i documenti prodotti. Deve essere inoltre previsto un sistema di monitoraggio a garanzia della avvenuta archiviazione di tutti i documenti.

• CUP.

la piattaforma per studi clinici deve gestire, tramite protocollo HL7, la ricezione delle liste di

pazienti in studio clinico nell’attività ambulatoriale e dell’elenco delle prestazioni erogate.

• Modulo Prescrittivo.

la piattaforma per studi clinici deve consentire, tramite cambio di contesto, la generazione e

registrazione sul SISS di ricette elettroniche a copertura di prestazioni aggiuntive;

• EPR.

la piattaforma per studi clinici deve garantire, tramite cambio di contesto gestito attraverso web services, l’accesso al Dossier del paziente.

• Cartella Clinica Elettronica.

la piattaforma per studi clinici deve consentire, tramite cambio di contesto, l’accesso al sistema di Cartella Clinica Elettronica (CCE) e, viceversa, deve consentire di essere acceduto dalla CCE per una consultazione dei dati raccolti. La piattaforma per studi clinici deve altresì trasmettere alla CCE i dati ritenuti utili attraverso protocollo standard (es. HL7) in formato strutturato.

• Data warehouse

la piattaforma per studi clinici deve prevedere un flusso di dati verso il sistema di data warehouse aziendale, questo allo scopo di poter generare dashboard per analisi statistiche e reporting ad hoc per tutti i livelli interessati (dal Principal Investigator (PI) alle Direzioni strategiche)

• Oracle eBusiness Suite

integrazione tra la piattaforma oggetto del presente capitolato e il sistema ERP aziendale (Oracle eBusiness suite 11i) per la condivisione di tariffario ed anagrafiche, entrambi esposti dall’ERP, al fine della emissione nell’ERP delle fatture attive nei confronti degli sponsor del progetto ed esposizione da parte dell’ERP del fatturato ed incassato per progetto al fine di averne evidenza nella

piattaforma oggetto del presente capitolato.

Grazie all’utilizzo di tecnologie standard (quali XX0, XXX, …) la piattaforma per studi clinici deve essere

predisposta per ulteriori nuove integrazioni con altri sistemi presenti presso la ritenesse necessario.

Fondazione qualora si

I costi di terze parti per la realizzazione delle integrazioni con i sistemi informatici di cui sopra sono a carico della Fondazione, non sono a carico dell’Aggiudicatario.

5. Descrizione dei servizi di assistenza e manutenzione

5.1.Generalità

Il servizio prevede un Service Desk di primo e secondo livello ubicato presso il Fornitore, dove saranno centralizzate le funzioni di esercizio dei sistemi oggetto del Servizio.

Il Fornitore deve prendere in carico problematiche e richieste relative a tutte le componenti costituenti il

Sistema in oggetto.

Il servizio richiesto dovrà essere svolto utilizzando un’organizzazione così articolata:

• Service Desk di primo e secondo livello sito presso il Fornitore secondo gli orari richiesti negli Orari di servizio;

Il Fornitore deve presentare in fase di offerta un documento che descriva i servizi di gestione

operativa, assistenza e manutenzione dei Sistemi, come di seguito richiesto.

Il Fornitore dovrà inoltre produrre le procedure operative necessarie, rispettando il framework ITIL, al fine di garantire i servizi richiesti con gli SLA di capitolato, definire le aree di responsabilità del processo stesso, nonché creare il manuale di tali procedure.

La Fondazione dovrà approvare il manuale delle procedure.

I servizi richiesti al Fornitore sono declinabili nelle seguenti tipologie:

• Gestione operativa dell’intero Sistema;

• Assistenza tramite Servizio di Service Desk di primo e secondo livello contattabile tramite numero verde dedicato e/o mail. Il servizio dovrà essere strutturato nel seguente modo:

• il Servizio di Service Desk del Fornitore dovrà utilizzare lo strumento di Trouble Ticketing fornito dall’Ente ed accessibile tramite interfaccia web, le eventuali licenze per l’utilizzo del strumento di Trouble Ticketing sono a totalmente carico del Fornitore;

• Il Servizio di Service Desk del Fornitore dovrà essere in grado di effettuare un Controllo Remoto sulle postazioni dell’Ente tramite software fornito dall’Ente stesso questo allo scopo di garantire la massima tempestività e capacità di monitoraggio. Per ulteriori dettagli si veda l’APPENDICE 3 - Architettura del Sistema Informativo Aziendale.

• Manutenzione (ordinaria, correttiva, normativa, adattiva, evolutiva) completa sul Sistema offerto nel Servizio);

Tutti gli interventi di rilascio di patch, nuove release, nuove funzionalità, altro, devono prevedere un’installazione preliminare nell’ambiente di test, a totale carico del Fornitore, nei termini di

predisposizione, allineamento e verifica, anche delle componenti di integrazione della soluzione

proposta con altri sistemi della Fondazione. La successiva installazione nell’ambiente di produzione è concordata con la Fondazione con adeguato anticipo allo scopo di minimizzare l’impatto sull’operatività dell’utenza.

Tutti gli interventi che prevedano di effettuare fermi programmati dei sistemi che comportino disservizio agli utenti, devono essere effettuati in opportune fasce orarie:

• da lunedì a venerdì prima delle ore 9:00 e/o dopo le ore 18:00;

• nel weekend;

salvo accordi diversi concordati caso per caso con i referenti della Fondazione.

A partire dalla data di Xxxxxxxx (collaudo finale, così come definito nel presente Capitolato Tecnico), il Fornitore deve essere disponibile a intervenire con proprie risorse specialistiche per analizzare e realizzare eventuali nuove implementazioni alle soluzioni fornite.

Il “Servizio di Gestione del Sistema” di seguito dettagliato fa riferimento a tutte le componenti della piattaforma per studi clinici.

Il servizio richiesto, di seguito dettagliato, deve garantire i seguenti processi anche tramite utilizzo di strumentazione adeguata:

• Monitoring Management

o Remote Monitoring

• Service Operations Management

o Incident Management e Problem Management

o Backup Management

• Reporting

5.1.1 Monitoring Management

Le attività di monitoring comprendono la verifica e il controllo costante del buon funzionamento del Sistema oggetto della Servizio sia dal punto di vista fisico, sia dal punto di vista logico

Ai referenti della Fondazione deve essere garantito l’accesso via Web ai sistemi di monitoring.

Il Fornitore deve inoltre mettere a disposizione uno strumento web di sintesi (dashboard) che, in un’unica videata, da concordare con la Fondazione, riassuma lo stato dei differenti alert dell’intero impianto.

Remote Monitoring:

Servizio di monitoring dell’Infrastruttura oggetto della Servizio, attuato remotamente nella sede del Fornitore dal sistema di monitoring (7x7 h24 x 365 gg.):

I tempi di intervento e/o di ripristino sono definiti in base agli SLA di capitolato.

Attività a carico della Fondazione:

• approvare le tecnologie di monitoring;

• approvare soglie di allarmi e performance sul sistema di monitoraggio;

• approvare modello report riassuntivo;

• approvare le procedure operative proposte dal Fornitore.

5.1.2 Service Operations Management

Incident Management e Problem Management:

Come definizione, il processo di Incident Management aiuta a risolvere l’anomalia o l’errore che si può verificare e a ripristinare velocemente l’erogazione del servizio.

Nell’ambito del Problem Management invece, se si sospetta di un problema ricorsivo all'interno dell'infrastruttura IT, l’analisi proattiva del problema aiuta a identificarne la causa in anticipo rispetto all’insorgenza del problema.

Una volta che le cause sono state identificate, viene presa una decisione per fare in modo che siano implementati i miglioramenti all’infrastruttura necessari a prevenire l’insorgere di nuovi incidenti.

L’attività è svolta dal personale di Service Desk di primo e secondo livello del Fornitore, esperto del Sistema oggetto della Servizio che, sulla base dei problemi individuati, apportano le modifiche necessarie alle configurazioni dei sistemi

salvaguardando al massimo l’operatività dell’impianto e, comunque, prevedendo piani malfunzionamenti.

di ripristino in caso di

Attività a carico del Fornitore:

Fase di rimozione del guasto:

• aprire (in automatico o manualmente) per ogni richiesta di incident/problem, IMAC, support, pervenuta al Service Desk, un ticket sullo strumento di Trouble Ticketing messo a disposizione dall’Ente;

• raccogliere le richieste che provengono in genere dal Service Desk INT, dai tecnici che si trovano sul campo o dai referenti della Fondazione. In questo caso deve essere comunque aperto il trouble ticket dal sistemista di presidio;

• prendere in carico, analizzare e risolvere temporaneamente o definitivamente i disservizi dovuti a malfunzionamenti del Sistema sia a livello centrale che periferico;

• eseguire attività da remoto e/o on-site a fronte di un fault dei Sistema, con strumentazione adeguata;

• operare remotamente sugli apparati e sulle componenti del Sistema per realizzare le soluzioni individuate;

• gestire i processi di escalation al suo interno o verso fornitori terzi;

• provvedere e supportare la riconfigurazione e riattivazione dei servizi;

• ripristinare la configurazione esistente in termini di utenze e servizi;

• upgrade dei software o dei

sistemi operativi degli apparati oggetto del Servizio qualora si dovessero

evidenziare bachi che ne compromettano le normali attività;

• informare la Fondazione sullo status dell’intervento e se la soluzione richiede

l’emissione di una patch

software, comunicare tempestivamente la prevista data di disponibilità della patch certificata;

• pianificare l’eventuale ulteriore intervento di installazione della patch per la rimozione definitiva del problema;

• riparare o sostituire integralmente le apparecchiature o le parti risultate difettose;

• operazioni di shutdown e restart delle componenti del Sistema;

• supportare da remoto o on-site le altre linee operative presenti presso la Fondazione durante la fase di “trouble shooting” ad esempio organizzando interventi congiunti.

• gestire problematiche legate al corretto funzionamento dei Data Base, corretta gestione ed occupazione dei tablespace, verifica della corretta indicizzazione con eventuale ricreazione degli indici stessi

Fase di chiusura guasto e gestione della documentazione:

• tenere traccia di ogni fault assegnato, dei tempi delle varie fasi di risoluzione;

• eseguire le prove di funzionalità del Sistema ai fini della certificazione di intervento eseguito positivamente;

• mantenere un database con le soluzioni dei problemi risolti;

• chiusura del trouble ticket assegnato alla propria coda di competenza dal Service Desk INT;

• fornire report riassuntivo fault, se richiesto;

• fornire una reportistica mensile sugli interventi di manutenzione straordinaria o a seguito di malfunzioni, indicando il tipo di intervento, la causa del malfunzionamento, l’ora di intervento.

I tempi di intervento e/o di ripristino sono definiti in base agli SLA di capitolato.

Attività a carico della Fondazione:

• approvare la soluzione a fronte di un fault;

• assicurare l’accesso ai locali dove necessita l’intervento;

• approvare le procedure operative presentate dal Fornitore;

• approvare modello dei report riassuntivi.

Per quel che riguarda la gestione delle componenti del Sistema definite ad alta criticità il Fornitore si farà carico dei servizi di manutenzione e assistenza tecnica alle condizione sopra descritte. La finestra d’intervento sarà però estesa h24 7X7 365 gg.

Backup Management

Il servizio si occupa di garantire, pianificare, sviluppare e verificare le procedure, atte al salvataggio e all’eventuale ripristino dei dati,

Attività a carico del Fornitore:

• configurare le procedure di backup e recovery con frequenza concordata tra Fondazione e Fornitore;

• garantire la capacità di ripristino dei dati necessari al funzionamento del servizio verificando la consistenza dei dati da sottoporre al backup;

• ripristinare i dati nel proprio Sistema;

• proporre contenuto report riassuntivi backup/restore;

• fornire report riassuntivi backup/restore;

• fornire indicazioni sulle soluzioni per migliorare le capacità di ripristino dati.

Attività a carico della Fondazione:

• approvare il modello riassuntivo dei report backup/restore;

• approvare le procedure operative presentate dal Fornitore.

5.1.3 Reporting

Il Fornitore dovrà produrre con cadenza periodica, specificata al Par. 10.1 SLA e Penali tutti i report richiesti.

Il contenuto dei report dovrà presentare informazioni chiare ed esaustive e potrà essere modificato o integrato dal Fornitore su indicazione della Fondazione che dovrà autorizzarlo.

Nell’arco della durata contrattuale, potranno essere richiesti dalla Fondazione dei Report Custom per tali richieste il Fornitore avrà 5 giorni lavorativi per produrre tali report.

Nell’arco della durata contrattuale, potranno essere richiesti dalla Fondazione ulteriori Report Ricorsivi, giornalieri, settimanali, mensili, annuali o con frequenza definita dalla Fondazione stesso. Il primo di tali report dovrà essere disponibile entro 5 giorni lavorativi dalla richiesta della Fondazione. Le modalità sono quelle indicate Par. 10.1 SLA e Penali.

5.2.Manutenzione Evolutiva

A partire dalla fase di chiusura ovvero collaudo finale (così come definita nel presente Capitolato Tecnico), il Fornitore deve essere disponibile a intervenire con proprie risorse specialistiche per analizzare e realizzare eventuali nuove implementazioni alle soluzioni fornite.

La procedura che si propone per avviare le “personalizzazioni ad-hoc”, nell’ambito del contratto di manutenzione evolutiva è qui descritta:

1. Richiesta di manutenzione evolutiva a cura del referente ICT della Fondazione verso il referente di progetto del Fornitore;

2. Presa in carico del Fornitore della richiesta di manutenzione evolutiva (entro 3 gg lavorativi dall’invio della richiesta);

3. Proposta di soluzione e valutazione economica del Fornitore in termini di giorni uomo e tempi realizzativi (entro 10 gg lavorativi dalla presa in carico);

4. In caso di accettazione da parte della Fondazione, le attività devono procedere nei tempi e con le risorse concordate;

5. Se la proposta non viene accettata vengono esaminate congiuntamente soluzioni alternative.

Alla conclusione di ogni nuova realizzazione il Fornitore deve collaudare la nuova configurazione della piattaforma per studi clinici, con la supervisione di almeno un referente ICT e uno della struttura cui la realizzazione si riferisce della Fondazione e stendere il verbale di collaudo.

Nel caso sia significativo e rilevante il contributo del personale della Fondazione o dei suoi consulenti in termini di proprio know-how e contributi allo sviluppo delle nuove funzionalità e ove questo comporti un miglioramento della piattaforma per studi clinici in termini di valorizzazione sul mercato (per es. se le migliorie introdotte diventano parte integrante di una nuova versione della piattaforma per studi clinici disponibile come prodotto commerciale e non specifico per un solo cliente), il dovuto al Fornitore da parte della Fondazione deve essere negoziato tra le parti.

5.3.Attività straordinarie

Nel caso, durante la durata contrattuale, debbano essere apportare modifiche e/o aggiornamenti che si rendessero necessari a seguito di variazioni legislative e/o normative a livello regionale, nazionale, il Fornitore dovrà farsi carico delle attività necessarie ad allineare il Sistema secondo la normativa vigente e questo senza oneri aggiuntivi a carico della Fondazione. In presenza di norme suscettibili di più interpretazioni, gli interventi di manutenzione e/o aggiornamento rifletteranno l’interpretazione della Fondazione.

Tali attività straordinarie ai punti sopra esposti dovranno essere effettuate senza oneri economici aggiuntivi a carico della Fondazione e questo sia in termini di progettazione, sia in termini di implementazione.

PARTE SECONDA – SPECIFICHE DI GESTIONE PROGETTO

6. Proposta progettuale

Il progetto di informatizzazione del percorso della ricerca clinica, oggetto del presente Capitolato, presenta caratteristiche peculiari ed elevata complessità in relazione a:

• Entità dell’intervento;

• Varietà delle aree di azione e interdipendenze tra le attività nelle diverse aree di cui si compone il progetto;

• Impatto organizzativo e sui processi primari di cura del paziente arruolato in studio clinico;

• Necessità di preservare l’operatività del servizio e la continuità delle attività di gestione degli studi clinici durante il cambiamento;

• Impatto innovativo sull’organizzazione e sui processi.

Poiché tale progetto rappresenta un importante momento di discontinuità per la Fondazione, al

Fornitore è richiesto di mettere a disposizione le competenze e le capacità di Project Management necessarie per raggiungere gli obiettivi di qualità, efficacia e rispetto dei tempi previsti, minimizzando nel contempo i disagi per i pazienti e il personale.

A fronte di ciò, il Fornitore deve dimostrare di saper mettere a frutto best practice nella gestione di progetti complessi e in particolare di essere in grado di:

• Progettare l’organizzazione e definire correttamente i ruoli e team di progetto, favorendo la collaborazione tra le persone di Fondazione e Fornitore;

• Pianificare correttamente le attività necessarie per raggiungere gli obiettivi e verificare l’avanzamento complessivo del progetto coordinandone le diverse aree;

• Definire e condividere piani operativi, di contingenza e di continuità operativa chiari e dettagliati;

• Raccogliere e analizzare i business requirements ed essere in grado di comprendere

correttamente il contesto, anticipando eventuali vincoli, criticità e opportunità di progetto;

• Produrre stime di fattibilità, stime dei costi e dei tempi;

• Gestire eventuali criticità attivando in modo tempestivo le necessarie strutture aziendali, interne ed esterne alla Fondazione, garantendo un servizio adeguato agli obiettivi della Fondazione;

• Gestire adeguatamente il transitorio di cambiamento in modo da processi primari di cura del paziente in studio;

garantire continuità nei

• Gestire le comunicazioni in modo trasparente, strutturando e attivando flussi informativi e di comunicazione efficienti tra i diversi soggetti coinvolti nel progetto;

• Supportare la Fondazione nella corretta gestione della comunicazione organizzativa;

• Formare e affiancare il personale nel cambiamento tecnologico e organizzativo.

Il Fornitore dovrà presentare, in fase di offerta, un PROGETTO TECNOLOGICO- ORGANIZZATIVO completo ed esaustivo, che tenga in considerazione le istanze sopra descritte e con indicazione chiara e strutturata di:

• Definizione dei moduli operativi che compongono il processo di ricerca clinica e che dovranno, a conclusione del progetto, essere tra loro integrati;

• Obiettivi, priorità di implementazione dei moduli, modalità operative e organizzazione del progetto;

• Modalità di interazione con tutti i soggetti coinvolti nel progetto, compresi fornitori e referenti dei sistemi attualmente in uso presso la Fondazione che devono essere oggetto di integrazione con il Sistema o saranno coinvolti a vari titolo dal progetto;

• Strumenti e documentazione a supporto delle attività di project management;

• Eventuali prerequisiti che si richiede siano previsti dalla Fondazione.

A seguito della accettazione o modifica della proposta di PROGETTO TECNOLOGICO-

ORGANIZZATIVO da parte della Fondazione, il Fornitore predisporrà un PROGETTO ESECUTIVO che verrà utilizzato come base per elaborare e rendere disponibile alla Fondazione la nuova “piattaforma per studi clinici”, corredato dalla tempistica di implementazione (Gantt).

Il Fornitore dovrà prevedere l’avviamento graduale di tutte le componenti della Piattaforma per studi clinici. La pianificazione, proposta preliminarmente dal Fornitore nel PROGETTO TECNICO-ORGANIZZATIVO, e definita nel PROGETTO ESECUTIVO, sarà validata dai referenti della Fondazione.

Per quanto riguarda la modalità organizzativa della gestione del progetto, il Fornitore dovrà indicare il nome del “Project Manager” dedicato al progetto stesso, fornendo un CV con documentata esperienza- conoscenza dell’ambito applicativo.

Al fine di perseguire quanto sopra detto, si illustrano di seguito alcuni elementi che la Fondazione ritiene indispensabile considerare per impostare una efficace gestione del progetto e che devono quindi essere adeguatamente esplorati nella proposta progettuale (PROGETTO TECNOLOGICO-ORGANIZZATIVO).

Principali attività di gestione del progetto

Il Fornitore deve presentare una pianificazione complessiva e declinare le fasi del progetto sia a livello complessivo, sia per ciascun ambito di intervento, mappando in modo chiaro le interdipendenze tra le varie fasi (Gantt, WBS). Il piano di progetto e la documentazione a corredo sulle modalità di gestione dello stesso devono rispondere in modo esaustivo alle specificità di progetto e dare un’indicazione precisa di vincoli e sinergie che sussistono con il contesto della Fondazione.

Trasversalmente alle diverse fasi, devono essere specificati meccanismi di monitoraggio di tempi, costi e qualità e devono essere formalizzati gli eventi e gli artefatti che sanciscono l’inizio e la chiusura di ciascuna fase.

In particolare, nell’ambito del progetto, la specifica struttura del Fornitore dedicata alla gestione e coordinamento delle fasi progettuali deve assicurare (al minimo):

• Il completamento del progetto nel rispetto dei tempi e costi previsti e nel rispetto dei livelli di servizio definiti nel presente Capitolato;

• L’aggiornamento costante del

piano di progetto, identificando ed evidenziando ai referenti della

Fondazione potenziali rischi e problematiche rilevanti, nonché implementando azioni correttive per la soluzione delle criticità;

• La definizione delle strutture e delle modalità organizzative di progetto;

• La gestione della comunicazione degli obiettivi, delle scadenze, dello stato di avanzamento del progetto e la condivisione delle informazioni tra i componenti dei team attivi sul progetto;

• Il coordinamento con altri progetti e programmi di sviluppo già in essere presso la Fondazione, per evitare che i benefici e gli obiettivi attesi siano compromessi da eventuali dinamiche contrastanti;

• La verifica del rispetto di standard e procedure durante l’intero ciclo di vita del progetto;

• L’aggiornamento frequente ed efficace dei referenti di progetto della Fondazione in appositi incontri di

avanzamento che devono essere coordinati e verbalizzati dal Fornitore: i controfirmati dai referenti di progetto interessati.

verbali devono essere

7. Prodotti e tempistiche

La durata totale del Contratto è di 48 mesi.

I prodotti minimi attesi per ciascuna fase del progetto e la tempistica di realizzazione sono indicati di seguito e dettagliati in maniera esaustiva nel presente paragrafo:

Fase di progetto	Tempistica	Prodotti minimi attesi
PRIMA PARTE
Avvio	T0	• Firma del contratto
Analisi e progetto Esecutivo	T0+2 (due) mese	• PROGETTO ESECUTIVO
Implementazione della Piattaforma	T0+6 (sei) mesi	• realizzazione, test e validazione delle diverse componenti della Piattaforma prima dell’Avviamento
Avviamento e Tuning	T0+8 (otto) mesi	• avviamento della Piattaforma • verbali di messa in esercizio delle Componenti avviate
Completamento di progetto	T0+10 (dieci) mesi	• completamento della Piattaforma con Verbali di messa in esercizio di tutti i componenti richiesti/forniti • gli SLA e le Penali saranno quelle definite nel presente capitolato.
Chiusura della fase di sviluppo e Collaudo Finale	T0+12 (dodici) mesi	• Manuale operativo per procedura di Processo ToBe • COLLAUDO FINALE
SECONDA PARTE
Gestione, assistenza e manutenzione	Da: (T0+12) + 36 (trentasei) mesi	• gestione, assistenza e manutenzione • gli SLA e le Penali saranno quelle definite nel presente capitolato • a cadenza trimestrale verifica dei livelli di performance/servizio e azioni correttive (Service Report) • a cadenza annuale Verifica di Continuità Operativa e di Disaster Recovery (Service Report)
Exit (Termine della durata contrattuale)	T0 + 48 (quarantotto) mesi

Tabella 1: Fasi, tempistiche e prodotti minimi attesi

A partire dalla fase di completamento di progetto e per la durata di 38 mesi, partono i Servizi di gestione, assistenza e manutenzione, come definito nel Capitolo 5.

Il Fornitore deve sostenere a suo carico qualsiasi richiesta di modifica, configurazione, sviluppo, etc. della Piattaforma, anche dovuta a difetto di analisi o a subentrate nuove esigenze (Manutenzione Evolutiva), che emerga nelle fasi di Implementazione o Avviamento ovvero prima del Collaudo Finale.

Penali su ritardo chiusura prima parte

Nel caso in cui, per motivi imputabili al Fornitore, il Collaudo Finale dovesse andare oltre 12 (dodici) mesi dalla data di Xxxxx (firma del contratto), saranno applicate le penali così come descritto: per ogni mese di ritardo rispetto alla chiusura prevista, la ditta aggiudicataria è assoggettata ad una penale pari al 2% della

quota della prima parte di progetto. A partire dal terzo mese di ritardo la penale sale al 4% della quota della prima parte di progetto.

8. Pianificazione del progetto

L’avanzamento del progetto è suddiviso in più fasi logiche, singolarmente anche molto complesse, che mirano a portare a regime la Piattaforma in oggetto, dette fasi sono distinte come sopra indicate e, per

ognuna, al Fornitore è richiesta dell’offerta.

una proposta di pianificazione di massima in

fase di presentazione

Di seguito si specificano gli aspetti che si richiede vengano recepite nella pianificazione delle attività.

8.1. Analisi e Progetto Esecutivo

Il Fornitore, in questa sede deve produrre, in seguito a una analisi dei processi, da svolgersi tramite analisi

sul campo, incontri con il gruppo

di lavoro e i referenti della Fondazione, in

tutte le strutture della

Fondazione interessate al progetto, una proposta di PROGETTO ESECUTIVO, da condividersi in appositi tavoli di lavoro con i referenti di progetto della Fondazione, che esplichi in maniera esaustiva le modalità di attuazione della Servizio in termini di attività, tempi, risorse e procedure operative.

Al Fornitore si richiede di rimappare i processi con il supporto della nuova Piattaforma integrata nel Sistema Informativo Aziendale, in accordo con le policy ICT aziendali (anche adeguandosi a vincoli posti da altri progetti in essere della Fondazione) e regionali (progetto CRS-SISS, linee guida sulla produzione dei DCE (gestione documenti padre, sostitutivi, annullativi).

A seguito delle analisi e degli incontri di cui sopra, il Fornitore dovrà riportare all’interno del PROGETTO ESECUTIVO:

• La descrizione esaustiva del progetto e delle attività di dettaglio che lo compongono opportunamente tempificate e descritte analiticamente;

• Una pianificazione delle attività, basata su ipotesi chiare, verosimili e verificate, accompagnata da un

cronoprogramma esecutivo del progetto complessivo. Questa è la declinazione di dettaglio del

cronoprogramma di massima presentato inizialmente in fase di gara;

• Le modalità previste e proposte per assicurare l’erogazione della Servizio, includendo procedure di start-up ed exit, alla descrizione tabelle attività / responsabilità / partecipazione (Fornitore – Fondazione) che chiariscano ruoli e responsabilità messe a disposizione e richieste per il progetto, con relativa quantificazione in FTE;

Tali documenti devono contenere i riferimenti a tutte le azioni necessarie per eseguire, integrare e coordinare i piani di attività relativi a tutte le fasi di intervento di cui si compone il progetto, che quindi devono essere

incluse in modo dettagliato nel piano di progetto complessivo. Tale documentazione è oggetto di

approvazione da parte della Fondazione per poter ritenere la fase conclusa.

A seguito della validazione del PROGETTO ESECUTIVO il Fornitore dovrà procedere con la revisione della “Proposta di Procedura di Processo ToBe” aggiornandola secondo il flusso di lavoro definito e rivisto nel corso dell’esecuzione del contratto per il raggiungimento della “Procedura di Processo ToBe”, che deve essere redatta entro la fase di Completamento.

8.2.Implementazione della Piattaforma

In questa fase il Fornitore deve porre in essere quanto concordato nel PROGETTO ESECUTIVO in termine di sviluppo, configurazione e inizializzazione dei sistemi, con tutte le componenti e attività previste, come ad esempio le diverse integrazioni con il Sistema Informativo Aziendale.

Il Fornitore deve provvedere, a proprio esclusivo onere, a svolgere tutte le attività di implementazione e configurazione della soluzione e quindi:

• alla configurazione della Piattaforma e alla sua personalizzazione coerentemente con i processi e i flussi di lavoro da implementare;

• alla configurazione di tutta la modulistica/documentazione oggetto del progetto di informatizzazione (soggetta a validazione dai referenti interessati della Fondazione);

• alla inizializzazione della Piattaforma con le anagrafiche e le codifiche necessarie all’abilitazione delle personalizzazioni delle singole strutture;

• alla verifica e messa in funzione della Piattaforma;

• al collaudo della piattaforma per studi clinici.

Il Fornitore deve provvedere alla formazione teorica e pratica di tutti gli utenti, secondo un Piano di

Formazione redatto dal Fornitore e concordato con la Fondazione. La formazione, in lingua italiana, deve essere esaustiva delle soluzioni proposte e deve essere prevista per tutto il personale amministrativo, tecnico e sanitario coinvolto direttamente nel progetto e nella gestione degli studi clinici e facente capo alle Strutture

descritte in Appendice 2 e inoltre per qualsiasi ulteriore operatore che la Fondazione indicherà in fase

esecutiva, inclusi i gestori/amministratori della Piattaforma

La Formazione dovrà essere erogata presso le aule didattiche della Fondazione.

Prima di poter procedere con la fase successiva si richiede che il Fornitore pianifichi la predisposizione dei test e della validazione delle diverse componenti prima dell’avviamento (si veda il paragrafo Avviamento e Tuning) che andrà condivisa con la Fondazione. Tale documentazione sarà oggetto di approvazione da parte della Fondazione per poter ritenere la fase conclusa.

8.3. Avviamento e Tuning

La fase di Avviamento deve essere presidiata on the job da personale del Fornitore in misura, qualifica ed esperienza opportune alla migliore gestione del cambiamento. Il personale sul campo del Fornitore deve, inoltre, fungere da collettore di raccolta delle segnalazioni degli operatori della Fondazione coinvolti, al fine di formalizzare le osservazioni/richieste per una successiva valutazione e gestione. Tale attività è di fondamentale importanza anche per verificare l’esistenza di criticità prima sconosciute o di margini di miglioramento dei processi e delle soluzioni, che il Fornitore è tenuto a formalizzare ed evidenziare alla Fondazione e nel caso a risolvere con oneri a proprio carico.

Al Fornitore è richiesto di collaborare con la Fondazione fornendo supporto attivo e proattivo in tutte le fasi legate all’implementazione dell’utilizzo della Piattaforma per studi clinici.

A partire dall’Avviamento il Fornitore deve garantire a proprio onere la gestione e la manutenzione dei sistemi forniti secondo quanto definito nel capitolo 5. Per ogni struttura avviata all’utilizzo della Piattaforma il Fornitore deve redigere un Verbale di messa in esercizio, sottoposto alla Fondazione per approvazione.

8.4.Completamento

Questa fase prevede il completamento graduale della messa in opera della Piattaforma per gli studi clinici in tutte le strutture coinvolte nel processo di gestione degli studi, come da PROGETTO ESECUTIVO validato dai referenti della Fondazione. In questo periodo deve essere garantito un presidio on site di personale del Fornitore in misura, qualifica ed esperienza opportune alla migliore gestione dell’implementazione della Piattaforma. Il personale sul campo del Fornitore deve, inoltre, fungere da collettore di raccolta delle segnalazioni degli operatori della Fondazione coinvolti, al fine di formalizzare le osservazioni/richieste per una successiva valutazione e gestione. Tale attività è di fondamentale importanza anche per verificare l’esistenza di criticità prima sconosciute o di margini di miglioramento dei processi e delle soluzioni, che il Fornitore è tenuto a formalizzare ed evidenziare alla Fondazione e nel caso a risolvere con oneri a proprio carico.

In questa fase il fornitore deve comunque garantire la gestione e la manutenzione dei sistemi secondo quanto definito nel capitolo 5.

Per ogni struttura in cui si è completata la messa in opera della Piattaforma per studi clinici il Fornitore deve redigere un verbale di completamento della messa in esercizio, sottoposto alla Fondazione per approvazione.

Resta inteso che il Fornitore deve implementazione e configurazione

provvedere, a proprio esclusivo onere, a svolgere tutte le attività di delle modifiche richieste, come nella fase di implementazione (es.

configurazione, inizializzazione, verifica, formazione, collaudo, etc.).

8.5.Chiusura della fase di sviluppo e Collaudo Finale

La chiusura del progetto deve avvenire entro la data stabilita nel PROGETTO ESECUTIVO, approvata dalla Fondazione.

In fase di chiusura devono essere svolte le seguenti attività:

• Verifica del livello di raggiungimento dei livelli prestazionali della Piattaforma per studi clinici;

• Analisi dei risultati e individuazione di eventuali azioni correttive;

• Adeguamento della Piattaforma alle esigenze eventualmente emerse nell’utilizzo;

I risultati di queste attività devono essere descritte in modo chiaro, conciso ed esaustivo dal Fornitore in un documento di COLLAUDO FINALE che determina il raggiungimento degli obiettivi e risultati attesi Queste attività sono da svolgersi, a cura del Fornitore, anche nella fase di manutenzione della Piattaforma per studi clinici, per assicurarne il massimo delle performance.

Al Fornitore è richiesto di presidiare il completamento di tutte le attività necessarie per la chiusura formale di quanto richiesto e quindi del Collaudo Finale,

Il Fornitore deve, a suo onere, descrivere le procedure, produrre manuali, formare gli utenti amministratori e fare tutto il necessario affinché il personale delle Strutture coinvolte nella gestione degli studi clinici sia messo in condizione di essere autonomo nelle attività di gestione della Piattaforma per studi clinici.

A partire dalla data di Chiusura, il Fornitore rimane disponibile a intervenire con proprie risorse

specialistiche per analizzare eventuali problematiche di funzionamento e per realizzare eventuali nuove implementazioni alle soluzioni fornite utilizzando il monte ore stabilito nel PROGETTO ESECUTIVO.

Per garantire la continuità operativa, a partire dalla data di chiusura e per un periodo di 2 mesi, il

Fornitore deve mettere a disposizione della Fondazione una figura on site tutor”.

junior di “Supporto e

8.6. Exit

Il Fornitore deve, a suo onere, garantire il trasferimento di tutte le conoscenze necessarie alla fluida transizione nella erogazione dei servizi e la continuità operativa per l’utenza della Fondazione. Durante la fase esecutiva di progetto è a cura del Fornitore la redazione del DOCUMENTO DI USCITA che descrive in modo chiaro, conciso ed esaustivo tutto quanto descritto in questo paragrafo.

In particolare il Fornitore si deve impegnare fino al termine del periodo contrattuale a soddisfare i seguenti requisiti generali:

• Non vi saranno impatti o interruzioni del servizio causate specificamente dalle attività di passaggio di consegne;

• Non vi saranno decadimenti dei livelli di servizio, specificamente imputabili al passaggio delle consegne e all'affiancamento del personale del Fornitore con quello subentrante;

• Dal punto di vista dell’utente finale, non vi saranno significativi cambiamenti, specificamente imputabili al passaggio delle consegne, che possano inficiare le attività operative.

Inoltre, il Fornitore deve garantire al termine della durata contrattuale prevista, la massima collaborazione

durante l’eventuale migrazione a un nuovo Sistema. Si richiede un affiancamento verso il fornitore

entrante di almeno un mese solare, nonché la consegna alla Fondazione di tutti i dati e documenti relativi agli studi clinici trattati con la piattaforma in oggetto, secondo formati standard (excel, csv, ecc...).

9. Risorse Gestionali di Progetto

Il Fornitore deve proporre una struttura organizzativa di progetto in grado di gestire opportunamente tutte le fasi previste, tramite risorse competenti e organismi dedicati alla gestione e alla conduzione delle attività. Verrà valutata positivamente l’indicazione precisa dei ruoli messi in campo, dei profili professionali, delle relative responsabilità e della quantificazione degli FTE erogati per la durata del progetto.

Il Fornitore deve proporre e concordare con la Fondazione le modalità di interazione con tutti i soggetti coinvolti a vario titolo nel progetto, compresi fornitori e referenti dei sistemi attualmente in uso presso la Fondazione che sono oggetto di integrazione con il sistema richiesto o sono coinvolti a vario titolo dal progetto.

La Fondazione mette a disposizione opportuni referenti interni a cui fare riferimento durante tutte le fasi di progetto (referenti scientifici, tecnici, amministrativi, informatici).

È chiaramente responsabilità del Fornitore adeguare le risorse utilizzate in modo tale da garantire il rispetto dei tempi e costi di Capitolato e degli SLA di Capitolato; ciò si intende in termini qualitativi - quantitativi e per tutta la durata del contratto. La Fondazione si riserva di valutare e segnalare l’inappropriatezza del personale predisposto dal Fornitore per l’erogazione del servizio e quindi richiederne e ottenerne la sostituzione.

Nel corso del progetto il Fornitore si impegna a garantire la stabilità del gruppo di lavoro. In caso di variazione al gruppo di lavoro il Fornitore deve assicurare un periodo di affiancamento per lo meno di 20 (venti) giorni lavorativi.

10. Orari di servizio

Gli orari di servizio minimi richiesti per l’attività di Service Desk sono indicati di seguito. Nell’ambito della proposta il Concorrente può estendere tali orari proponendo nuove tabelle orarie; tale estensione sarà oggetto di maggiore punteggio nel relativo criterio di valutazione.

Si precisa inoltre che nel seguito per “Reperibilità” si intende la possibilità di attivare telefonicamente una risorsa addetta al servizio di assistenza e manutenzione, che prenda in carico la richiesta e la evada secondo gli SLA sotto definiti mediante collegamento da remoto e/o interagendo telefonicamente con il richiedente oppure direttamente on site. La Reperibilità deve poter essere attivata automaticamente dai sistemi di Monitoraggio remoto predisposti per il Sistema.

I giorni di festività considerati sono i seguenti: 1 Gennaio, 6 Gennaio, Pasqua (variabile), Lunedì di Pasqua (variabile), 25 aprile, 1 maggio, 2 giugno, 15 agosto, 1 novembre, 7 dicembre, 8 dicembre, 25 dicembre, 26 dicembre.

Tale elenco sarà aggiornato nel caso in cui vengano promulgati nuovi giorni di festività nazionale.

Servizi	Orari
	Lunedì-Venerdì	Sabato	Domenica e Festivi
Service Desk	9:00 – 18:00	Non richiesto	Non richiesto
Reperibilità	24h per 365 gg
Monitoraggio remoto	24h per 365 gg

10.1. SLA e Penali

Tabella 2: Livelli minimi di servizio

Gli indicatori di Service Level Agreement (SLA) sotto indicati verranno valutati mensilmente.

Tutti i report dovranno essere prodotti dal Fornitore su base mensile (dove non diversamente specificato) e

inviati entro la prima decade del Fondazione concordato.

mese successivo all’interno di un Service Report al referente della

Tempo di presa in carico

In riferimento alla tabella successiva, per Tempo di presa in carico si intende il tempo trascorso tra la segnalazione di un guasto/problema e/o richiesta di servizio da parte della Fondazione e la presa in carico del Fornitore.

Tempo di risoluzione

Per Tempo di risoluzione si intende il tempo massimo trascorso tra la segnalazione del guasto/problema e/o richiesta da parte della Fondazione e la risoluzione definitiva che ripristina il corretto funzionamento del Sistema e lo svolgimento delle attività operative.

Grado di urgenza

Di seguito sono riportate le tempistiche (soglie limite) utilizzate come indicatori per la valutazione degli

SLA, specificate per Grado di urgenza (problema Bloccante, Grave e Lieve); il grado di urgenza è valutato sulla base della disponibilità dei sistemi ovvero sul livello di gravità del blocco delle funzionalità del Sistema e del disagio recato all’organizzazione e/o agli utenti.

m

Le ore lavorative indicate nella tabella di seguito sono da considerarsi corrispondenti agli orari di copertura del servizio di Service Desk.

Grado di urgenza	Tempo di presa in carico (Soglia limite)	Te po di risoluzione (Soglia limite)
Problema Bloccante: (Alta Criticità) malfunzionamento che impedisce lo svolgimento delle attività operative della Fondazione (es. blocco del sistema centrale, …)	½ ora	2 ore
Problema Grave: (Media Criticità) malfunzionamento che, pure non impedendo lo svolgimento delle attività oppure interessando pochi operatori, ostacola la continuità, efficienza, efficacia, sicurezza, qualità o altri attributi significativi	½ ora	3 ore
Problema Lieve: (Bassa Criticità) malfunzionamento che non ostacola il regolare svolgimento delle attività	3 ore lavorative	16 ore lavorative
IMAC	-	2 giorni lavorativi
IMAC (Urgenti)	-	8 ore lavorative

Tabella 3: Tempi di intervento e ripristino

Per problemi categorizzati come Bloccanti o Gravi i tempi indicati in Tabella 3 sono calcolati 7x7 h24 365 gg.

Indicatori complessivi di servizio e SLA

Gli indicatori complessivi di servizio sono di seguito riportati e sono misurati sulla base della disponibilità del Sistema all’utente finale, indipendentemente se la causa del disservizio sia da imputare alle applicazioni,

all’ambiente di base o ad altro delle parti comuni del Sistema; non verranno computati disservizi

manifestamente causati da componenti estranee al Servizio in oggetto.

Le ore lavorative indicate nella tabella di seguito sono da considerarsi corrispondenti agli orari di copertura del servizio di Service Desk.

Indicatori di servizio	Modalità di valutazione	SLA	Periodo di osservazione
Tempo di indisponibilità (TI)	Tempo di indisponibilità del sistema misurato nelle ore lavorative, compresi fermi per manutenzione ordinaria e straordinaria	<= 2 ore lavorative	Mensile
Tempo di Indisponibilità sistema di monitoring (TISM)	Tempo di indisponibilità di monitoring del sistema misurato h24 x 365 giorni, esclusi fermi per manutenzioni concordate	<= 2 ore lavorative	Mensile
Tempo di Presa in carico (TP)	Rispetto dei valori soglia riportati in Tabella 3: Tempi di intervento e ripristino	>= 90%	Mensile
Tempo di Risoluzione per Problemi Bloccanti (TRPB)	Rispetto dei valori soglia riportati in Tabella 3: Tempi di intervento e ripristino	Si veda Tabella 5: Calcolo delle penali	Mensile
Tempo di Risoluzione per Problemi Gravi (TRPG)	Rispetto dei valori soglia riportati in Tabella 3: Tempi di intervento e ripristino	Si veda Tabella 5: Calcolo delle penali	Mensile
Tempo di Risoluzione per Problemi Lievi (TRPL)	Rispetto dei valori soglia riportati in Tabella 3: Tempi di intervento e ripristino	>= 90%	Mensile
IMAC	Rispetto dei valori soglia riportati in Tabella 3: Tempi di intervento e ripristino	>= 90%	Mensile
IMAC (Urgenti)	Rispetto dei valori soglia riportati in Tabella 3: Tempi di intervento e ripristino	>= 90%	Mensile

Tabella 4: Indicatori complessivi di servizio

Indicatore di servizio	Valore nel periodo	Penale / Decurtazione in % o in e ro/ora del canone del servizio
Tempo di Indisponibilità (TI)	Per ogni ora o frazione successiva allo SLA	500 Euro/ora
Tempo di Indisponibilità sistema di monitoring (TISM)	Per ogni ora o frazione successiva allo SLA	300 Euro/ora
Tempo di Presa in carico (TP)	X >= 90%	0%
	90% > X >= 70%	5%
	70% > X >= 50%	10%
	50% > X	15%
Tempo di risoluzione per Problemi Bloccanti (TIPB)	Per ogni ora o frazione successiva allo SLA relativo al singolo episodio	500 Euro/ora
Tempo di risoluzione per Problemi Gravi (TIPG)	Per ogni ora o frazione successiva allo SLA relativo al singolo episodio	200 Euro/ora
Tempo di risoluzione per Problemi Lievi (TIPL)	X >= 90%	0%
	90% > X >= 70%	10%
	70% > X >= 50%	20%
	50% > X	30%
Tempo di risoluzione per Problemi Lievi IMAC IMAC (Urgenti)	X >= 90%	0%
	90% > X >= 70%	10%
	70% > X >= 50%	20%
	50% > X	30%
Ritardo di consegna Service Report	Per ogni giorno successivo al decimo giorno del mese successivo al periodo di rilevazione	100 Euro/Giorno
Insufficiente contenuto informativo del Service Report	Per ogni report dove non si riscontra il contenuto informativo concordato	100 Euro/Giorno

u

Tabella 5: Calcolo delle penali

Penali relative a disservizi causati dal Fornitore

In caso di azioni errate da parte del Fornitore, che pregiudichino la funzionalità di tutto o parte di un servizio, verrà applicata una penale di 500 Euro per ogni singolo episodio, oltre all’eventuale penale relativa allo SLA.

Audit

Inoltre durante l’esecuzione del contratto, la Fondazione potrà richiedere al Fornitore di sottostare ad attività di auditing dei servizi forniti. Tali attività potranno essere svolte dai Responsabili individuati dalla Fondazione, da persone espressamente delegate, o da una Società esterna appositamente incaricata.

Scopo delle attività di auditing è la valutazione dello stato delle attività svolte dal Fornitore e la verifica della loro conformità rispetto alla programmazione concordata e al contratto.

Le attività di auditing, che potranno avere per oggetto qualunque porzione o l’intero complesso dei servizi, potranno essere svolte con due diverse modalità su insindacabile scelta della Fondazione:

● dando al Fornitore un preavviso di almeno 15 giorni con la specificazione dell’oggetto dell’attività di auditing;

● dando al Fornitore un preavviso di un’ora senza specificare la tipologia di attività che verrà sottoposta a esame.

APPENDICE 1

Piattaforma per Studi Clinici

REQUISITI SPECIFICI IDENTIFICATI DALLE STRUTTURE CHE INTERVENGONO NEL PROCESSO DI GESTIONE E CONDUZIONE DEGLI STUDI CLINICI

STRUTTURA	REQUISITI
S.c. REFeLP:	inserimento e aggiornamento del tariffario della Fondazione INT, per una corretta formulazione del budget dello studio, tracciamento delle prestazioni attraverso il riconoscimento del paziente in studio; “correzioni” sull’attribuzione dei costi a sponsor o SSN; verifica delle scadenze per la fatturazione, e degli incassi. Estrazione dati e informazioni tramite dashboard
S.s. TTO:	interfaccia con i promotori/sponsor, con i PI e suo staff/DM e con la segreteria del CE per la condivisione della documentazione amministrativa, l’invio della determina di approvazione e dei fac-simili di comunicazioni relative alla fatturazione e alla chiusura dello studio, l’inserimento delle scadenze (polizza assicurativa, fatturazione alla sottoscrizione del contratto e alle successive scadenze contrattuali, conclusione contratto) e il monitoraggio amministrativo dello studio; archivio delle bozze dei documenti (contratto, MTA, lettere contratto, etc)
Segreteria CE:	registrazione di tutta la documentazione inviata dal promotore/sponsor per l’autorizzazione (anagrafica, tempistica, codice studio, etc); invio da parte del promotore dei documenti degli studi non farmacologici; gestione degli emendamenti, delle notifiche e tracciamento documenti; monitoraggio amministrativo dello studio (dashboard per estrazione dati); gestione sedute CE. Trasferimento dati archiviati nel gestionale “Pratiche-WEB” in uso attualmente
S.c. Farmacia:	anagrafica dell’IMP e gestione del farmaco in studio; inserimento del Form identificativo dello studio, del modulo richiesta farmaci sperimentali, del modulo di contabilità e compilazione direttamente in piattaforma; carico dei materiali forniti dallo sponsor in piattaforma; inserimento delle Linee Guida per l’allestimento del farmaco sperimentale; interfaccia con lo sponsor per l’accesso a documenti per il monitoraggio delle attività della farmacia (data log temperatura, localizzazione farmaco); gestione Farmacovigilanza degli studi promossi dalla Fondazione (SAE, DSUR, etc); possibilità di estrarre informazioni e dati a scopo ricerca mediante dashboard
Data Manager/Study Coordinator:	inserimento della documentazione e la sua gestione trasversale tra le strutture coinvolte (interfaccia con TTO, Segreteria CE e CUP), aggiornamento continuo dei documenti che si modificano nel tempo, tracking dei vecchi documenti e archivio; interfaccia con i promotori/sponsor per il ricevimento proposte di studio e proposte di budget; registrazione e archivio pre-study visit ; monitoraggio andamento studio (pz arruolati, pre-screenati, screenati, in trattamento, in follow-up, etc) e stato di avanzamento presso INT (inizio, fine arruolamento, fine studio, chiusura centro) con dashboard per estrazione dati; necessaria una sezione specifica della piattaforma dedicata alle attività proprie dello start- up (documentazione per approvazione) degli studi “spontanei” promossi da INT, mono e multicentrici: preparazione documenti per approvazione e e-CRF, selezione e iter di fattibilità dei centri aderenti allo studio, formulazione budget (lo studio ha ricevuto un finanziamento parziale, non ha finanziamento, è parte di un progetto di ricerca finanziato, etc) e contratto con i finanziatori no-profit;; contratti con i centri partecipanti; monitoraggio dei centri; gestione emendamenti, sviluppo di e-CRF per studi promossi da INT monocentrici e multicentrici. gestione della fatturazione con possibilità di distinguere le prestazioni segnalate dal CUP rimborsate dal Sistema Sanitario Nazionale da quelle rimborsate dallo Sponsor e possibilità di raggrupparle per categoria erogante ai fini dell’emissione di fattura finale. Trasferimento dati archiviati nel gestionale in uso attualmente.

PI, Study Coordinator, infermiere di ricerca

Studi “spontanei” no-profit: interfaccia con le strutture amministrative (TTO, Segreteria CE, REFeLP) e i DM per disegno studio, stesura budget, preparazione documenti per l’approvazione, preparazione e-CRF. Interfaccia con Farmacia per gestione del farmaco in studio. Stretta interconnessione con CCE per reclutamento pazienti, somministrazione del consenso, gestione trattamenti, visite controllo, esami clinici; possibilità di monitoraggio andamento studio (pz arruolati,in pre-screening, selezionati dopo screening, in trattamento, in follow-up, etc) e stato di avanzamento (inizio, fine arruolamento, fine studio, chiusura centro); gestione della fatturazione sulla base delle informazioni disponibili (n° visite e tipologia, n° paz, prestazioni a rimborso SSN o Sponsor), attraverso ad un integrazione con il sistema di prenotazione degli esami del CUP . Possibilità di estrazione dati e informazioni di esito attraverso dashboard di facile gestione

S.c. ICT-SIA:

interconnessione con la CCE, e con gli applicativi ad oggi in uso per la gestione delle prenotazioni, dell’ambulatorio, dei ricoveri, delle prestazioni; livelli di integrazione tra i sistemi in step successivi per grado di complessità; linguaggio richiesto : HL7 e WEB Services; definizione dei livelli di accesso e profilazione delle utenze sia in piattaforma gestionale che in CCE; implementazione della piattaforma per fasi successive, inizialmente focalizzata sulla gestione documentale e successivamente potrà gestire gli aspetti legati al paziente (screening, arruolamento, trattamento, follow-up), grazie alla progressiva interconnessione con la CCE. L’anagrafica dello studio caricata sulla piattaforma manderà informazioni alla CCE e all’ICT; la CCE invierà alla piattaforma le informazioni su farmaci, prestazioni, dati clinici etc.; la piattaforma dovrebbe generare l’elenco delle prestazioni da effettuare per la visita successive.

REFeLP: Risorse Economiche e Finanziare e Libera Professione TTO: Trasferimento Tecnologico

CE: Comitato Etico

PI : Ricercatore Responsabile dello Studio DM: Data Manager/Study Coordinator

IMP: Investigational Medicinal Product: farmaco in studio SIV: visita inizio studio

CUP: centro unico di prenotazione CCE: cartella clinica elettronica

ICT-SIA: Information Communication Technology e Sistemi Informativi Aziendali

APPENDICE 2

Piattaforma per Studi Clinici

STRUTTURE COINVOLTE E ATTIVITA’ PROPRIE DEL PROCESSO DI GESTIONE E CONDUZIONE DEGLI STUDI CLINICI

STRUTTURA	Attività svolte nel processo
S.c. REFeLP:	formulazione del budget dello studio (tariffario prestazioni), tracciamento delle prestazioni attraverso il rico oscimento del paziente in studio,“correzioni” sull’attribuzione dei costi a sponsor o SSN, verifica delle scadenze per la fatturazione, e controllo degli incassi
S.s. TTO:	documentazione amministrativa (contratto, Material Transfer Agreement, lettere contratto, etc, fac-simili delle comunicazioni di fatturazione e chiusura dello studio) e suo archivio; interfaccia con i promotori/sponsor, con i PI, lo staff e i DM, e con la segreteria del CE per la condivisione della documentazione, della determina di approvazione; monitoraggio amministrativo dello studio (polizza assicurativa, fatturazione alla sottoscrizione del contratto)
Segreteria CE:	registrazione di tutta la documentazione inviata dal promotore/sponsor (anagrafica, tempistica, codice studio, consenso informato, etc), per approvazione studi farmacologici e non; gestione degli emendamenti, delle notifiche e tracciamento documenti; gestione sedute CE; monitoraggio amministrativo dello studio
S.c. Farmacia:	gestione del farmaco in studio (anagrafica dell’IMP; form identificativo dello studio, modulo richiesta farmaci sperimentali, modulo di contabilità e loro compilazione); gestione dei materiali forniti dallo sponsor (carico-scarico); Linee Guida per l’allestimento del farmaco sperimentale; interfaccia con lo sponsor per il monitoraggio delle attività della farmacia (data log temperatura, localizzazione farmaco); gestione Farmacovigilanza
Data Manager/Study Coordinator:	attività di start-up degli studi “spontanei” (documentazione per approvazione):, contatti con i centri partecipanti a studio multicentrico, monitoraggio dei centri, gestione emendamenti; e-CRF; ricevimento proposte di studio e di budget da promotori/sponsor esterni; gestione trasversale della documentazione tra le strutture coinvolte (REFeLP, TTO, Farmacia, Segreteria CE, PI, reparti degenza, laboratori diagnostica e analisi, etc); aggiornamento continuo documenti e archivio; monitoraggio andamento studio; gestione della fatturazione; registrazione e archiviazione della scheda di PRE-STUDY visit. .
PI, Study Coordinator, infermiere di ricerca	fattibilità dello studio e budget; reclutamento pazienti, somministrazione del consenso, gestione trattamenti, visite controllo, esami clinici; monitoraggio andamento studio (pz arruolati, pre-screenati, screenati, in trattamento, in follow-up, etc) e stato di avanzamento (inizio, fine arruolamento, fine studio, chiusura centro); gestione della fatturazione sulla base delle informazioni disponibili (n° visite e tipologia, n° paz, prestazioni a rimborso SSN o Sponsor).
S.c. ICT-SIA:	supervisione della CCE e degli applicativi per la gestione delle prenotazioni,dell’ambulatorio, dei ricoveri, delle prestazioni, etc.; definizione dei livelli di accesso e profilazione delle utenze; sicurezza dei sistemi

REFeLP: Risorse Economiche e Finanziare e Libera Professione TTO: Ufficio di Trasferimento Tecnologico

CE: Comitato Etico

PI : Ricercatore Responsabile dello Studio DM: Data Manager/Study Coordinator

IMP: Investigational Medicinal Product: farmaco in studio SIV: visita inizio studio

ICT-SIA: Information Communication Technology e Sistemi Informativi Aziendali CCE: cartella clinica elettronica

APPENDICE 3 - Architettura del Sistema Informativo Aziendale

La strategia di innovazione ICT punta a fornire un supporto integrato ai processi diagnostico-terapeutici e alle attività di ricerca clinico-scientifica oltre che ai processi di gestione amministrativa della Fondazione. Dal 2000 la Fondazione ha messo a punto una strategia di innovazione che ha, prima di tutto, analizzato approfonditamente il portafoglio ICT presente e successivamente focalizzato gli sforzi per la realizzazione di

un’infrastruttura comune che permettesse di sviluppare le applicazioni critiche per i processi clinici e

amministrativi. Il sistema è evoluto nel corso degli anni verso soluzioni di mercato specializzate ma in grado di garantire l’interoperabilità secondo meccanismi standard e basati su tecnologie consolidate, flessibili e scalabili. I principi chiave che guidano l’innovazione IT nella Fondazione possono essere così riassunti:

• Abilitare l’integrazione tra le applicazioni a supporto dei processi clinici;

• Acquisire conoscenza dei processi e migliorarne le capacità di controllo;

• Adottare un approccio coerente e integrato per affrontare l’innovazione tecnologica e organizzativa;

• Diffondere nei reparti l’utilizzo di strumenti ergonomici per supportare la mobilità.

Business Intelligence

Datawarehouse

Amministrativo

Datawarehouse

Clinico

Datawarehouse

Scientifico

Il Sistema Informativo Aziendale (di seguito SIA) della Fondazione è composto da diversi moduli applicativi integrati tra loro a vario livello finalizzati a permettere la corretta gestione dei processi clinici, scientifici e amministrativi. L’infrastruttura di rete aziendale copre tutti i presidi della Fondazione, permettendo l’accesso alla Intranet aziendale e ai diversi applicativi fruiti con architettura web-based o client-server.

Servizi amministrativo-contabili

ERP

Risorse Umane

Cartella

Clinica Elettronica

Cartella di

Farmacoterapia

Extranet

CRS-SISS

FSE

ROL-CCO REL-CCO..

Gestione Accessi

Front Office

ADT

Middleware di integrazione

Servizi Centrali

Adapter HL7

SISS-Way

RPY

CUP

Base Dati clinica (EPR)

PACS

Altro (Web Services, batch, dblink, … )

Anagrafe Prescrizioni

Pazienti (BAC) RUR

LIS

RIS Gestione Blocco Ambulatoriale Operatorio

Banca

Tessuti

Anatomia

Patologica

Radioterapia

. . .

Active Directory - LDAP

Sistemi Dipartimentali

Piattaforma RFId

Firma

digitale

Marcatura

temporale

Archiviazione

sostitutiva

Gestione Ordini

Servizi di firma ed archiviazione

Figura 1: Architettura di alto livello del Sistema Informativo Aziendale

Come raffigurato in Figura 1, l’architettura del SIA è caratterizzata dalla presenza di un middleware centrale che permette l’interoperabilità tra i diversi moduli applicativi presenti nella Fondazione: dal Front Office (ADT e CUP), ai dipartimentali, ai servizi aziendali centralizzati (es. Anagrafica Aziendale Pazienti - BAC, Base Dati Clinica - EPR), fino ai servizi di firma digitale e di integrazione con la extranet regionale del progetto CRS-SISS (Carta Regionale dei Servizi - Sistema Informativo Socio Sanitario).

Data Center della Fondazione

La Fondazione è dotata di due Data Center nell’area di Milano distanti circa un kilometro in linea d’aria:

• Data Center Primario (Produzione): xxx Xxxxxxxx, 0;

• Data Center Secondario (Disaster Recovery): xxx Xxxxxx, 00.

Il collegamento ridondato tra i due siti è di tipo punto-punto e ha banda disponibile di 100 Mb; questo collegamento è utilizzato per la connessione di dati e fonia tra la sede di via Xxxxxx e la sede di via Venezian.

I Data Center sono dotati di sistema UPS.

Nei Data Center sono già disponibili armadi rack; sono armadi da 19”, 60 cm (larghezza) x 200 cm (altezza) x 90 cm (profondità).

È in corso l’adesione al progetto regionale di back-up/disaster recovery con ARIA SpA (ex Lombardia Informatica S.p.A.).

Middleware di integrazione (JCAPS - Santer)

Il middleware di interoperabilità è lo strato software che permette la comunicazione fra tutti i sottosistemi presenti all’interno del SIA, e in particolare abilita le integrazioni interne tra sistemi dipartimentali della Fondazione tramite protocollo HL7, coerentemente con quanto riportato nella documentazione regionale AS- PS_R-SEHL7#01, che descrive i profili adottati, nell’ambito del progetto CRS-SISS, per la cooperazione

applicativa tra i sistemi informatici presenti nelle Aziende Sanitarie secondo organizzativi previsti dal progetto di integrazione regionale.

i modelli e i processi

Tale soluzione si appoggia sulla integrazione JCAPS (Santer), il

Piattaforma Regionale che mette a disposizione il Middleware di quale si occupa fondamentalmente di ascoltare i messaggi HL7

dell’applicativo inviante e di instradarli verso l’applicativo ricevente. Ogni applicativo si connette al middleware tramite un’interfaccia definita “adapter”, la quale fornisce a un generico applicativo i servizi per l’integrazione, sia verso i sistemi sovra-aziendali sia verso l’interno della Fondazione. L’adapter per HL7

mette a disposizione il “connettore” per gli applicativi che adottano questo protocollo standard. Se

l’applicativo dipartimentale da integrare non è predisposto a una integrazione nativa HL7, l’integrazione richiede la realizzazione di un “adapter proprietario” che abiliti un dialogo HL7.

Il middleware consente la condivisione dei servizi centrali tra le varie applicazioni, in particolare la sincronizzazione delle diverse Anagrafiche Locali con l’Anagrafe Pazienti Centralizzata, l’archiviazione dei referti sul repository aziendale. Tra queste vi è modulo SISS-Way, composto da una serie di componenti

della Piattaforma Regionale che forniscono servizi applicativi sincroni per l'integrazione con il SISS

integrando le funzionalità dell'Anagrafe Aziendale e del Repository Referti. I servizi SISS-Way gestiti sono quelli di gestione della firma, archiviazione su Repository, notifica verso il SISS e consultazione dei referti digitali archiviati.

Attraverso un particolare tipo di adapter, il middleware mette in comunicazione Aziendale con l’extranet SISS. In particolare fornisce i servizi per:

il Sistema Informativo

• Identificare l’assistito rispetto all’anagrafica depositata a livello regionale;

• Identificare e acquisire le prescrizioni registrate sul dominio centrale del sistema informativo regionale;

• Notificare al sistema informativo regionale gli eventi sanitari (prenotazione e accettazione di un appuntamento, accettazioni e dimissioni di ricovero, ecc.);

• Gestire la trasmissione dei referti in forma strutturata e/o di referto formato digitalmente dagli applicativi di origine al repository;

• Consultare lo storico del paziente registrato sul dominio regionale e sul repository referti.

Front Office (ADT – Santer; CUP - Santer)

Questo modulo costituisce il sistema amministrativo destinato all’accettazione del paziente, che racchiude le

funzioni per la gestione amministrativa e organizzativa dei flussi di pazienti in Fondazione. Esso si compone dei seguenti applicativi:

ingresso e uscita dalla

• ADT. Esso supporta la gestione amministrativa degli eventi di accettazione, dimissione e

trasferimento, relativi ai ricoveri ordinari e alle prestazioni erogate in regime di DH. Espone la lista dei pazienti accettati a tutti i reparti afferenti alla struttura ospedaliera. L’applicativo produce le SDO e le lettere di dimissione firmate digitalmente e archiviate via SISS-Way sul Repository aziendale e notificate al Fascicolo Sanitario Elettronico nella rete regionale SISS. Per alcune specialità, inoltre, viene prodotto direttamente il documento ROL-CCO.

• CUP. Esso supporta tutta la gestione amministrativa relativa all’erogazione delle prestazioni

ambulatoriali. L’applicativo accetta il paziente esterno e comunica con i dipartimentali per la

prenotazione e tracciamento delle prestazioni erogate. L’applicativo si integra attraverso il

middleware di integrazione via messaggistica HL7 con i servizi dipartimentali e nativamente con la Gestione Ambulatoriale.

Entrambi gli applicativi gestiscono flussi di rendicontazione verso la Regione, rispettivamente SDO e la 28 SAN.

Servizi centrali

Questo modulo contiene tutti i servizi condivisi dai diversi moduli applicativi del SIA attraverso il middleware di integrazione.

• Base Dati Clinici ed EPR (Repository - Santer). Nella Fondazione tutta la documentazione firmata elettronicamente è stata concentrata, in un unico contenitore che rispetta le caratteristiche suggerite dal progetto regionale CRS-SISS e la normativa vigente in materia. In particolare è stato adottato il Repository Referti, componente della Piattaforma Regionale che permette di archiviare e condividere i referti prodotti secondo quanto definito dal SISS. A esso è affiancato un Repository PACS (Picture Archiving and Communication System) per la gestione delle immagini radiologiche.

La memorizzazione del referto avviene attraverso l’interfaccia IHE in documento tramite messaggistica HL7.

grado di accettare il

In particolare, il Repository Referti gestisce sia la messaggistica HL7 che i servizi SISS-Way per l’archiviazione, la consultazione e l’oscuramento dei referti, e oltre ai referti in pdf supporta anche i

dati clinici strutturati, per il momento solo per dati di laboratorio (questi inviati via HL7). E’

possibile inoltre accedere all’interfaccia EPR per la consultazione avanzata dei referti, organizzati per episodio clinico per ciascun paziente. Tutti i referti sono firmati in firma digitale SISS e marcati temporalmente. I Repository (Referti e PACS) alimentano il sistema aziendale di conservazione sostitutiva per il mantenimento nel tempo dei documenti digitali.

Un’ulteriore modalità di accesso ai referti consiste nel passaggio di contesto da un applicativo verso il modulo EPR (l’interfaccia web al Repository Referti aziendale). Tale integrazione è implementata tra sistema Order Entry e l’EPR attraverso modalità standard HL7-CCOW.

• Sistema di Conservazione Sostitutiva (Scriba - Medas). Il sistema supporta la conservazione a norma di legge di tutti i referti archiviati su Repository-EPR e delle immagini DICOM provenienti dal PACS.

• Cartella Clinica Elettronica (wHospital – Lutech). Il sistema di Cartella Clinica Elettronica è una piattaforma web-based, unica per tutta la Fondazione, caratterizzata da componenti trasversali e componenti verticali personalizzate per gestire le peculiarità delle diverse realtà cliniche supportate (es. schede specialistiche per patologia). La sua trasversalità consente di implementare soluzioni per il supporto del workflow clinico-sanitario. Si integra con i restanti applicativi dipartimentali tramite integrazioni HL7, DICOM, e/o passaggio di contesto.

• Order management (Order Entry - Santer). Rappresenta il sistema per la gestione delle richieste

informatizzate verso i dipartimentali per i pazienti ricoverati. Al momento la richiesta informatizzata è gestita soltanto per il RIS, ma a tendere saranno informatizzate tutte le richieste, con tanto di associazione al relativo referto (erogato), come LIS, Anatomia Patologica, Visite Parere.

• Anagrafe Aziendale Pazienti (BAC - Santer). Nella Fondazione la gestione centralizzata dei dati anagrafici è abilitata dalla BAC (Banca Anagrafica Centralizzata), componente della Piattaforma Regionale. La soluzione in attuazione prevede un’interfaccia IHE, basata su messaggistica XX0, xx grado di disaccoppiare completamente i sottosistemi. La BAC è alimentata solo dai sistemi di front office attraverso il middleware HL7 e comunica ogni variazione anagrafica attraverso broadcast HL7 verso dipartimentali e gli stessi ADT e CUP, allo scopo di garantire il costante allineamento dei dati

anagrafici. Lo scenario è quello per cui ciascun sottosistema sia dotato locale, che deve essere allineata alla BAC con messaggistica HL7.

di una propria anagrafe

• Active Directory (LDAP-Active Directory 2003 - Microsoft). È il sistema di directory aziendale utilizzato per la gestione centralizzata dei dati relativi all’identità degli utenti e dei rispettivi account per l’autenticazione ai diversi applicativi aziendali.

• Generazione prescrizione (GestAmb - Santer). Sono disponibili funzionalità di ricettario a

supporto al medico che intende prescrivere richieste di tipo specialistico o farmaceutico tramite il Ricettario Unico Regionale (RUR). Le integrazioni con i servizi di gestione prescrizione sono implementati tramite i servizi messi a disposizione dalla Piattaforma Regionale, in particolare i metodi lato client del modulo PRSC di SissWay. A ogni impegnativa prescritta che il SISS convalida è associato un codice univoco, o Identificativo Univoco Centrale (IUP), generato e restituito dal SISS. Tutti i moduli del SIA possono integrarsi attraverso passaggio di contesto, come previsto dagli scenari SISS.

Sistemi amministrativi e contabili

In questo modulo ricadono tutte le applicazioni per la gestione dei flussi amministrativi e contabili, dalla gestione dei magazzini, al calcolo delle buste paga, alle funzionalità di business intelligence per il monitoraggio delle prestazioni aziendali.

• Oracle Applications. Tutta la parte amministrativo-contabile della Fondazione viene gestita, con scarse integrazioni con il resto del SIA e in modo pressoché autonomo, dalle Oracle Applications,

che attualmente sono in xxxxx xx xxxxxxxxxxxxx xxxx xxxxxxxx 00x. In particolare le Oracle

Applications presidiano il

ciclo attivo, ovvero tutta la parte contabile

e di fatturazione legata

all’erogazione del servizio, e il ciclo passivo, ovvero tutti gli ordini e i rapporti con i fornitori, mettendo a disposizione funzionalità per la gestione del workflow di gestione degli ordini dalla richiesta di magazzino, alla generazione dell’ordine, alla gestione della tesoreria per il pagamento.

Dal punto di vista delle scorte di farmaci, le Oracle Applications presidiano la gestione del

magazzino centrale e del magazzino Laboratorio di Galenica Clinica; sono in corso di avvio le funzionalità a supporto della gestione delle scorte locali dei diversi reparti. La gestione dei dispositivi medici è difficoltosa, anche per le diverse modalità di acquisizione, soprattutto nell’area del Blocco Operatorio, dove al momento non è ancora attiva la gestitone con le Oracle Applications.

• BOARD. Sistema di business intelligence utilizzato per reporting e statistiche sull’attività clinico- sanitaria e per la rendicontazione dei costi e la costruzione del bilancio aziendale.

Integrazione con il servizio ICT (Information Communication Technology) e SIA

Il Fornitore affidatario deve effettuare la perfetta integrazione di quanto fornito con i servizi ICT e SIA in essere presso la Fondazione.

La connessione alla rete aziendale di qualsiasi apparecchiatura deve essere preventivamente autorizzata da ICT e deve uniformarsi alle policy adottate dalla Fondazione (indirizzi IP, naming convention, antivirus, ecc.). In particolare non devono assolutamente essere installati e collegati all’infrastruttura aziendale modem, hub, Access Point o qualsiasi altra apparecchiatura non preventivamente autorizzata dalla s.c. ICT e SIA.

Sarà possibile accedere da remoto alla rete aziendale per attività di manutenzione e/o tele assistenza sulle apparecchiature installate, tale connessione deve rispettare le policy aziendali ICT.

La connessione remota prevederà l’utilizzo di un client Cisco (fornito dalla Fondazione) che sfruttando lo standard IPsec (Ip security) permetterà al Fornitore il collegamento alle apparecchiature di propria competenza presenti sulla Intranet aziendale.

Presso i locali destinati a ospitare l’apparecchiatura in oggetto è presente un sistema di cablaggio rispondente agli standard nazionali e internazionali in merito alle caratteristiche elettriche, fisiche, trasmissive, meccaniche e di installazione.

Antivirus

Deve essere installata la versione 11 o superiore di Office Scan (Trend Micro), configurata per effettuare gli aggiornamenti in modo tale da utilizzare il server dedicato residente sulla Intranet aziendale.

Join al dominio

Allo scopo di facilitare la condivisione delle informazioni tra le macchine ICT e le apparecchiature può essere opportuno in alcuni casi effettuare la join al dominio INT. Qualora fossero necessarie indicazioni, queste verranno illustrate da personale ICT.

Condivisione ed elaborazione dati

Qualora fosse necessario condividere o trasmettere dati con/alle postazioni di lavoro gestite dalla S.C. ICT e SIA si devono definire le modalità con le quali è possibile farlo considerando che:

• Il parco macchine ICT è prevalentemente costituito da PC con S.O. Windows 7 Professional;

• Gli utenti accedono al PC autenticandosi a un Dominio Windows 2003, utilizzando proprie credenziali;

• L’installazione di nuovo software su macchine ICT può essere effettuato solo da personale ICT;

• La configurazione delle postazioni di lavoro ICT può essere effettuato solo da personale ICT.

Si ribadisce che anche l’installazione di eventuali software su postazioni di lavoro ICT della Fondazione deve avvenire previa verifica di compatibilità da parte della s.c. ICT e SIA.

Acronimi

ADT	Accettazione Dimissione Trasferimento
BDA	Banca Dati Aziendale
CCE	Cartella Clinica Elettronica
CRS SISS	Carta Regionale dei Servizi-Sistema Informativo Socio Sanitario
CUP	Centro Unico Prenotazione
EPR	Electronic Patient Record
ERP	Enterprise Resource Planning
HL7	Health Level 7
ICD	International Classification of Diseases
ICT	Information Communication Technology
LIS	Laboratory Information System
RFId	Radio Frequency Identification
SDO	Scheda Dimissione Ospedaliera
SIA	Sistema Informativo Aziendale
SNOMED-CT	SNOMED Clinical Terms

a

e

Repository documentale accessibile anche dall’esterno

APPENDICE 4

Interfaccia piattaforma e Cartella Clinica Elettronica

Piattaform

CCE

Comunicazione di attivazione studio

Service Desk ICT (mail)

Creazione

dell’Anagrafica dello studio

HL7

CCE recepisce

l’anagrafica dello studio

• Codifiche

• associazione tra studio e prestazioni

• ?

Web

Services

• Gestione documentale dello studio

• Flusso autorizzativo

Associazione Pz.

Studio

Possibilità di effettuare

blocchi sugli applicativi che richi dono le prestazioni (Modulo Prescrittivo ,CUP, OM) con eventuale gestione delle eccezioni

• Inizio e fine arruolamento Pz. App. verticale CCE

• Prestazioni erogate di gestione dello

• Consumo farmaci

• Dati macro aggregati (Report) studio

HL7

Web

Elaborazione- Services

Fatturazione?

Profilazione utenze

sulla Piattaforma. interne/ esterne

Profilazione utenze

sulla CCE