Allegato A - TECNICO
[Digitare il testo]
Allegato A - TECNICO
Full service avviamento e gestione riuso CCE Capitolato tecnico per Servizi di
CCE Aziendale
Sezione 0 : Introduzione e principi generali Sezione 1 : Servizi Avviamento & Estensione Sezione 2 : Servizi Gestione
Sezione 3 : Servizi Evoluzione
Sezione 4 : Soluzione applicativa tecnologica
[Digitare il testo]
Sommario 0 SEZIONE INTRODUZIONE E PRINCIPI GENERALI 4
0.1 Glossario 4
0.2 DEFINIZIONE DI CCE 5
0.3 Abstract 5
0.4 Oggetto dell appalto 6
0.5 Requisiti di erogazione dei servizi 8
0.5.1 Brevetti industriali e diritti di autore 8
0.5.2 Riservatezza 8
0.5.3 Referente Unico di progetto 8
0.5.4 Livelli di servizio SLA 8
0.5.5 Fatturazione 10
0.5.6 Monitoraggio continuo e decurtazione del canone 10
0.5.7 Risoluzione contrattuale 10
0.6 Piano di comunicazione 11
0.6.1 Riferimenti gruppo di lavoro Ente 11
0.6.2 Riferimenti del gruppo di Lavoro del fornitore 11
0.6.3 Le riunioni: modalità 11
0.6.4 Riunioni di Avanzamento Lavori 11
0.6.4.1 Scopo 11
0.6.4.2 Report di avanzamento (Project Progress Report) 12
0.6.4.3 Diagrammi di GANTT e pianificazione risorse 12
0.6.4.4 Report di Eccezione 12
0.6.4.5 Riunioni di avanzamento con l’Ente 12
0.6.4.6 Riunioni di coordinamento 13
0.6.4.7 Interfaccia con il l’Ente ed “Escalation Path” 13
0.7 Procedure e standard di qualità 13
0.7.1 Procedure generali tra il Fornitore e l‟Ente 13
0.7.1.1 Tipologia delle segnalazioni 13
0.7.1.2 “Follow up” delle azioni 13
0.7.2 Standard per la produzione di documentazione 14
0.7.2.1 Formato di un documento 14
0.7.2.2 Linguaggio dei Documenti 14
0.8 Piano di implementazione 14
0.9 exit management 16
0.10 Gestione del rischio 17
0.10.1 Definizione di rischio 17
0.10.2 Controllo dei rischi del progetto 18
0.11 Ruoli e competenze delle risorse professionali richieste 18
0.11.1 Responsabile del Contratto (Client Manager) 18
0.11.2 Responsabile di Programma (Program Manager) 18
0.11.3 Responsabile di Progetto (Project Manager) 19
0.11.4 Progettazione, Analisi e Sviluppo 19
0.11.5 Analisi e Sviluppo 19
0.11.6 Supporto e tutor 19
0.11.7 dimensionamento del team 20
0.11.8 Aggiornamento Professionale e Corsi di Formazione 21
0.11.9 Comitato di Controllo (CC) 21
1 SERVIZI AVVIAMENTO ED ESTENSIONE 23
1.1 Ruolo e responsabilità del servizio di avviamento ed estensione 23
1.2 Competenze richieste 23
1.3 Descrizione delle attività richieste 24
1.3.1 Contesto aziendale 24
1.3.2 Servizio di formazione preventiva agli utilizzatori del sistema 31
1.3.3 Servizio di affiancamento agli operatori in fase di avviamento delle Unità Operative 31
1.3.4 Servizio di profilazione progressiva degli operatori 31
2 SEZIONE GESTIONE 32
2.1 Ruolo e responsabilità 32
2.2 Competenze richieste 32
2.3 Descrizione delle attività richieste 33
2.3.1 Sviluppo applicativo manutentivo e correttivo 33
2.3.2 Help Desk e Gestione Utenti 33
2.3.3 assistenza 7 X 24 33
2.3.4 Responsabilità e Supervisione degli standard di configurazione apparati 33
2.3.5 Coordinamento organizzativo e tecnico 33
3 SERVIZI EVOLUTIVI 35
[Digitare il testo]
3.1 Competenze richieste 35
3.2 Descrizione delle attività richieste 35
3.2.1 Servizio di analisi,progettazione e protipazione evolutive 35
3.2.2 Interiazioni con il BOARD della Community di riuso CCE 35
4 SOLUZIONE APPLICATIVA TECNOLOGICA AS-IS 37
4.1 Caratteristiche funzionali del sistema 37
4.2 Infrastruttura tecnologica 38
4.3 Componenti del sistema disponibili per la ditta aggiudicataria 39
4.4 Prescrizioni e vincoli per lo sviluppo e intervento sul sw CCE 40
4.4.1 MODELLO E ARCHITETTURA DI SVILUPPO DEL SOFTWARE 42
4.4.2 SVILUPPO - Postazioni di lavoro e ambiente per lo sviluppo del software 44
4.4.3 METODOLOGIA 45
[Digitare il testo]
0 SEZIONE INTRODUZIONE E PRINCIPI GENERALI
Il presente documento illustra i contenuti tecnico/organizzativi e i requisiti per l‟attuazione delle attività relative alla procedura di gara per l'affidamento del contratto di appalto per i servizi di supporto all‟avviamento in produzione del sistema informatico Cartella Clinica CCE, sviluppato dall‟ASST Niguarda di Milano ed acquisito in riuso dall‟Ente appaltante, nonché dei servizi continuativi finalizzati alla continuità di funzionamento, al supporto utenti ed alla manutenzione/evoluzione dell‟intero impianto software.
Il presente documento tecnico di appalto è strutturato nelle seguenti sezioni: Sezione 0 : introduzione e principi generali
Sezione 1 : Servizio di avviamento ed estensione Sezione 2 : Servizio di gestione
Sezione 3 : Servizio di evoluzione
Sezione 4 : Soluzione applicativa/tecnologica AS-IS
0.1 Glossario
Definizione | Significato | Descrizione |
BMM | Grande Ospedale Metropolitano “Bianchi Melacrino Xxxxxxx” – Reggio Calabria | Ente appaltatore |
NIG | ASST Grande Ospedale Metropolitano Niguarda - Milano | ente promotore della soluzione in riuso AGID CCE rif 824, e in cui è istallata la soluzione CCE |
BESTA | FONDAZIONE I.R.C.C.S. ISTITUTO NEUROLOGICO XXXXX XXXXX - Milano | Altro ente sanitario in cui è installata la soluzione CCE |
FOM | FONDAZIONE IRCCS Ospedale Maggiore Niguarda Ca Granda - Milano | Altro ente sanitarioin cui è installata la soluzione CCE |
CCE ovvero: POR, MT | Cartella Clinica Elettronica, anche con denominazione Portale Clinico o Medical Tutorial | Soluzione di Cartella Clinica Elettronica sviluppata da NIG |
Dossier Clinico | Componente della cartella clinica elettronica (CCE) | È una componente della CCE che consente una gestione dedicata della documentazione clinica riferita a uno specifico paziente. In linea generale è lo strumento di piu‟ largo utilizzo al personale medico |
EPR | Electronic Patient Record | Clinical data repository aziendale (in letteratura internazionale anche indicato con il termine Electronic Medical Record, EMR) di tutti gli eventi del paziente (referti, esami, ecc.) in formato documentale e strutturato |
OM | Order Management | Funzionalità per permettere la registrazione delle richieste cliniche e assistenziali durante il percorso di cura e instradarli ai sistemi dipartimentali o funzionalità specifica di refertazione per i servizi. |
SIO | Sistema InformativoOspedaliero | Il complesso dell‟architettura hardware e software di supporto ai processi clinico-scientifici ed amministrativi all‟interno dell‟azienda sanitaria |
SISS | Sistema Informativo Socio-Sanitario della Regione Lombardia | Network regionale per l‟integrazione dei flussi informativi per i servizi socio-sanitari al cittadino/paziente |
FSE | Fascicolo Sanitario Elettronico | Archivio degli episodi e relativa documentazione clinica a livello regionale o nazionale |
EPR | Electronic Patient Record | Archivio degli episodi e relativa documentazione clinica a livello aziendale |
AA- BAC | Banca AnagraficaCentralizzata | AnagrafeAziendaledegliassistiti |
ADT | Admission, Discharge, Transfer | Admission/Discharge/Transfer |
CDA2 | Clinical DocumentArchitecture | Clinical DocumentArchitecture |
CUP | CentroUnicodiPrenotazione | CentroUnicodiPrenotazione |
DCE | DocumentoClinicoElettronico | DocumentoClinicoElettronico |
HL7 | HealthLevel7 | HealthLevel7 |
IHE | Integratingthe HealthcareEnterprise | Integratingthe HealthcareEnterprise |
LIS | Laboratory InformationSystem | Laboratory InformationSystem |
XXX | XxxxxxxXXX„PatientAdministrationManagement | ProfiloIHE„PatientAdministrationManagement‟ |
PIR | ProfiloIHE„PatientInformationReconciliation‟ | ProfiloIHE„PatientInformationReconciliation‟ |
Definizione | Significato | Descrizione |
FRO | Frontoffice | Frontoffice:SoluzionidiaccoglienzadiCUPADTeTriage |
PS | Pronto Soccorso | Pronto Soccorso :cartella clinicadigestionedelpaziente inemergenza |
RIS | RadiologyInformationSystem | RadiologyInformationSystem |
SWF | ScheduledWorkflow‟ | ProfiloIHE„ScheduledWorkflow‟ |
CCE | CartellaClinicaElettronica | CartellaClinicaElettronicadelpazientenelpercorsoclinico |
DCA | DiarioClinicoAssistenziale | DiarioClinicoAssistenziale |
TRIAGE | accoglienzadelpazienteinpronto soccorso | Modulo funzionalediaccoglienzadelpazienteinpronto soccorso |
RENE | Sistema nefrologia | Sistema informativoperlagestionedellesedutedialitiche |
SIMT | Sistemainformativotrafusionale | Sistemainformativotrafusionale |
[Digitare il testo]
0.2 DEFINIZIONE DI CCE
La CCE - Cartella Clinica Elettronica - altresì denominata Portale Clinico CCE o Dossier Clinico, è “l‟interfaccia” per la gestione unificata della storia clinica del paziente dell‟ospedale (per la totalità dei percorsi di cura, come ad esempio quello ambulatoriale e di reparto, comprendente “Gestione clinica del paziente” e “Trasferimenti e dimissioni” delle Linee Guida nazionali per la Cartella Clinica Elettronica Aziendale di Ricovero) e per tutta l‟attività del processo clinico di diagnosi e cura.
0.3 Abstract
L‟Ospedale Niguarda, a partire dal 2002, ha avviato le realizzazione di una propria soluzione denominata “Portale Clinico” (in breve “POR”, o “Dossier Clinico” o “Medical Tutorial” in breve “MT”), per la gestione unificata della storia clinica del paziente. È una soluzione per il supporto delle attività sanitarie e cliniche di reparto e di ambulatorio, nato per rispondere a due esigenze fondamentali: uniformare ed integrare le informazioni cliniche dei pazienti trattate nei diversi ambiti sanitari e, contestualmente, perseguire un progetto di dematerializzazione della documentazione cartacea (Fascicolo Sanitario Elettronico - FSE).
Il modello proposto è compatibile e puo‟ utilizzare la piattaforma regionale Lombarda di ultima generazione (EPR - Electronic Patient Record), interagisce con il Fascicolo Sanitario Elettronico regionale (FSE) regionale e utilizza l‟integrazione con apparecchiature medicali (di monitoraggio) e con i laboratori di analisi per il recupero in automatico degli esiti (dati strutturati numerici) all‟interno del dossier sanitario. La digitalizzazione del processo è resa possibile grazie ad alcune caratteristiche del modello:
- mobilità ed ergonomia degli strumenti che permettono di svolgere funzioni presso il letto del paziente;
- identificazione sicura del processo tramite RFID operatore-operazione-paziente;
- disasterrecovery& business continuity 100% per ottenere SEMPRE la disponibilità del dato anche in caso di failure dei sistemi e delle infrastrutture centrali e locali;
- valenza medico legale del dato (con integrazione della conservazione sostitutiva).
Si tratta di una soluzione potenzialmente replicabile nelle altre realtà lombarde in quanto si basa su un innovativo modello totalmente Open Source orientato al riuso, in ottemperanza alle indicazioni ministeriali in materia (Gazzetta Ufficiale n. 31 del 7 febbraio 2004).
Il settore Sanitario si sta muovendo sempre più verso un‟idea di Sistema Informativo paziente-centrico, in grado di fornire al personale sanitario un adeguato supporto nel corso dell‟intero processo di cura del paziente.
Il progetto Portale Clinico si caratterizza per un‟elevata componente di innovazione, essendo il veicolo attraverso il quale si vuole puntare alla realizzazione del Dossier Sanitario Elettronico (DSE) per il paziente.
Il Portale s‟inserisce in un‟architettura olistica dei Sistemi Informativi organizzati per processo, e rappresenta il cuore dell‟automazione del workflow del percorso di cura del paziente.
Inoltre, rappresenta un fattore strategico abilitante la promozione di progetti innovativi e sperimentali, sia di carattere regionale che ministeriale.
Questo sistema può essere paragonato a un raccoglitore virtuale, che tiene traccia di tutti i contatti che il paziente ha con la struttura sanitaria. Si tratta quindi di uno strumento che consente la raccolta strutturata dei dati riguardanti la salute del paziente e il suo percorso diagnostico-terapeutico, nonché le attività amministrative connesse ai ricoveri o alle prestazioni ambulatoriali.
Il Portale ha l‟obiettivo di fornire un supporto alla gestione informatizzata, uniforme, aggiornata e integrata dei dati anagrafici, clinici e sanitari del paziente lungo tutto il ciclo di assistenza sanitaria all‟interno di una determinata struttura sanitaria, Azienda Ospedaliera o IRCCS. Proprio per queste caratteristiche, può essere visto come uno degli ambiti applicativi chiave per l‟innovazione ICT in sanità.
[Digitare il testo]
Oltre a queste grandi aree di attività esistono una serie di altre iniziative che mirano all‟informatizzazione di specifiche aree operative dell‟ospedale. Nell‟insieme tutti questi progetti perseguono l‟obiettivo altamente strategico di dematerializzazione della documentazione sanitaria.
A livello organizzativo esistono due gruppi di lavoro fortemente interdipendenti: il team del gestore e il team dell‟ICT degli ospedali aderenti al riuso. Il team dell‟ICT è il punto di raccordo tra la soluzione informatica e le esigenze dell‟ospedale, detiene la conoscenza storica del sistema e dell‟azienda, si occupa di attività di pianificazione e controllo. Il team del gestore definisce possibili soluzioni sulla base di requisiti- utente formalizzati e risponde alle richieste di cambiamento e miglioramento dei sistemi.
I due gruppi lavorano fianco a fianco a partire dalla pianificazione delle attività fino alla verifica e al controllo dei risultati.
Alla fase di raccolta dei requisiti dell‟utente segue la formalizzazione di questi che costituiscono la base per lo sviluppo della soluzione che verrà poi testata e validata con gli utenti stessi.
Nel funzionamento a regime del sistema si mantiene uno stretto rapporto con gli attori del processo per raccogliere feedback e possibili migliorie. Gli utenti stessi svolgono quindi un ruolo proattivo nel processo di innovazione.
Nell‟illustrazione a lato viene presentato lo stato delle funzionalità della CCE, ideate seguendo la logica del percorso di cura del paziente e pertanto soggette a continue interazioni con i servizi diagnostici strumentali a supporto dell‟attività clinica/assistenziale.
0.4 Oggetto dell appalto
Il presente contratto ha per oggetto il Servizio di Avviamento e gestione della soluzione applicativa CCE - Cartella Clinica Elettronica del catalogo AGID N 284.
In particolare il servizio richiesto, si compone di:
1. Servizi iniziali di avviamento
• Servizi iniziali di Formazione in loco (in aula comprensivi di documentazione ed in affiancamento nei reparti/ambulatori) agli operatori clinici, sanitari ed amministrativi a supporto dell‟utilizzo della piattaforma CCE (comprensiva dei sottosistemi di Farmaco terapia e Nuovo Ricettario Elettronico NRE), organizzati presso la sede dell‟Ente appaltante e finalizzati alla completa diffusione e operatività del sistema nell‟ambito dei processi clinici, assistenziali e ambulatoriali;
• Servizi iniziali di consulenza specialistica finalizzati all‟armonizzazione dei processi operativi ospedalieri per conseguire l‟obiettivo di dematerializzazione della documentazione clinica dei pazienti (ambulatoriali ed in regime di ricovero) che rappresenta il target dell‟iniziativa;
• Servizi iniziali di classificazione e definizione delle codifiche farmaci interne (principio attivo/farmaco commerciale), predisposizione del prontuario farmaci di reparto e configurazione delle relative entità informatiche, supporto alla Farmacia aziendale e alla Direzione Sanitaria per la definizione dei modelli di acquisto e rendicontazione
• Servizi iniziali di integrazione funzionale del Portale Clinico CCE con i sistemi “verticali” in uso presso l‟Ente appaltante da realizzarsi, sulla base degli standard già implementati nel Portale stesso (Web Services, messaggistica HL7, integrazioni di contesto, ecc.), mediante interventi sul codice sorgente già nelle disponibilità dell‟Ente;
• Servizi iniziali di configurazione e personalizzazione delle componenti software specifiche, presenti nel Portale Clinico CCE Niguarda, a supporto delle specialità di reparto e ambulatoriali (inquadramenti, referti strutturati, fogli di trasferimento, lettere di dimissione, ecc.) ai fini del corretto popolamento del repository dei Dossier clinico/ambulatoriali e dei percorsi di cura;
• Servizi di configurazione e classificazione utenti ai fini del processo di autenticazione e autorizzazione all‟uso del Portale CCE Niguarda nonché dei diversi sistemi clinici integrati dallo stesso;
• Servizi di configurazione e classificazione delle workstation finalizzate all‟uso del Portale Clinico CCE;
• Servizi di popolamento iniziale delle tabelle “base” indispensabili al funzionamento del sistema
• Servizi di coordinamento della predisposizione e installazione degli apparati e periferiche di uso esclusivo della CCE (badge e lettori RfId, lettori bar code, postazioni mobili e di backup)
2. Servizi gestione
• Servizi continuativi di monitoraggio dell‟intero impianto del Portale Clinico CCE (software di base, middleware e software applicativo degli ambienti PROD e PRE-PROD) comprensivi di garanzia sul pronto intervento specialistico ai fini della continuità d‟uso del sistema (controllo 24H/365 per tutta la durata del contratto con risoluzione malfunzionamenti);
[Digitare il testo]
• Servizi continuativi di manutenzione ordinaria del codice sorgente ai fini della correzione errori e degli adeguamenti normativi eventualmente emergenti successivamente all‟avviamento del sistema;
• Servizi di Help Desk applicativo (HD2 24H/365) attivabili da SPOC (HD1) o mediante ticket a supporto delle problematiche di sistema evidenziate dagli utenti
3. Servizi evolutivi
• Servizi continuativi di evoluzione funzionale e tecnologica sul CCE ai fini dell‟adeguamento del codice sorgente ai regolamenti regionali ed alle progressive esigenze dell‟Ente Appaltante (basket di prestazioni/anno)
• Servizi di presidio tecnico/applicativo a supporto dei progressivi mutamenti organizzativi dell‟Ente attesi per i prossimi esercizi (basket di prestazioni/anno)
• Servizi specialistici di supporto alla messa in funzione delle future “Major Releases” del Portale Clinico CCE: Update di sistema e di impianto, Aggiornamenti della Base Dati e delle utilities di gestione, Configuration Management e complementi formativi (e- learning)
La fornitura dovrà prevedere tutti i servizi e gli strumenti necessari per la perfetta realizzazione di quanto richiesto, secondo quanto descritto nelle sezioni che seguono.
Dal punto di vista organizzativo, per quanto indicato al fornitore viene richiesto l‟erogazione ed il presidio di tre processi principali: Avviamento ed Estensione (fino alla completa estensione nell‟impiego del nuovo strumento informatico), Evoluzione (per l‟attuazione di adeguamenti o introduzione di elementi funzionali nuovi) e Gestione. Ciascuno di essi ha una propria anima, che rispettivamente richiama le funzioni di Ricerca e Sviluppo e di Produzione.
Pertanto al fornitore viene richiesto di espletare queste due funzioni avendo cura di soddisfare i requisiti base:
- Avviamento ed Estensione (o struttura di avviamento): con competenze relative all‟introduzione del cambiamento, in termini di coordinamento delle attività, modalità di coinvolgimento ed interazione con gli utenti, configurazione e adeguamenti applicativi. Caratteristiche distintive:
- Attenzione ai requisiti utente e forte conoscenza dei processi ospedalieri;
- Flessibilità e velocità nella configurazione delle funzionalità da valutare e validare con i referenti clinici;
- Conoscenza del contesto normativo, organizzativo e relazionale in cui il sistema si va ad inserire.
- Integrazione con i sistemi informativi esistenti e capacità di soluzioni all‟emergenza o contingenza
- Gestione (o struttura di produzione): con competenze relative all‟ingegnerizzazione e diffusione della soluzione, per l‟utilizzo in produzione all‟interno delle strutture cliniche con caratteristiche di performance ed affidabilità adeguate. Caratteristiche distintive:
- Conoscenza delle architetture e delle modalità di esercizio di applicazioni business critical;
- Software factory allo stato dell‟arte in termini di processo di sviluppo software, comprensivo di testing, documentazione, produzione di eLearning, …;
- Numerosità del personale di supporto e diffusione nell‟utilizzo (per attivazione in parallelo di più strutture cliniche);
- Help desk di supporto all‟esercizio ed alla gestione.
- Evoluzione (o struttura di innovazione): con competenze relative all‟innovazione della soluzione, in termini di funzionalità supportate, modalità di interazione con gli utenti, ergonomia, tecnologie hardware e software utilizzate, ecc. Caratteristiche distintive:
- Attenzione ai requisiti utente e forte conoscenza dei processi ospedalieri;
- Conoscenza delle tecnologie informatiche e delle modalità di interazione web allo stato dell‟arte;
- Flessibilità e velocità nella creazione di prototipi da valutare e validare con i referenti clinici;
- Conoscenza del contesto normativo, organizzativo e relazionale in cui il sistema si va ad inserire.
- Forte coesione alla condivisione delle soluzioni nella loro definizione e relativa implementazione a livello di community del riuso al fine che quanto realizzato possa essere recepito e convergere nella versione della soluzione adottata da tutti gli enti aderenti ed evitare disallineamenti o sovrapposizioni funzionali
Il mantenimento delle caratteristiche di cui sopra, in parte antitetiche tra loro, è indispensabile perché la soluzione possa evolvere ed essere utilizzata in ambiti organizzativi più ampi. Allo stato attuale, essa è in uso con soddisfazione da parte degli utenti in altre realtà ospedaliere continua ad evolvere per incrementi, secondo un modello di realizzazione prototipale e comunitario che porterà, nel corso del tempo, all‟aumento delle funzionalità coperte in base alla naturale evoluzione dei processi clinici assistenziali sottesi.
Dal momento che l‟ente ha valutato positivamente l‟introduzione di questa soluzione CCE nella propria realtà, per le attività di formazione, avviamente e conseguente manutenzione e assistenza e per gli aspetti di gestione dell‟esercizio oltre a componenti di evoluzione applicativa, l‟ente è alla ricerca di un fornitore che attui le attività realizzative/gestionali necessarie per il raggiungimento dell‟obiettivo di introduzione capillare ed estensivo del nuovo strumento digitale.
Il Referente del fornitore in qualità di coordinatore dell‟appalto dovrà interagire con il Coordinamento organizzativo della community del riuso - BOARD, responsabile di pianificare, monitorare e coordinare tutte le attività, andando a gestire in particolare:
• nuove funzionalità da realizzare
• supervisione alla progettazione e definizione dei requisiti
• supervisione alla definizione dei mockup
• pianificazione delle risorse
[Digitare il testo]
• supervisione alle fasi di sviluppo
• supervisione alle fasi di test
• supervisione alle fasi di messa in produzione
• definizione e coordinamento dei piani di avviamento e formazione
• piani preventivi e consultivi commesse
• supervisione e verifica livelli qualitativi del servizio
• supervisione e verifica non conformità e attivazione azioni correttive
La programmazione delle attività sarà costantemente aggiornata e pubblicata sul PMIS (Project Management Information System) dell‟ente.
Il fornitore, oltre al precedente, potrà impiegare strumenti propri, che già impiega, di programmazione e di timetable per la gestione dettagliata delle commesse. Il fornitore dovrà descrivere dettagliatamente gli strumenti software impiegati sia da un punto di vista applicativo che organizzativo.
Ad ogni staff meeting di progetto si dovranno riportare gli stati avanzamento lavori illustrando i progressi fatti e le criticità in atto. (vedere paragrafo Riunioni di AvanzamentoLavori).
0.5 Requisiti di erogazione dei servizi
0.5.1 Brevetti industriali e diritti di autore
Le Parti convengono espressamente che funzionalità innovative eventualmente prodotte in esecuzione del presente contratto saranno di piena ed esclusiva proprietà dell‟Ospedale Bianchi Melacrino Xxxxxxx di Reggio Calabria e saranno concesse in riuso a tutte le attuali e future aziende sanitarie pubbliche aderenti all‟iniziativa come parte integrante del riuso CCE iscritto AGID N 284, garanzia peraltro riportata nella scheda descrittiva del catalogo AgID per il software in riuso al numero 284 e nella convenzione sottoscritta dagli Enti.
In particolare si precisa, senza che ciò costituisca limitazione del pieno diritto di proprietà di cui sopra, che il codice sorgente, nonché l‟ambiente di pre produzione e produzione dell‟impianto CCE, funzionali all‟oggetto della presente procedura unitamente alle procedure operative di gestione, saranno di proprietà del committente.
L‟Ente si riserva in ogni momento tutte le operazioni di accesso e di utilizzo del codice sorgente per esigenze interne, anche dopo lo scioglimento del vincolo contrattuale con l‟aggiudicatario per qualunque motivo intervenuto (scadenza, risoluzione, recesso, ecc.).
0.5.2 Riservatezza
Tutte le conoscenze, informazioni, notizie, dati, procedure, applicazioni software, codici sorgenti documenti e formule segrete e nuove (in seguito “informazioni”), trasferite al Fornitore o di cui il Fornitore venga a conoscenza nell‟ambito del contratto, non potranno essere divulgate e/o utilizzate – sia direttamente sia indirettamente – per fini estranei al Contratto.
Agli stessi obblighi sono tenuti i dipendeni e collaboratori del Fornitore (e/o delle Società consorziate).
L‟obbligo di riservatezza si intende esteso anche al periodo successivo alla cessazione del presente accordo e in ogni modo fino a quando le relative informazioni non siano divulgate da parte del legittimo titolare o diventino legittimamente di pubblico dominio.
È fatto obbligo di non rivelare, usare o impiegare, per fini diversi da quelli stabiliti nel presente accordo, qualunque dato, documento o informazione relativi ai diritti esclusivi, alle attività, ai piani o agli affari dell‟altra Parte o di terzi, acquisito nell‟esecuzione del presente contratto, salva l‟autorizzazione scritta dell‟altra Parte o dei terzi medesimi, per quanto di rispettiva competenza.
Alla scadenza del contratto il Fornitore dovrà pertanto restituire e distruggere tutte le informazioni qualunque sia la forma o il supporto su cui sono state trasfuse. Tali informazioni hanno un alto valore strategico per il committente e il loro uso illegittimo o non corretto costituisce inadempienza contrattuale. Conseguentemente il fornitore si obbliga sin da ora a risarcire ogni eventuale danno subito dal committente per effetto dell‟inosservanza dell‟obbligo di riservatezza.
0.5.3 Referente Unico di progetto
L‟Impresa dovrà indicare un suo referente interno, che rappresenterà il punto di contatto al quale l‟Ente appaltante dovrà far riferimento per qualsiasi necessità. Tutte le comunicazioni da e per l‟Impresa dovranno essere effettuate tramite il suddetto referente.
0.5.4 Livelli di servizio SLA
L‟Ente, negli obiettivi di una continuità di servizio senza interruzioni della soluzione applicativa, richiede i seguenti orari di servizio:
attività lavorativa ordinaria con supporto utente on-site:
8:30 – 12:00 -- 13:00 - 17:30 feriali lunedì-venerdì supporto manutentivo, call center con intervento operativo anche on-site:
h24+365 g/anno
[Digitare il testo]
Durante l‟esecuzione del contratto, l‟Ente potrà richiedere al Fornitore di sottostare ad attività di auditing dei servizi forniti. Tali attività potranno essere svolte dai Responsabili individuati dall‟Ente, da persone espressamente delegate, o da una Società esterna appositamente incaricata.
Scopo delle attività di auditing sarà 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 oggetto della presente fornitura, saranno svolte con due diverse modalità su insindacabile scelta dell‟Ente:
• 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 ad esame; Il capitolo riporta gli SLA (Service Level Agreement) che saranno contrattualizzati nell‟ambito dei servizi richiesti.
Gli SLA i cui indicatori sono di seguito riportati dovranno essere tutti indicati in maniera chiara ed esaustiva sui report periodici, report la cui struttura dovrà essere prodotta dal Fornitore ed approvata dall‟Ente.
Tutti i report dovranno essere prodotti su base mensile (dove non diversamente specificato) e inviati entro la prima decade del mese successivo.
Gli indicatori che costituiscono gli SLA sono descritti nella tabella che segue. Si formalizza che i riferimenti di attività per l‟ente sono:
- schede commesse con relativa programmazione e tempistiche di realizzazione commesse: microsoftproject presente nell‟ENTE
- timetable di dettaglio a commessa con riportato preventivo e consultivo aggiornato alla giornata lavorativa corrente. Lo strumento viene messo a disposizione dal fornitore predisponendo l‟accesso on line per la consultazione da parte dell‟ente
- registro delle non conformità presente nell‟ente
- registro dei ticket sul sistema del gestore del help.desk aziendale
- varia documentazione intercorsa tra ente e fornitore
- indicatori degli SLA di servizio descritti nel capitolo di pertinenza
Pertanto la situazione del servizio l‟ente si riserva di desumerla senza preavviso dalla consultazione delle fonti informative di cui sopra e pertanto dalla loro disponibilità, completezza e aggiornamento.
Il prodotto in gestione in modalià di singola funzionalità o in forma aggregata sarà sottoposto a un processo di controllo qualità (impiegando anche metriche ISO/IES) atto a verificare la sussistenza ai livelli qualitativi e quantitativi minimi richiesti.
Il grado rilevato farà scattare segnalazioni di non conformità che al seguito delle azioni correttive attivate forniranno le valutazioni al monitoraggio continuo oggetto della liquidazione delle competenze economiche.
Indicatore | Descrizione |
Mediante relazioni di avanzamento con SAL mensili e timetable commessa di dettaglio settimanale (a preventivo/budget e a consuntivo) per le risorse di progetto per valutare : | • l‟efficienza produttiva in base alle richieste • saturazione effettiva per singolo sottoprogetto o gruppo di attività |
Mediante somministrazione di un questionario su un panel di minimo 5 utilizzatori per rilevare le seguenti componenti che avranno un grade da 1 a 10 (con sei livello sufficiente) | • Funzionalità (adeguatezza, accuratezza, interoperabilità, sicurezza): una sottocaratteristica della funzionalità è l'adeguatezza, ossia la capacità del prodotto software di fornire un insieme di funzioni appropriato per i compiti e gli obiettivi specificati dall'utente; • Usabilità (comprensibilità, apprendibilità, operabilità, attrattività): comprende anche test di accessibilità ai fini del rispetto della legge 4/2004, "Disposizioni per favorire l'accesso dei soggetti disabili agli strumenti informatici", l‟usabilità può essere verificata con test con focus group e direttamente nell‟utilizzo sul campo; • Misura di non decadimento qualità applicativa |
Mediante l‟analisi delle NC o richiesta di assistenza richieste dall‟utente rilevato su un periodo minimo di 15gg relativa alla componente applicativa in verifica o sull‟intero prodotto, valutazione degli indicatori di produzione (quali ad esempio di referti) per rilevare le seguenti componenti che avranno un grade da 1 a 10 (con sei livello sufficiente): | • Efficienza (comportamento rispetto al tempo, uso di risorse) • Affidabilità (maturità – robustezza, tolleranza errori, recuperabilità): l'affidabilità può essere monitorata con la metrica della difettosità e del tempo medio di correzione; |
Mediante l‟analisi delle problematiche rilevati nel ciclo di vita del SW in particolare riguardo gli impatti nelle evoluzioni tecnologiche delle pdl o di delivery su client con piattaforma differente per rilevare le seguenti componenti che avranno un grado da 1 a 10 (con sei livello sufficiente): | • Portabilità (adattabilità, installabilità, coesistenza, sostituibilità): rispetto ai dispositivi di fruizione ed ai relativi ambienti tecnologici (sistema operativo, software d‟ambiente, ecc…). • Manutenibilità (analizzabilità, modificabilità, stabilità, testabilità): capacità del software di essere modificato con un impegno contenuto (per evoluzioni e/o correzioni o adeguamenti); |
Mediante verifiche periodiche a campione un referente qualità designato dall‟ente. La relazione indicherà la | • Leggibilità software |
situazione riscontrata e ne sintetizzerà un giudizio con grado da 1 a 10 (con sei livello sufficiente): | |
Assenza di regressioni delle funzionalità attuali e future per tutta la durata del contratto | • Mantenimento della qualità del software |
coerenza preventivo-consuntivo sulle attività e il rispetto dei tempi stimati | • Rispetto della Pianificazione e consuntivazione |
[Digitare il testo]
0.5.5 Fatturazione
Per quanto concerne i “Servizi iniziali di avviamento” la fatturazione dei corrispettivi sarà autorizzata in relazione al completamento di ogni singolo insieme di attività al raggiungimento delle milestones principali indicate nel cronoprogramma (formazione CCE, formazione terapia, integrazioni CCE, avviamento CCE reparti, avviamento Terapia reparti, avviamento CCE ambulatori, attivazione ricettario, ecc.) sulla base dei prezzi di dettaglio presenti nell‟offerta economica presentata dall‟aggiudicatario.
Per quanto riguarda la fase del contratto a decorrere della conclusione del primo anno, i “Servizi continuativi di gestione” la fatturazione avverrà in base ad un canone trimestrale costante omnicomprensivo calcolato in base al prezzo globale offerto dall‟aggiudicatario ripartito sui 8 trimestri di erogazione previsti sui due anni, con maturazione a decorrere dal primo trimese successivo alla conclusione del primo anno del contratto.
La fatturazione dei “Servizi evolutivi e di supporto locale” avverrà alla conclusione con esito positivo di quanto autorizzato preventivamente da specifico buono d‟ordine emesso specificatamente per la realizzazione di quanto convenuto dalle parti. La valorizzazione delle tariffe avverrà mediante apposito listino prezzi definito dall‟appalto in sede di aggiudicazione.
0.5.6 Monitoraggio continuo e decurtazione del canone
L‟Ente appaltante adotterà, fin dalla fase di avvio del servizio, un monitoraggio continuo per valutare la corretta attivazione ed erogazione dei servizi come da contratto e il non degrado delle funzionalità richieste in termini di performance e contenuti.
Nel caso in cui la rilevazione evidenziasse situazioni di criticità, l‟impresa sarà tenuta ad intervenire a ripristinare il livello di performance nominale (Service Level Agreement). Al riscontro dello stato di degrado, con permanenza oltre ai limiti descritti nell‟Allegato Tecnico, nell‟ambito del monitoraggio e liquidazione delle competenze mensili, verranno attivate le decurtazioni sul canone così commisurate:
LIVELLO DI INEFFICIENZA | DECURTAZIONE CANONE |
Nessuna inefficienza | 0 % |
Diminuzione di efficienza: non compromette lo svolgimento delle funzioni | fino al 30 % |
Diminuzione di efficienza marcata: alcune funzionalità sono compromesse | fino al 60 % |
Efficienza insufficiente: lo svolgimento di alcune operazioni è impedito | fino al 80 % |
Efficienza nulla: il servizio non può essere utilizzato | fino al 100 % |
La decurtazione del canone avverrà in seguito a richiesta motivata degli organi tecnici competenti dell‟Ente che potranno, in base a valutazioni del momento, decidere di applicare valori percentuali di decurtazione intermedi rispetto agli scaglioni suindicati.
L‟impresa potrà opporsi alla contestazione, entro 15 gg. solari dalla notifica della scheda di monitoraggio periodico, con motivate controdeduzioni scritte.
Per le attività di implementazione o evolutive, e in particolar modo nella fase contrattuale iniziale di avviamento ed estensione dell‟impianto entro il primo anno, le modalità e tempistiche attuative saranno definite tramite il cronoprogramma di progetto, che viene recepito in prima versione quello derivato dal progetto presentato dall‟aggiudicatario, e modificato con successive versioni tramite formalizzazione delle parti.
Ogni scostamento di programmazione sul cronoprogramma in vigore, fermo restando quanto previsto per i casi di Risoluzione del Contratto e salvo il risarcimento dell‟eventuale maggior danno, l‟Ente appaltante si riserva, a sua discrezione e senza formalità, di applicare una penale pari ad Euro 1.000,00 per ogni giorno di ritardo rispetto ai termini stabiliti dal cronoprogramma sottoscritto dalle parti ovvero per ogni violazione degli obblighi contrattuali previsti nel presente CSA.
NB Il fornitore potrà proporre delle specifiche metriche per la determinazione dello stato di efficienza dell‟impianto, e di conseguenza algoritmi di calcolo del grado % di inefficienza, e in contradditorio con l‟ente potranno essere assunte come metriche per il monitoraggio. In assenza di questo l‟ente effettuerà il monitoraggio in modo qualitativo supportato da indicatori quali: ticket di richiesta assistenza inevasi con anzianità > 15gg , non conformità notificate, livello di gradimento da parte dell‟utenza mediante segnalazioni di lamentele, persistenze di malfunzionamenti o inefficienze operative.
0.5.7 Risoluzione contrattuale
In conformità al disposto di cui all‟art. 1456 del Codice Civile (clausola risolutiva espressa) il contratto potrà essere risolto mediante semplice lettera raccomandata con messa in mora di 15 giorni, senza necessità di ulteriori adempimenti, nei seguenti casi:
• reiterate interruzioni della funzionalità dell‟impianto gestito e degli stessi servizi oggetto della fornitura;
• eccessivo scostamento dai valori di soglia degli SLA richiesti;
[Digitare il testo]
• lacunosa e ritardata presentazione dei report di attività;
• ritardo grave nell‟esecuzione degli interventi di manutenzione;
• mancata o lacunosa attivazione del servizio in difformità da quanto previsto nel Capitolato Tecnico e in particolare nel paragrafo “progetto di avviamento”;
• non completamento della fase di avviamento del sistema entro 6 mesi dalla decorrenza del contratto;
• inosservanza del codice etico aziendale e regionale;
• inosservanza delle prescrizioni del precedente articolo 9.
La risoluzione del contratto comporterà l‟incameramento del deposito cauzionale nonché il risarcimento dei danni subiti dall‟Ente Appaltante.
L‟impresa si dovrà attenere alla vigente normativa riguardo all‟interruzione di pubblico servizio e dovrà rispettare completamente le esigenze operative degli enti e prestare piena collaborazione per assicurare il subentro meno problematico possibile di altra impresa nell‟esecuzione del contratto.
0.6 Piano di comunicazione
Questa sezione del documento descrive le modalità adottate per gestire le comunicazioni all‟interno del progetto, include quindi la matrice di coordinamento di tutti i partecipanti, una descrizione delle Riunioni di Avanzamento e dei Report di Avanzamento.
0.6.1 Riferimentigruppo di lavoro Ente
L‟elenco delle persone di riferimento dell‟Ente sarà comunicato successivamente all‟aggiudicazione della gara.
NOME | FUNZIONE | TELEFONO | |
0.6.2 Riferimenti del gruppo di Lavoro del fornitore
I nominativi delle figure professionali del fornitore coinvolte nel progetto saranno specificate nella riunione di avviamento:
NOME | FUNZIONE | TELEFONO | FAX | |
0.6.3 Le riunioni: modalità
Le riunioni formali saranno un momento di incontro e discussione dei partecipanti al progetto, e quindi saranno organizzate e gestite secondo quanto qui di seguito riportato, fatte salve modalità specifiche descritte nei paragrafi successivi.
Convocazione
La convocazione della riunione potrà essere effettuata, in funzione dell‟oggetto della riunione stessa, da un Project Manager (PM) o da un altro dei referenti identificati nei Gruppi di Lavoro del Fornitore o dell‟Ente.
Verbalizzazione
In sede di riunione (o subito dopo) sarà redatto dal Fornitore un verbale, che sarà inviato per revisione a tutti i partecipanti alla riunione stessa, per posta elettronica, fax o altro mezzo, entro 5 giorni lavorativi.
Le revisioni, per poter essere incorporate, dovranno pervenire entro 5 giorni lavorativi dalla data di invio della bozza del verbale, trascorsi i quali il documento sarà consolidato, inviato a tutti i partecipanti ed archiviato.
0.6.4 Riunioni di AvanzamentoLavori
0.6.4.1 Scopo
Gli avanzamenti del progetto sono controllati attraverso i Rapporti sulloStato di Avanzamento Lavori (Project Progress Report) durante le Riunioni di Avanzamento Lavori che si terranno con cadenza che sarà stabilita di comune accordo tra le parti.
Il Project Progress Report (PPR) e‟ un documento, il cui schema redatto dal Fornitore con cadenza mensile, entro i primi 5 giorni lavorativi del mese successivo. Tale report e‟ inviato all‟Ente almeno due giorni prima della relativa Riunione di Avanzamento, durante la quale esso sarà esaminato, confrontato con la pianificazione corrente ed infine approvato.
Cadenze diverse potranno essere concordate con l‟Ente a seconda dell‟opportunità e del periodo di progetto (report più frequenti, ad esempio mensili, nei periodi di maggiore criticità, quale la fase di transizione, e più diradati successivamente, a regime operativo).
[Digitare il testo]
Le riunioni di avanzamento potranno anche non tenersi in modo formale nel caso in cui ci siano situazioni di difficoltà ad organizzare gli incontri. In questi casi il Project Manager prepara il Project Progress Report alla luce delle informazioni che saranno state acquisite in incontri ristretti, aggiornamenti telefonici (o conference call), o altre modalità di comunicazione (e-mail, etc.) che saranno di volta in volta stabilite.
Qui di seguito sono brevemente descritte le modalità di svolgimento delle riunioni periodiche di avanzamento lavori, sia interne che esterne, ed i vari tipi di report e documenti associati.
0.6.4.2 Report di avanzamento (Project Progress Report)
Il Project Progress Report (P.P.R.), preparato direttamente dal Project Manager del Fornitore, o da qualche altro collaboratore sotto la sua supervisione, riporta le seguenti informazioni:
• Attivitàsvolte secondo ipiani
Viene riportata una breve descrizione delle attività previste nel periodo ed i risultati ottenuti. Commenti alle attività svolte vengono aggiunti se ritenuti interessanti.
• Attivitàpianificate ma non eseguite
Vengono elencate le attività previste e non eseguite, unitamente alle motivazioni che hanno reso impossibile l‟esecuzione (ritardi di esecuzione, ripianificazione, cancellazione dell‟attività, etc.). Se ci sono date di ripianificazione, essevengonoriportate.
• Attivitàsvolte ma non pianificate
Si tratta di attività che non erano state pianificate ma che sono state eseguite a seguito di necessità contingenti (anticipazione di attività, nuove attività richieste con procedure di change management, etc.)
• Obiettivi di prossimoperiodo
Vengono elencati i principali obiettivi del prossimo periodo.
• Problemi e Warnings
Questa sezione serve ad illustrare i principali problemi incontrati, o solo previsti, che possono influenzare negativamente la riuscita del progetto e sui quali il team di progetto e‟ chiamato alla massima collaborazione ed attenzione, al fine di rimuoverli o di aggirarli.
0.6.4.3 Diagrammi di GANTT e pianificazione risorse
Con cadenza da valutare congiuntamente tra il Fornitore e l‟Ente (tipicamente unitamente ai PPR), saranno emessi dal Fornitore diagrammi di GANTT aggiornati in modo da fornire un maggior dettaglio sullo stato del progetto e sulla pianificazione, tali diagrammi rappresentano la pianificazione di base rispetto alla quale viene verificato l‟avanzamento lavori.
La scheda con il GANTT contiene:
• Identificativodellaattività
• Nome attività
• La percentuale del risultato stimato dal project manager
• Le date di inizio e fine delle attività previste
• Le date di inizio e fine effettive
0.6.4.4 Report di Eccezione
Il “report di eccezione” (Exception Report) è un segnale che il Project Manager manda al Comitato di Controllo e Revisione, per avvisarlo che una o più fasi del progetto devieranno al di fuori dei margini di tolleranza.
Il “report di eccezione” descrive la deviazione prevista rispetto ai piani, fornisce una analisi sia della eccezione sia delle scelte disponibili per il prosieguo, e suggerisce la scelta più opportuna.
Il Report di eccezione contiene:
• una descrizione della causa di deviazione del piano
• conseguenzedelladeviazione
• le sceltedisponibili
• l'effetto di ogni scelta sul progetto
• isuggerimenti del Project Manager
Un report di eccezione di solito conduce ad una riunione per l‟approfondimento della materia e per stabilire la decisione finale.
0.6.4.5 Riunioni di avanzamento con l’Ente
Per tutta la durata del contratto si terranno riunioni periodiche (circa quindicinali in fase di transizione, più rade in fase di erogazione) per la discussione dei report di avanzamento fra il Fornitore e l‟Ente.
Il Fornitore sottoporrà all‟Ente il report sullo “Stato di Avanzamento Lavori” secondo le modalità già descritte nei paragrafi precedenti. Il verbale della riunione di avanzamento includerà:
• Listadeipartecipanti
• Approvazionedell‟agenda
• Discussione del report sullo “Stato di Avanzamento Lavori”
• Evoluzioni sui punti aperti del precedente incontro
[Digitare il testo]
• Sommario di tutti i punti ancora aperti e tempistiche di chiusura
• Accettazione formale dei rilasci di progetto
• Stato delle richieste di modifica al progetto
• Problemicontrattuali
• Pianificazione di eventuali riunioni su specifici temi
• Varie
• Scelta della data per l‟incontro successivo
Il Fornitore potrà richiedere all‟Ente correzioni al verbale dell‟incontro di avanzamento entro cinque giorni lavorativi dalla ricezione dello stesso. Le correzione dovranno essere concordate in modo che la versione finale sia accettata prima della successiva riunione di avanzamento. Questo allo scopo di evitare che il successivo incontro abbia luogo senza un accordo sui punti discussi nel precedente.
0.6.4.6 Riunioni di coordinamento
Incontri a carattere tecnico tra personale dell‟Ente e del Fornitore potranno essere richiesti quando necessario dai rappresentanti di entrambe le parti.
Tali incontri saranno gestiti con le modalità già viste per le riunioni, fatte salve le eventuali semplificazioni procedurali che si dovessero convenire necessarie per snellire l‟operatività quotidiana.
In particolare si potrà concordare, per temi specifici, di non procedere ogni volta alla redazione/approvazione dei verbali di riunione, ma di lavorare congiuntamente alla redazione di un documento (es. specifica, procedura, report, etc.) da far evolvere in occasione di ogni incontro.
0.6.4.7 Interfaccia con il l’Ente ed “Escalation Path”
Durante il progetto, il Project Manager deve essere allertato di ogni situazione causante inefficienza e perdita di tempo. E‟ sua responsabilità identificare queste situazioni e correggerle. Egli deve predisporre i “sensori” appropriati ed essere pronto a rispondere con rapidità quando insorgono problemi.
I problemi che non possono essere risolti internamente al progetto, devono essere scalati al Comitato di Controllo.
0.7 Procedure e standard di qualità
Sono riportate qui di seguito le informazioni più importanti per il mantenimento degli standard qualitativi delle attività di gestione e controllo del progetto, per quanto attiene ai contenuti del presente documento.
L‟ente individua (a titolo esemplificativo non esaustiva) la seguente documentazione ISO a completo carico del servizio, oggetto della presente fornitura, in termini di redazione e aggiornamento continuo:
- scheda di impianto con PCE piano continuità ed emergenza
- scheda di progetto/commessa
0.7.1 Procedure generali tra il Fornitore e l’Ente
Lo scopo di queste procedure é facilitare il Project Management nel formalizzare e mantenere un archivio storico di tutte le relazioni importanti fra il Fornitore ed il corrispondente Project Manager dell‟Ente.
La procedura di gestione delle segnalazioni registra e gestisce tutte quelle che nascono durante il ciclo di vita del progetto; fornisce le informazioni sul loro stato, controlla tutto il loro processo e fornisce il feedback a chi ha emesso la segnalazione circa le azioni che sono state intraprese di conseguenza.
Questo capitolo spiega il modo in cui vengono sollevati problemi e suggerimenti, ed il meccanismo all'interno del metodo per gestire i vari tipi di segnalazioni.
0.7.1.1 Tipologia delle segnalazioni
Il processo delle segnalazioni é innescato al nascere di una criticità sul progetto, per documentare un cambiamento all'interno del progetto stesso oppure un errore riscontrato in uno delle sue parti.
Una segnalazione, che ogni membro del gruppo di progetto (Ente o Fornitore) può originare, é in generale un problema riscontrato, una differenza di opinioni, un suggerimento o una questione in sospeso, che richiede per la sua chiusura lo svolgimento di una serie di attività.
Se la segnalazione non può essere analizzata e risolta immediatamente, dovrà essere documentata e tracciata attraverso questa procedura, che gestirà pertanto solo le più significative.
Si richiede quindi al Fornitore la creazione della procedura necessaria a gestire e regolare quanto sopra esposto.
0.7.1.2 “Follow up” delle azioni
Durante il ciclo di vita del progetto viene richiesto al Project Manager di mantenere una lista delle azioni che sono state intraprese a seguito di una segnalazione; ovviamente una o più azioni possono essere necessarie per dar seguito ad una segnalazione, a seconda della sua tipologia e complessità.
[Digitare il testo]
❑ Ogni azione deve essere assegnata ad una risorsa ben identificata, e la lista viene riesaminata durante le riunioni di avanzamento.
0.7.2 Standard per la produzione di documentazione
Di seguito indicazioni su come dovrebbe essere organizzato un documento:
0.7.2.1 Formato di un documento
Tutta la documentazione prodotta deve essere sottoposta a controllo di revisione, indicando la storia delle modifiche:
• Autore
• Versione
• Data
• Stato del documento
• Etc.
0.7.2.2 Linguaggio dei Documenti
Salvo quando diversamente concordato tra le parti, tutti i documenti sviluppati per il progetto saranno redatti e consegnati in lingua italiana.
0.8 Piano di implementazione
Il Fornitore dovrà produrre nell‟ambito del progetto presentato in gara un programma che esplichi in maniera esaustiva le modalità di attuazione della fornitura presso l‟Ente dettagliando attività, tempi, risorse e procedure operative.
Il progetto esecutivo presenta la pianificazione di massima che consente di individuare i “majordeliverables” e le date con i principali milestones di progetto.
Il piano deve essere suddiviso in più fasi, come di seguito riportate:
Fase | Descrizione |
P1 | Fase di Adempimenti Contrattuali (dalla delibera di aggiudicazione alla firma del contratto) |
P2 (duratamax 1 mese calendariale) | Fase di Predisposizione dei servizi (periodo in cui il Fornitore si prepara ad erogare i servizi in fornitura) |
P3 Data inizio = t0 | Fase di Avviamento (fase in cui il Fornitore prende effettivamente in carico i servizi in fornitura e avvia/prende in carico le aree ospedaliere prototipali). Il numero di persone che costituisce il presidio dovrà essere quanto dichiarato in offerta. In tale periodo introduce ed esegue gli adeguamenti/integrazioni necessari al corretto funzionamento richiesti. Questa fase indica l’attivazione del periodo contrattuale |
P4 Data fine = t0 + 12 mesi | Fase di Estensione (fase in cui il Fornitore estende l’utilizzo dello strumento in tutte le aree ospedaliere) il numero di persone che costituisce il presidio dovrà essere quanto dichiarato in offerta. In tale periodo effettua adeguamenti o integrazioni di personalizzazioni necessarie alle diverse aree specialistiche interessate dall’estensione. |
P5 Data fine = t0 + 30 mesi | Fase di Regime Operativo (fase in cui il Fornitore ha completato l’estensione in tutto l’ente) il numero di persone che costituisce il presidio dovrà essere quanto dichiarato in offerta. Le attività evolutive vengono individuate e condivise con l’ente secondo specifiche necessità |
[Digitare il testo]
L’esecuzione della fasi P3 e P4 delle attività di avviamento ed estensione, dovrà avere tassativamente completata in 360 giorni continuativi. Non saranno accettate offerte difformi da tale postulato. In caso di non completamento delle suddette attività entro il termine stabilito l’Ente appaltante si riserva, inoltre, il diritto di risoluzione immediata del contratto con diritto di rimborso, da parte dell’appaltante, di tutti gli oneri contrattuali patiti, fatti salvi i danni eventualmente emergenti.
Il fornitore deve analizzare e predisporre un piano di attività (presentato in bozza nel progetto di gara) che illustri il piano strategico dalla presa in carico del servizio e il raggiungimento della milestone di avviamento ed estensione della soluzione prodotto nella configurazione target.
Nel progetto di gara il fornitore deve dichiarare in modo chiaro le modalità e la tempistica al raggiungimento del servizio CCE nella modalità regime come descritto nella parte tecnica strategica di prodotto.
Si precisache:
o Tutti i Servizi di Gestione devono essere forniti dall‟aggiudicatario per tutta la durata contrattuale, ivi compresa la fase Avviamento ed Estensione.
o Il dimensionamento dei Servizi DBA ed Infrastruttura a livello Application sarà a carico dell‟aggiudicatario in base alle strategie di implementazione del progetto ed al rispetto della continuità di servizio.
L‟aggiudicatario prendere in carico il progetto che ha avuto già le seguenti Milestones in stato CONCLUSO:
[Digitare il testo]
Mentre nell‟ambito delle fasi P3-P4 dovrà effettuare le seguenti milestones:
NB: La declinizazione delle milestones sopracitate in dettagliato cronoprogramma e strategia evolutiva sarà propria del progetto di implementazione richiesto dall’appalto e oggetto di valutazione per l’aggiudicazione
0.9 EXIT MANAGEMENT
Nel presente paragrafo vengono descritte le attività e le procedure che saranno richieste al Fornitore nella fase finale del rapporto contrattuale, per il rilascio del servizio, per il passaggio delle consegne al subentrante designato (Fornitore Entrante) dall‟Ente e per il trasferimento al relativo personale di tutte le conoscenze necessarie a garantire la fluida transizione nella erogazione e la continuità operativa per l‟utenza dei servizi in fornitura dell‟Ente.
Alla scadenza del contratto il Fornitore presterà l‟assistenza necessaria a trasferire la gestione dei servizi all‟Ente o al nuovo Fornitore per un periodo pari agli ultimi due mesi di contratto.
La fase di Exit management, oltre a quanto detto, contempla i seguenti aspetti:
• fornitura del servizio e delle modalità di garanzia di continuità nella fase di trasferimento;
• gestione del processo di trasferimento: ruoli, responsabilità, autorizzazioni e risorse da assegnare;
• diritti di proprietà intellettuale: accordi necessari, licenze, etc.;
• due diligence: definizione della documentazione e dei contenuti da trasferire al fornitore che subentra, nonché la definizione delle altre obbligazioni e penalità previste;
• contratti e licenze;
• sicurezza;
• piano di comunicazione.
Di seguito si riporta una traccia dei contenuti e delle caratteristiche qualificanti dell‟attività di Exit, che saranno gestite in ambito Comitato di Governance dei servizi, relativamente a:
• oggetto della transizione, attività e relative modalità di esecuzione
• compiti e responsabilità di ciascuna delle parti
Le caratteristiche qualificanti si riconoscono nei seguenti aspetti:
• Piano di Transizione:
o le attività di affiancamento e rilascio sono specificate e governate da uno specifico Piano di Transizione, in cui saranno riportate tutte le attività previste in termini di tempi, risorse impiegate, punti di verifica e controllo dei risultati attesi, criteri di accettazione, i rischi, la cadenza degli incontri per la verifica dello stato di avanzamento delle attività;
• Responsabilità:
o durante il periodo di affiancamento e migrazione al termine del Contratto, la responsabilità dei Servizi viene mantenuta dal Fornitore fino al termine previsto contrattualmente;
• Governo del processo:
o Il Fornitore assicura tutte le attività finalizzate a coordinare e verificare la corretta ed efficace esecuzione delle attività di Affiancamento e Rilascio nel rispetto dei termini concordati nonché la coerenza con i requisiti, i vincoli ed i termini stabiliti nei documenti contrattuali; a tale scopo viene individuata una figura unica per il Fornitore (Project Manager) che coordinerà tutte le attività e che interfaccerà l‟Ente ovvero l‟eventuale Fornitore terzo subentrante;
• Continuità dei servizi:
o al fine di garantire all‟Ente il mantenimento dei richiesti livelli di servizio da parte del subentrante, nel Piano di Transizione sono previste fasi di verifica e validazione sia del trasferimento di know-how che del rilascio della documentazione; altresì, contestualmente al trasferimento delle conoscenze, si prevede un adeguato periodo di affiancamento delle risorse del subentrante nella operatività corrente del Fornitore uscente;
• Risorse professionali:
[Digitare il testo]
o un gruppo di risorse del Fornitore appositamente designato affiancherà le risorse dell‟Ente e/o del Fornitore subentrante per il trasferimento delle conoscenze sui servizi e sulle relative attività di gestione; il team (minimo 2 persone) sarà composto da personale già impegnato nell‟erogazione dei servizi;
• Customer Care:
o al fine di minimizzare l‟impatto del passaggio di consegne dal vecchio al nuovo gestore dei servizi nei riguardi degli utenti del Sistema.
In particolare il Fornitore si deve impegnare a soddisfare i seguenti requisiti generali:
• durante la fase finale, fino al termine del periodo contrattuale, non vi saranno impatti o interruzioni del servizio causate specificamente dalle attività di passaggio di consegne;
• analogamente, in tale periodo, non vi saranno decadimenti dei livelli di servizio, specificamente imputabili al passaggio delle consegne e all'affiancamento del personale del Fornitore con quello subentrante;
• nel medesimo periodo, dal punto di vista dell‟utente finale, non vi saranno significativi cambiamenti, specificamente imputabili al passaggio delle consegne, che possano inficiare le attività operative.
Per quanto riguarda la presa in carico del servizio da parte del subentrante, il Fornitore si impegna a mettere a disposizione, nelle modalità di seguito indicate, tutto il proprio personale responsabile e preposto ai servizi contrattualmente previsti, ad attività quali le seguenti:
• addestramento del personale subentrante, prevalentemente con affiancamento e in modalità on the job, finalizzato alla rapida acquisizione da parte di quest'ultimo delle conoscenze specifiche dei sistemi informativi e dei servizi oggetto del contratto;
• illustrazione della gestione del servizio e delle relative procedure di servizio in essere alla data e messa a disposizione di tutta la relativa documentazione.
La fase finale del periodo contrattuale sarà finalizzata, da una parte, alla prosecuzione dei servizi contrattualmente previsti, con il mantenimento dei livelli di servizio consolidati, dall'altra, a mettere in grado il personale tecnico indicato dall‟Ente ad un efficace subentro nei servizi in questione. Per tale ragione, il Fornitore si deve impegnare nei confronti del subentrante ad un completo passaggio delle consegne ed alla fornitura di tutta la documentazione e il supporto necessari a consentire un agevole avvio del nuovo ciclo di servizio.
Gli obiettivi di cui sopra saranno raggiunti organizzando le attività nelle seguenti fasi:
• fase di programmazione del passaggio di consegne:
o predisposizione e raccolta della documentazione per il passaggio di consegne (procedure, report, strumenti, …);
o riunione preparatoria con l‟Ente;
o pianificazione incontri di passaggio delle consegne;
• fase di affiancamento:
o consegna della documentazione per il passaggio di consegne;
o effettuazione degli incontri finalizzati al passaggio delle consegne;
o training on the job (affiancamento) del personale subentrante per consentire la prosecuzione dei servizi senza significativi decadimenti di qualità.
Viene richiesto inoltre di allegare nel progetto una proposta di EXIT MANAGENT GESTORE CORRENTE da sottoporre all’attuale gestore del servizio nelle medesime modalità illustrate nel presente paragrafo.
0.10 Gestione del rischio
La gestione dei rischi è un controllo importante nell‟ambito di un progetto; e‟ opportuno tenere traccia di tutti i rischi identificati, la loro analisi, le contromisure adottate e lo status.
Questa gestione deve partire all‟inizio del progetto e continuare fino alla sua chiusura; i rischi devono essere revisionati periodicamente, almeno alla conclusione di ogni fase, durante le Riunioni di Avanzamento.
In modo proattivo ogni aggiornamento del progetto di rischio dovrà essere sottoposto al comitato di controllo unitamente alla proposta di azioni per mitigare i rischi.
Il fornitore deve inserire nella documentazione di gara una prima proposta di gestione del rischio.
0.10.1 Definizione di rischio
Un rischio e‟ la possibilità del verificarsi di un evento con una conseguenza negativa. Puòessereidentificatoponendosidomande come:
• Che cosa può andare storto?
• Quando e come potrebbe andare storto?
• Quali potrebbero essere le ragioni del problema? (tecniche, interne, esterne)
• Che cosa ci indica che il problema sta per verificarsi?
• Quali sono le conseguenze (irrilevanti, gestibili, catastrofiche ..)?
• Quale e‟ la probabilità che l‟evento si verifichi?
La necessità di gestire i rischi nei progetti è rinforzata dalla frequenza dei problemi che causano i fallimenti dei progetti. I rischi necessitano di essere identificati e gestiti a livello appropriato.
[Digitare il testo]
0.10.2 Controllodeirischi del progetto
Nel corso della vita del progetto, il Project Manager del Fornitore terrà aggiornata una tabella con la lista dei principali rischi e delle possibili azioni preventive.
La tabella è intesa per l‟uso da parte del Project Management per la gestione giorno per giorno del progetto, e riporta le informazioni qui di seguito elencate:
• classificazione del rischio, in base alla gravità delle sue conseguenze come:
• Critico
• Alto
• Medio
• Basso
• Valutazione, che può essere di accettazione o rifiuto,
• Breve descrizione delle azioni da intraprendere, che possono essere di:
• Prevenzione
• Riduzione
• Trasferimento
• Accettazione
Identificazione | Criticità | Valutazione | Azione |
Le azioni correttive saranno discusse dai partecipanti al progetto nel corso delle Riunione di Avanzamento. Qui di seguito è riportato, a titolo di esempio uno schema generale.
0.11 Ruoli e competenze delle risorse professionali richieste
In questo paragrafo vengono brevemente illustrati i profili professionali e le competenze minime delle risorse ritenute indispensabili per l‟erogazione dei servizi.
Sarà responsabilità del Fornitore adeguare in termini qualitativi e quantitativi, per tutta la durata del contratto, le risorse utilizzate in modo tale da garantire gli SLA di capitolato.
L‟Ente si riserva di valutare e segnalare incompatibilità del personale (elencato in seguito nelle figure principali) predisposto dal Fornitore per l‟erogazione del servizio e richiederne la sostituzione.
Nel documento di progetto del fornitore dovrà descrivere in modo dettagliato le figure e skill messe a disposizione ad integrazione di quello citato nel seguito a titolo esemplificativo.
0.11.1 Responsabile del Contratto (Client Manager)
Il Client Manager è una figura professionale di alto livello ed elevato profilo gerarchico, con forti doti di leadership e capacità manageriali, il cui ruolo è caratterizzato dalle seguenti responsabilità:
• essere l‟interfaccia del Fornitore;
• garantire la congruità tra quanto riportato nel contratto con quanto erogato;
• verificare lo stato dell‟erogazione dei servizi e della relazione con l‟Ente e organizzare gli incontri di revisione previsti;
• proporre e giustificare, in termini di costi, benefici, tempi e rischi, le soluzioni per il miglioramento continuo;
• farsi parte diligente e cooperare nella risoluzione dei conflitti o problemi che potrebbero sorgere durante lo svolgimento del contratto;
• attivarsi per le approvazioni e seguire il raggiungimento degli scopi/obiettivi;
• fornire informazioni accurate e tempestive per la gestione amministrativa e contabile del contratto.
0.11.2 Responsabile di Programma (Program Manager)
Il Program Manager è una figura professionale di alto livello, responsabile dell‟intero Team di Lavoro durante il quale vengono erogati i servizi oggetto del capitolato e risorsa di riferimento per quanto attiene l‟erogazione e la gestione dei servizi richiesti. E‟ quindi l‟interfaccia verso l‟Ente per la gestione dei rapporti e delle relazioni operative. Il suo ruolo è caratterizzato dalle seguenti responsabilità:
• organizzazione complessiva dei servizi, in riferimento al dimensionamento delle risorse, alle modalità operative (turnazione dei tecnici o degli operatori), al mantenimento degli skill professionali delle risorse;
• predisporre ed eseguire tutte le attività previste per raggiungere nei tempi stabiliti i livelli di SLA contrattuali;
• integrare gli apporti di tutti i partecipanti al programma complessivo, in ottica di team;
• verificare lo stato di sviluppo delle singole attività, intervenendo con gli opportuni correttivi sugli scostamenti temporali e realizzativi;
• definire, per ogni processo di sviluppo, le procedure operative;
• ricercare l‟ottimizzazione dei singoli processi, attraverso la loro integrazione;
• verificare ed eventualmente attuare le modifiche e le integrazioni richieste dall‟Ente;
[Digitare il testo]
• predisporre la documentazione e i report periodici;
• validare e coordinare i piani per la realizzazione di singoli progetti/eventi;
0.11.3 Responsabile di Progetto (Project Manager)
Il Project Manager è una figura professionale di alto livello che, coordinata dal Program Manager, è responsabile del Team di Lavoro di un singolo progetto di evoluzione e manutenzione di una componente applicativa o di un determinato servizio oggetto del capitolato. E‟ quindi anche risorsa di riferimento per quanto attiene l‟erogazione e la gestione dei servizi richiesti nel dato ambito specifico. Il suo ruolo è caratterizzato dalle seguenti responsabilità:
• organizzazione di dettaglio del singolo servizio, in riferimento al dimensionamento delle risorse, alle modalità operative (turnazione dei tecnici o degli operatori), al mantenimento degli skill professionali delle risorse;
• predisporre ed eseguire tutte le attività previste per raggiungere nei tempi stabiliti i livelli di SLA contrattuali, per il dato servizio;
• integrare gli apporti di tutti i partecipanti al singolo progetto, in ottica di team;
• verificare lo stato di sviluppo delle singole attività, intervenendo con gli opportuni correttivi sugli scostamenti temporali e realizzativi, per il dato progetto;
• collaborare alla predisposizione della documentazione e dei report periodici per il dato progetto;
• recepire le esigenze di evoluzione o manutenzione di una componente applicativa ed effettuare la prima analisi (demand management).
0.11.4 Progettazione, Analisi e Sviluppo
E‟ una figura professionale che svolge le attività di indirizzo e di standard progettuale caratterizzata dai seguenti skill:
· capacità relazionale di coordinamento e gestione del contenzioso
· esperienza di attività di sviluppo software (Java base, J2EE, JSF, EJB, Hibernate), testing (funzionale, unità e integrazione), analisi dei requisiti (conoscenza di metologie per l‟analisi processi e di procedure, analisi requisiti funzionali con traduzione in requisiti tecniche di sviluppo applicativo, analisi organizzazione dati su architetture database relazionali con logiche di integrità del dato) e progettazione (UML)
· Progettazione ed evoluzione degli standard dell‟architettura applicativa
· Verifica congruità dei dati e dei flussi di comunicazione della CCE da e verso il middleware di integrazione e più in generale verso tutti gli altri sistemi informativi
· Analisi proattiva delle incongruenze e loro risoluzione
· Attivazione di soluzioni di monitoraggio continuo per l‟innalzamento della qualità del dato e la verifica della qualità di interscambio delle comunicazioni
· pianificazione e controllo delle attività del team
0.11.5 Analisi e Sviluppo
E‟ una figura professionale che svolge tutti i servizi di pertinenza nel ciclo di vita del sofware dall‟analisi allo sviluppo e test caratterizzate dai seguenti skill.
Gli skill (non esaustivi) caratterizzanti di tipo tecnico sono i seguenti:
· esperienza di attività di sviluppo software (Java base, J2EE, JSF, EJB, Hibernate), testing (funzionale, unità e integrazione), analisi dei requisiti (conoscenza di analisi requisiti funzionali con traduzione in requisiti tecniche di sviluppo applicativo, analisi organizzazione dati su architetture database relazionali con logiche di integrità del dato) e progettazione (UML)
· J2EE (JSF, EJB, Hibernate)
· Testing (funzionale, unità e integrazione)
· UML
Il servizio dovrà occuparsi dello sviluppo di manutenzione e correzione del Software seguendo una metodologia di bug-fixing.
· Bug (dovuti a segnalazioni di HD che a segnalazioni/rilevazioni interne all‟ICT Niguarda)
· Adeguamenti normativi
Il servizio dovrà occuparsi dello sviluppo del Software secondo la pianificazione definita
Lo sviluppo deve avere una precisa metodologia di sviluppo e prevedere oltre allo sviuppo l‟appropriata documentazione, criteri di performance e di test.
Nello specifico si devono prevedere gli opportuni deliverable per le seguenti attività:
· Analisi
· Up-front design
· Sviluppo
· Testing
· Documentazione
0.11.6 Supporto e tutor
E‟ una figura professionale caratterizzata dai seguenti skill:
• capacità relazionale e gestione del contenzioso
[Digitare il testo]
• esperienza di attività di call center ed help desk
• esperienza di attivita di formazione all‟utilizzo di applicativi web
• conoscenza dei processi tipici delle aziende sanitarie e dei ruoli degli utenti del sistema informativo ospedaliero
• capacità di definizione del piano di avviamento e relativa conduzione
Nell‟ambito del processo formativo il prodotto deve essere corredato da materiale che faciliti l‟autoapprendimento operativo dell‟utente in modalità e–learning.
Il prodotto finale sarà quindi costituito da learningobject corredati di audio, elaborati secondo lo standard scorm, ed erogabili con piattaforma Docebo.
I learningobject devono corrispondere alle sezioni logiche nelle quali e‟ suddiviso l‟applicativo.
Il materiale base per la preparazione dei learningobject deve essere costituito da powerpoint costruito con le immagini dell‟applicativo inserito nel layout aziendale . La quantità di immagini necessarie a costituire il learningobject deve essere proporzionale alle istruzioni operative necessarie perché l‟utente utilizzi correttamente l‟applicativo. La presentazione grafica deve essere priva priva di “eccessive grazie”, essere standardizzata e il piu‟ possibile conforme a quanto già nella proposta formativa aziendale. Il prodotto deve essere poi gestito nella sua fase di erogazione sulla piattaforma.
Qualora sia richiesto dalle condizioni di avviamento, e‟ possibile che venga prevista la figura di uno o piu‟ tutor. A seconda della scelta di formazione/avviamento il tutor affianca l‟utente finale nell‟utilizzo dell‟applicativo in fase di simulazione in aula, oppure nella realtà lavorativa. Il tutor non puo‟ essere una figura di puro sviluppatore: deve conoscere l‟applicativo e la realtà dove viene applicato, essere una persona comunicativa, che sappia interagire con l‟utente finale rispettandone il ruolo. Nell‟affiancamento dovrà rispettare i ritmi imposti dal flusso lavorativo dell‟utente finale, ad esempio il tempo visita, ed avere un atteggiamento corretto e discreto qualora si trovasse in presenza di pazienti. Il tutor infine deve saper gestire le eventuali osservazioni in merito all‟applicativo degli utenti finali.
0.11.7 dimensionamento del team
Si richiede di indicare la presenza minima giornaliera compilando la seguente tabella in termini di FTE allocati in modo permanente per la copertura di tutta la fascia oraria del presidio
Tramite la pianificazione strategica e la relative preventivazione attività verrà commisurato il fabbisogno necessario e tramite un basket di commessa verrà autorizzato il consumo e attivata la commessa.
Avviamento | Estensione | Gestione | ||||||
Figura
Fteco Fte Fte Fteco Fte Fte Fteco Fte Fte mples x/x x/x xxxxx x/x x/x xxxxx x/x x/x xxxx xxxx xxxxxx xxxx ente fornit sivo ente fornit
ore ore ore
Fase
Client Manager Program Manager Project Manager Team Leader Tecniciprofessionali DB administrator Supporto& Tutor System architect
Totale
Si precisa che tale descrizione di effort non è finalizzata per attivare rendicontazioni amministrative e di pagamento ma solo al fine di definire la task force messa a disposizione (contingenti minimi) per il raggiungimento degli obiettivi di traguardare alla soluzione di convergenza.
[Digitare il testo]
0.11.8 Aggiornamento Professionale e Corsi di Formazione
Il Fornitore dovrà eseguire le indicazioni riportate nella propria offerta per quanto riguarda le modalità previste per lo sviluppo e l‟aggiornamento degli skill del personale impiegato nell‟erogazione dei servizi; tale aggiornamento dovrà essere documentato con cadenza semestrale all‟Ente.
Il documento depositato presso i referenti dell‟ente dopo essere creato all‟avviamento del servizio da parte del fornitore dovrà essere mantenuto costantemente al fine di mantenersi coerente con le modalità di gestione di tutte le componenti del servizio. Dovrà inoltre tenere copia del codice dell‟impianto CCE. Inoltre il fornitore con cadenza periodica bimestrale effettuare incontri formativi al personale dell‟ente referente del servizio per un aggiornamento completo del knowhow proprio contenuto del CCE sia in termini gestionali che di tecniche professionali in tutte le aree di pertinenza del servizio erogato.
0.11.9 Comitato di Controllo (CC)
Il Comitato di Controllo è un organismo paritetico tra Ente e Fornitore preposto al controllo dei livelli di servizio e alla gestione del contratto nel tempo.
Il comitato si riunisce a scadenze periodiche per tutta la durata del contratto.
In particolare, al CC sono attribuite le seguenti funzioni:
• analisi delle richieste di modifica dei processi di erogazione dei servizi e dell‟organizzazione, in termini quantitativi e qualitativi;
• definizione, revisione e controllo della qualità dei servizi erogati e delle tecnologie fornite;
• valutazione delle azioni da intraprendere per risolvere eventuali problemi operativi;
• risoluzione di conflitti tra le parti.
Deve essere data indicazione puntuale della composizione della CC come segue:
Fornitore | Ente | ||
Ruolo | Nome | Ruolo | Nome |
Program Manager | Responsabile IT o delegato | ||
Program Manager | Responsabile IT o delegato | ||
CoordinatoreEvoluzioni | BOARD community | ||
Nel documento di progetto del fornitore dovrà descrivere in modo dettagliato le figure e skill messe a disposizione ad integrazione di quello citato nel seguito a titolo esemplificativo.
[Digitare il testo]
[Digitare il testo]
1 SERVIZI AVVIAMENTO ED ESTENSIONE
1.1 Ruolo e responsabilità del servizio di avviamento ed estensione
Il Servizio di avviamento ed estensione (o struttura di avviamento) dovrà richiamare le funzioni di gestione del cambiamento ed essere in tal senso il responsabile dell‟innovazione tecnologica della soluzione fino alla completa realizzazione dell‟introduzione dello strumento informatico in modo pervasivo e completo in tutte le realtà dell‟ente.
Il team coinvolto è governato da un coordinamento strategico erogato dal fornitore stesso che interagisce con i referenti di progetto dell‟ente.
In questa fase i servizi di gestione devono essere comunque attivi, ma la componente strategica per il raggiungimento dell‟obiettivo è in questa fase definita dal team specifico.
I servizi richiesti a supporto degli utilizzatori per tutta la durata dell‟avviamento del sistema sono:
• Il servizio di formazione preventiva agli utilizzatori del sistema, da erogarsi in aula presso un‟apposita struttura locale che sarà resa disponibile dall‟A.O. BMM di Reggio Calabria;
• il servizio di affiancamento agli utilizzatori del sistema, da erogarsi presso le unità operative dislocate nelle diverse strutture afferenti l‟A.O. BMM di Reggio Calabria per un periodo non inferiore ai 15 giorni di calendario successivi allo start up di ogni reparto/unità operativa
• il servizio di profilazione progressiva degli utilizzatori ai fini del riconoscimento, autenticazione e autorizzazione degli operatori, per il corretto utilizzo del sistema in conformità alle normative del garante per la protezione dei dati personali;
• il servizio di configurazione delle prestazioni e consulenze richiedibili per i pazienti interni alle diverse strutture ospedaliere preposte a tali compiti;
• il servizio di coordinamento di tutte le attività ai fini della puntuale attuazione del piano di avviamento.
• il servizio continuativo di adeguamento del codice sorgente unificato, ai fini della personalizzazioni o correzione dei possibili malfunzionamenti emergenti durante la fase di avviamento;
• il servizio di verifica e adeguamento, parallelo all‟avviamento di ogni singolo reparto, della modulistica clinica complementare alle informazioni già gestite dalla Cartella Clinica Elettronica CCE;
• il servizio di configurazione delle relazioni cliniche ambulatoriali (referti strutturati) e delle lettere di dimissione ospedaliera per reparto/specialità;
• il servizio di configurazione delle workstation e/o dei dispositivi mobili per l‟accesso al sistema;
• il servizio di configurazione delle sezioni previste dai documenti di inquadramento clinico e ambulatoriale per reparto/specialità;
• il servizio di configurazione e attivazione delle postazioni server di backup per ogni reparto dell‟Ente;
Sarà valutata, quale condizione migliorativa proposta da fornitore senza costi aggiuntivi:
- l‟installazione/avviamento di un sistema di supporto alla terapia farmacologica degenti da inserire nel catalogo riuso unitamente alla soluzione CCE, caratterizzato dalla completa integrazione con il sistema Cartella Clinica Elettronica CCE oggetto della gestione del presente appalto
- adeguamento del modulo prescrittivo per la sua integrazione diretta al MEF in assenza della componente dei metodi di middleware di piattaforma della regione lombardia (punto di partenza della soluzione attuale)
1.2 Competenze richieste
Il Servizio di Avviamento ed Estensione dovrà pertanto avere competenze relative all‟introduzione del cambiamento in processi lavorativi, in termini di funzionalità di gestione digitale delle attività cliniche assistenziali, modalità di interazione con gli utenti, coordinamento e organizzazione strategica delle attività tecniche e di comunicazione ecc.
Caratteristiche distintive:
- Attenzione ai requisiti utente e forte conoscenza dei processi ospedalieri;
- Conoscenza delle tecnologie informatiche e delle modalità di interazione web allo stato dell‟arte;
- Conoscenza del contesto normativo, organizzativo e relazionale in cui il sistema si va ad inserire.
- Conoscenza dei sistema informativi sanitari e loro modalità di integrazione e interoperabilità
[Digitare il testo]
1.3 Descrizione delle attività richieste
Nello specifico si devono prevedere gli opportuni deliverable per le seguenti attività:
• Servizi iniziali di Formazione in loco (in aula comprensivi di documentazione ed in affiancamento nei reparti/ambulatori) agli operatori clinici, sanitari ed amministrativi a supporto dell‟utilizzo della piattaforma CCE (comprensiva dei sottosistemi di Farmaco terapia e Ricettario Elettronico NRE), organizzati presso la sede dell‟Ente appaltante e finalizzati alla completa diffusione e operatività del sistema nell‟ambito dei processi clinici, assistenziali e ambulatoriali;
• Servizi iniziali di consulenza specialistica finalizzati all‟armonizzazione dei processi operativi ospedalieri per conseguire l‟obiettivo di dematerializzazione della documentazione clinica dei pazienti (ambulatoriali ed in regime di ricovero) che rappresenta il target dell‟iniziativa;
• Servizi iniziali di classificazione e definizione delle codifiche farmaci interne (principio attivo/farmaco commerciale), predisposizione del prontuario farmaci di reparto e configurazione delle relative entità informatiche, supporto alla Farmacia aziendale e alla Direzione Sanitaria per la definizione dei modelli di acquisto e rendicontazione
• Servizi iniziali di integrazione funzionale della CCE con i sistemi “verticali” in uso presso l‟Ente appaltante da realizzarsi, sulla base degli standard già implementati nel Portale stesso (Web Services, messaggistica HL7, integrazioni di contesto, ecc.), mediante interventi sul codice sorgente già nelle disponibilità dell‟Ente;
• Servizi iniziali di configurazione e personalizzazione delle componenti software specifiche, presenti nel CCE, a supporto delle specialità di reparto e ambulatoriali (inquadramenti, referti strutturati, fogli di trasferimento, lettere di dimissione, ecc.) ai fini del corretto popolamento del repository dei Dossier clinico/ambulatoriali e dei percorsi di cura;
• Servizi di configurazione e classificazione utenti ai fini del processo di autenticazione e autorizzazione all‟uso del Portale CCE Niguarda nonché dei diversi sistemi clinici integrati dallo stesso;
• Servizi di configurazione e classificazione delle workstation finalizzate all‟uso del Portale Clinico CCE;
• Servizi di popolamento iniziale delle tabelle “base” indispensabili al funzionamento del sistema
• Servizi di coordinamento della predisposizione e installazione degli apparati e periferiche di uso esclusivo della CCE (badge e lettori RfId, lettori bar code, postazioni mobili e di backup)
1.3.1 Contesto aziendale
L‟organizzazione dell‟Ente appaltante è caratterizzata dalla presenza di 2 presidi, entrambi localizzati nella città:
• struttura “Riuniti”, situata in Via Xxxxxxxx Xxxxxxxxx con circa 500 posti letto
• struttura Xxxxxxx, situata in Viale Europa, con 60 posti letto per degenza ordinaria e 8 per DayHosp
Nell‟ambito di tali strutture sono erogate anche le prestazioni ambulatoriali e diagnostiche per tutte le specialità cliniche presenti presso l‟A.O.
Il personale dipendente, valutato ad oggi, risulta pari a circa 1.300 operatori, di cui circa 1.100 direttamente coinvolti nei processi di assistenza e cura.
Complessivamente, a livello indicativo, la struttura sanitaria è organizzata come riportato nella tabella seguente.
Nella tabella viene riportato sempre a livello indicativo una preliminare indicazione per ogni struttura se la tipologia del format di CCE puo‟ essere considerato nel set standard, o specifico.
Nel caso del format specifico il progetto dovrà illustrare la strategia di personalizzazione e standardizzazione della documentazione corrente oltre alla personalizzazione dei format di refertazioni o di processo. Particolare attenzione dovrà essere inoltre data ai sistemi di refertazione presenti, come quelli dell‟area cardiologica, al fine di dismetterle e subentrare col nuovo strumento mantenendo la continuità operativa per gli utilizzatori coinvolti.
La strategia di avviamento ed estensione deve tener conto dei moduli funzionali trasversali che necessariamente dovranno avere la loro introduzione e diffusione su tutto l‟ente con tempistica pressochè identica o molto ravvicinata, ad esempio: richieste e consultazione delle richieste/referti servizi dipartimentali, richieste/referti consulenza….
Anche la suddivisione dei gruppi omogenei di avviamento è puramente indicativa e da rivalutare a livello di progetto e ovviamente da sottoporre in post aggiudicazione dal gruppo di lavoro del progetto multidisciplinare istituito a livello aziendale.
Dati | |||||||||
GRUPPO | cod_cdr | cdr | Cod_cdc | Descrizione CDC | TIPO | FORMAT_CCE | Somma di Day Hospital | Somma di DaySurgery | Somma di Degenza ordinaria |
1 | 1030703 | UOC CHIRURGIA VASCOLARE | 103070301 | CHIRURGIA VASCOLARE - DEGENZA ORDINARIA | DEG | STANDARD | 0 | 0 | 19 |
103070302 | CHIRURGIA VASCOLARE - DAY SURGERY | DS | STANDARD | 0 | 1 | 0 | |||
103070303 | CHIRURGIA VASCOLARE - AMBULATORI | AMB | STANDARD | 0 | 0 | 0 | |||
1030704 | UOC CHIRURGIA TORACICA | 103070401 | CHIRURGIA XXXXXXXX - XXXXXXX XXXXXXXXX | XXX | XXXXXXXX | 0 | 0 | 14 | |
103070402 | CHIRURGIA TORACICA - DAY SURGERY | DS | STANDARD | 0 | 1 | 0 | |||
103070403 | CHIRURGIA TORACICA - AMBULATORI | AMB | STANDARD | 0 | 0 | 0 | |||
1030803 | UOC MEDICINA E CHIRURGIA DI ACCETTAZIONE E D'URGENZA (MCAE) | 103080301 | MEDICINA D'URGENZA - DEGENZA ORDINARIA | DEG | STANDARD | 0 | 0 | 20 | |
1 Totale | 0 | 2 | 53 | ||||||
2 | 1030301 | UOC CHIRURGIA GENERALE E D'URGENZA | 103030101 | CHIRURGIA GENERALE E D'URGENZA - DEGENZA ORDINARIA | DEG | STANDARD | 0 | 0 | 28 |
103030102 | CHIRURGIA GENERALE E D'URGENZA - DAY SURGERY | DS | STANDARD | 0 | 2 | 0 | |||
103030103 | CHIRURGIA GENERALE E D'URGENZA - AMBULATORI | AMB | STANDARD | 0 | 0 | 0 | |||
2 Totale | 0 | 2 | 28 | ||||||
3 | 1030401 | UOC NEUROLOGIA | 103040101 | NEUROLOGIA - DEGENZA ORDINARIA | DEG | STANDARD | 0 | 0 | 20 |
103040103 | NEUROLOGIA - AMBULATORI | AMB | STANDARD | 0 | 0 | 0 | |||
1030403 | UOC NEUROCHIRURGIA | 103040301 | NEUROCHIRURGIA - DEGENZA ORDINARIA | DEG | STANDARD | 0 | 0 | 19 | |
103040303 | NEUROCHIRURGIA - AMBULATORI | AMB | STANDARD | 0 | 0 | 0 | |||
1030404 | UOC OTORINOLARINGOIATRIA | 103040401 | XXXXXXXXXXXXXXXXXXXX - XXXXXXX XXXXXXXXX | XXX | XXXXXXXX | 0 | 0 | 6 | |
103040402 | OTORINOLARINGOIATRIA - DAY SURGERY | AMB | STANDARD | 0 | 0 | 0 | |||
1030405 | UOC OCULISTICA | 103040502 | OCULISTICA - DAY SURGERY | DS | STANDARD | 0 | 0 | 0 | |
103040503 | OCULISTICA - AMBULATORI | AMB | STANDARD | 0 | 0 | 0 | |||
1030406 | UOSD TERAPIA DEL DOLORE | 103040602 | TERAPIA DEL DOLORE - DAY HOSPITAL | DH | STANDARD | 1 | 0 | 0 | |
103040603 | TERAPIA DEL DOLORE - AMBULATORI | AMB | STANDARD | 0 | 0 | 0 | |||
3 Totale | 1 | 0 | 45 | ||||||
4 | 1030602 | UOC EMATOLOGIA | 103060201 | EMATOLOGIA - DEGENZA ORDINARIA | DEG | STANDARD | 0 | 0 | 24 |
103060202 | EMATOLOGIA - DAY HOSPITAL | DH | STANDARD | 10 | 0 | 0 | |||
103060203 | EMATOLOGIA - AMBULATORI | AMB | STANDARD | 0 | 0 | 0 | |||
1030603 | UOC ONCOLOGIA MEDICA | 103060301 | ONCOLOGIA - DEGENZA ORDINARIA | DEG | STANDARD | 0 | 0 | 17 | |
103060302 | ONCOLOGIA - DAY HOSPITAL | DH | STANDARD | 13 | 0 | 0 | |||
103060303 | ONCOLOGIA - AMBULATORI | AMB | STANDARD | 0 | 0 | 0 | |||
1030604 | UOC RADIOTERAPIA ONCOLOGICA | 103060402 | RADIOTERAPIA - DAY HOSPITAL | DH | STANDARD | 1 | 0 | 0 | |
103060403 | RADIOTERAPIA - AMBULATORI | AMB | STANDARD | 0 | 0 | 0 | |||
1030605 | UOSD MICROCITEMIE - EMOSTASI E TROMBOSI | 103060502 | MICROCITEMIE - DAY HOSPITAL | DH | STANDARD | 1 | 0 | 0 | |
103060503 | MICROCITEMIE - AMBULATORI | AMB | STANDARD | 0 | 0 | 0 | |||
4 Totale | 26 | 0 | 41 | ||||||
5 | 1030201 | UOC DERMATOLOGIA | 103020102 | DERMATOLOGIA - DAY HOSPITAL | DH | STANDARD | 1 | 0 | 0 |
103020103 | DERMATOLOGIA - AMBULATORI | AMB | STANDARD | 0 | 0 | 0 | |||
1030202 | UOC DIABETOLOGIA ED ENDOCRINOLOGIA | 103020203 | DIABETOLOGIA ED ENDOCRINOLOGIA - AMBULATORI | AMB | STANDARD | 0 | 0 | 0 | |
1030203 | UOC GASTROENTEROLOGIA | 103020301 | XXXXXXXXXXXXXXXXX - XXXXXXX XXXXXXXXX | XXX | XXXXXXXX | 0 | 0 | 0 | |
103020302 | GASTROENTEROLOGIA - DAY HOSPITAL | DH | STANDARD | 1 | 0 | 0 | |||
103020501 | MALATTIE INFETTIVE - DEGENZA ORDINARIA | DEG | STANDARD | 0 | 0 | 0 | |||
[Digitare il testo]
103020502 | MALATTIE INFETTIVE - DAY HOSPITAL | DH | STANDARD | 1 | 0 | 0 | |||
103020503 | MALATTIE INFETTIVE - AMBULATORI | AMB | STANDARD | 0 | 0 | 0 | |||
1030206 | UOC MEDICINA GENERALE | 103020603 | MEDICINA RIUNITI - DAY HOSPITAL | DH | STANDARD | 0 | 0 | 0 | |
103020604 | MEDICINA XXXXXXX - DAY HOSPITAL | DH | STANDARD | 0 | 0 | 0 | |||
1030207 | UOC NEFROLOGIA ABILITATA AL TRAPIANTO | 103020701 | NEFROLOGIA - DEGENZA ORDINARIA | DEG | STANDARD | 0 | 0 | 18 | |
103020702 | NEFROLOGIA - DAY HOSPITAL | DH | STANDARD | 1 | 0 | 0 | |||
103020703 | NEFROLOGIA - AMBULATORI | AMB | STANDARD | 0 | 0 | 0 | |||
1030208 | UOC PNEUMOLOGIA | 103020801 | XXXXXXXXXXX - XXXXXXX XXXXXXXXX | XXX | XXXXXXXX | 0 | 0 | 20 | |
103020803 | PNEUMOLOGIA - AMBULATORI | AMB | STANDARD | 0 | 0 | 0 | |||
1030210 | UOC RECUPERO E RIABILITAZIONE | 103021002 | RECUPERO E RIABILITAZIONE - DAY HOSPITAL | DEG | STANDARD | 0 | 0 | 15 | |
103021003 | RECUPERO E RIABILITAZIONE - AMBULATORI | AMB | STANDARD | 0 | 0 | 0 | |||
1030211 | UOSD REUMATOLOGIA | 103021102 | REUMATOLOGIA - DAY HOSPITAL | DH | STANDARD | 1 | 0 | 0 | |
103021103 | REUMATOLOGIA - AMBULATORI | AMB | STANDARD | 0 | 0 | 0 | |||
5 Totale | 7 | 0 | 53 | ||||||
6 | 1030206 | UOC MEDICINA GENERALE | 103020601 | MEDICINA RIUNITI - DEGENZA ORDINARIA | DEG | STANDARD | 0 | 0 | 40 |
6 Totale | 0 | 0 | 40 | ||||||
7 | 1030206 | UOC MEDICINA GENERALE | 103020602 | MEDICINA XXXXXXX - DEGENZA ORDINARIA | DEG | STANDARD | 0 | 0 | 40 |
7 Totale | 0 | 0 | 40 | ||||||
8 | 1030302 | UOC ORTOPEDIA E TRAUMATOLOGIA | 103030201 | ORTOPEDIA E TRAUMATOLOGIA - DEGENZA ORDINARIA | DEG | STANDARD | 0 | 0 | 28 |
103030202 | ORTOPEDIA E TRAUMATOLOGIA - DAY SURGERY | DS | STANDARD | 0 | 2 | 0 | |||
103030203 | ORTOPEDIA E TRAUMATOLOGIA - AMBULATORI | AMB | STANDARD | 0 | 0 | 0 | |||
103030301 | UROLOGIA - DEGENZA ORDINARIA | DEG | STANDARD | 0 | 0 | 28 | |||
103030302 | UROLOGIA- DAY SURGERY | DS | STANDARD | 0 | 2 | 0 | |||
103030303 | UROLOGIA - AMBULATORI | AMB | STANDARD | 0 | 0 | 0 | |||
8 Totale | 0 | 4 | 56 | ||||||
9 | 1030701 | UOC CARDIOLOGIA UTIC | 103070101 | CARDIOLOGIA - DEGENZA ORDINARIA | DEG | SPECIFICO CARDIOLOGIA | 0 | 0 | 22 |
103070102 | CARDIOLOGIA - DAY HOSPITAL | DH | SPECIFICO CARDIOLOGIA | 2 | 0 | 0 | |||
103070103 | CARDIOLOGIA - AMBULATORI | AMB | SPECIFICO CARDIOLOGIA | 0 | 0 | 0 | |||
1030702 | UOC CARDIOCHIRURGIA | 103070201 | CARDIOCHIRURGIA - DEGENZA ORDINARIA | DEG | SPECIFICO CARDIOLOGIA | 0 | 0 | 20 | |
103070202 | CARDIOCHIRURGIA - DAY SURGERY | DH | SPECIFICO CARDIOLOGIA | 0 | 0 | 0 | |||
103070203 | CARDIOCHIRURGIA - AMBULATORI | AMB | SPECIFICO CARDIOLOGIA | 0 | 0 | 0 | |||
9 Totale | 2 | 0 | 42 | ||||||
12 | 1030601 | UOC CENTRO TRAPIANTI MIDOLLO OSSEO | 103060101 | XXXXXX XXXXXXXXX XXXXXXX XXXXX - XXXXXXX XXXXXXXXX | XXX | XXXXXXXXX XXXXXXXXX | 0 | 0 | 8 |
103060102 | CENTRO TRAPIANTI MIDOLLO OSSEO - DAY HOSPITAL | DH | SPECIFICO TRAPIANTI | 2 | 0 | 0 | |||
103060103 | CENTRO TRAPIANTI MIDOLLO OSSEO - AMBULATORI | AMB | SPECIFICO TRAPIANTI | 0 | 0 | 0 | |||
12 Totale | 2 | 0 | 8 | ||||||
11 | 1030606 | UOSD ONCOEMATOLOGIA PEDIATRICA | 103060601 | ONCOEMATOLOGIA PEDIATRICA - DEGENZA ORDINARIA | DEG | SPECIFICO PEDIATRIA | 0 | 0 | 4 |
103060602 | ONCOEMATOLOGIA PEDIATRICA - DAY HOSPITAL | DH | SPECIFICO PEDIATRIA | 0 | 0 | 0 | |||
103060603 | ONCOEMATOLOGIA PEDIATRICA - AMBULATORI | AMB | SPECIFICO PEDIATRIA | 0 | 0 | 0 | |||
1031003 | UOC PEDIATRIA | 103100301 | PEDIATRIA - DEGENZA ORDINARIA | DEG | SPECIFICO PEDIATRIA | 0 | 0 | 19 | |
103100302 | PEDIATRIA - DAY HOSPITAL | DH | SPECIFICO PEDIATRIA | 1 | 0 | 0 | |||
103100303 | PEDIATRIA - AMBULATORI | AMB | SPECIFICO PEDIATRIA | 0 | 0 | 0 | |||
11 Totale | 1 | 0 | 23 | ||||||
13 | 1030705 | UOSD RIANIMAZIONE CARDIOCHIRURGICA | 103070501 | RIANIMAZIONE CARDIOCHIRURGICA - DEGENZA ORDINARIA | DEG | SPECIFICO INTENSIVA | 0 | 0 | 0 |
1030804 | UOC TERAPIA INTENSIVA | 103080401 | TERAPIA INTENSIVA - DEGENZA ORDINARIA | DEG | SPECIFICO INTENSIVA | 0 | 0 | 14 | |
1030805 | UOSD TERAPIA INTENSIVA POSTOPERATORIA | 103080501 | TERAPIA INTENSIVA POSTOPERATORIA - DEGENZA ORDINARIA | DEG | SPECIFICO INTENSIVA | 0 | 0 | 0 | |
1031001 | UOC NEONATOLOGIA | 103100101 | NEONATOLOGIA - DEGENZA ORDINARIA | DEG | SPECIFICO INTENSIVA | 0 | 0 | 16 | |
[Digitare il testo]
103100102 | NEONATOLOGIA - DAY HOSPITAL | DH | SPECIFICO INTENSIVA | 1 | 0 | 0 | |||
103100103 | NEONATOLOGIA - AMBULATORI | AMB | SPECIFICO INTENSIVA | 0 | 0 | 0 | |||
13 Totale | 1 | 0 | 30 | ||||||
10 | 1031002 | UOC OSTETRICIA E GINECOLOGIA | 1031002 | UOC OSTETRICIA E GINECOLOGIA | DS | SPECIFICO OSTETRICIA | 0 | 4 | 0 |
103100201 | OSTETRICIA E GINECOLOGIA - DEGENZA ORDINARIA | DEG | SPECIFICO OSTETRICIA | 0 | 0 | 36 | |||
103100202 | OSTETRICIA E GINECOLOGIA - DAY HOSPITAL | DH | SPECIFICO OSTETRICIA | 0 | 0 | 0 | |||
103100203 | OSTETRICIA E GINECOLOGIA - AMBULATORI | AMB | SPECIFICO OSTETRICIA | 0 | 0 | 0 | |||
10 Totale | 0 | 4 | 36 | ||||||
Totale complessivo | 40 | 12 | 495 | ||||||
[Digitare il testo]
[Digitare il testo]
Si illustra in seguito il contesto aziendale in merito ai sistemi informativi sanitari esistenti e le regole di interoperabilità previste verso il sistema CCE.
I sistemi di accoglienza e quelli di laboratorio analisi sono nel contesto della suite AREA di Engineering, quali:
- CUP
- ADT
- TRIAGE
- PS
- LIS
- BAC
Nella figura alla pagina seguente viene rappresentatolo scenariocomplessivo del sistema informativodell‟ente,mentre In giallo learee dovute alle modalitàdi interoperabilitàche coinvolgono l’introduzione della CCE.
[Digitare il testo]
[Digitare il testo]
Si sintetizzano a seguire i principi guida riguardo le modalità di interoperabilità tra i diversi impianti.
impianto | descrizione |
CUP | Il sistemaha lagestione esclusivadellaprenotazioneeaccettazionedel paziente ambulatoriale |
1) | il sistemacuptramite messaggistica HL7 comunica gli eventi AMB e successivi cambi di statoai sistemi dipartimentali RIS, CCE. Tale modalità è anche disponibile a tuttii sistemi dipartimentali dell‟ente esistenti o di nuova introduzione. I sistemi coinvolti dovranno gestiregli accodamenti dei messaggi in relazione al recepimento della risposta per corretta ricevimentodai sistemi terzi |
2) | La CCE ha funzionalità che tramite webservices debitamente esposti dal sistemaCUPconsente: a. la comunicazionedello stato di occupazione agende b. lo spostamento di appuntamenti c.l‟inserimento di appuntamenti |
ADT | il sistemaADT hail ruolo esclusivo di accoglienzadel pazientein regimediricovero(prericovero, ordinario, dayhospital,mac) |
3) | il sistemaADT tramite messaggistica HL7 trasmette l‟evento diammissionedel ricoveroesuccessivi cambi di stato al sistema dipartimentale. |
4) | Il sistema ADT gestisce come refertazione esclusivamente le seguenti componenti: SDO, Verbale operatorio, CEDAP |
Nota: i nosologici ancora aperti all‟attivazione della CCE verranno chiusi direttamente tramite l‟ADT e non verranno gestite lettere dimissione. La CCE gestirà solo episodi aperti dall‟avvio della stessa. Lo storico delle lettere dimissioni e sdo e verbali e cedap non saranno consultabili da CCE e rimarranno come archivi locali della soluzione AREAS.
5) | Creazione ed attivazionedal sistemaADT di un servizio applicativo web chepermettaallaCCE ad invocaretramitechiamatadi contesto con prefissatespecifichesiadi parametri (autenticazione, identificazionepaziente, evento clinico in modalitàembedded) che di ergonomiaapplicativala funzionespecificadimovimentazione degenti edimissionegiàin essere |
6) | Il sistema CCE tramite integrazione di contesto invocherà il sistemaADT con prefissatespecifichesiadi parametri (autenticazione, identificazione paziente, evento clinico in modalitàembedded)per le seguenti funzionalità: - accettazione e movimento pazienti - compilazione della SDO - gestione del verbale operatorio - gestione del CEDAP |
7) | Attivazionedi un servizio hl7 per la comunicazione dei documenti, al repository CCE, seguenti: - SDO - Verbale operatorio - Verbale pronto soccorso |
TRIAGE | il sistema TRIAGE ha il ruolo diaccoglienza del paziente in regime di emergenza |
8) | Tramite il sistema ADT l‟eventodi ammissione al pronto soccorso esuccessivi cambi di statoviene trasmesso al sistemadipartimentale CCE, in standard hl7 |
PS | Il sistemaè preposto allagestione esclusivadel pazientenelpercorso di curain emergenza |
9) | comunicazionedelle richiesteesuccessivi cambidi stato tramite messaggisticahl7 opportunatamenteindirizzata ai sistemi dipartimentali RIS, CCE ed eventualmentea futuri nuovi sistemi dipartimentali, gestendogli accodamenti dei messaggi in relazione al recepimento della rispostaper corretta ricevimento dai sistemi terzi. |
LIS | Il sistemadipartimentaleLISèil sistema esclusivo perlagestionedel servizio di medicinadi laboratorio |
10) | Attivazionedi un servizio hl7 per la comunicazione dei documenti, al repository CCE relativi ai referti di medicina di laboratorio |
11) | attivazionedi un servizioapplicativo web chepermettaasistemi dipartimentali terzi quali aCCE ad invocaretramite chiamatadi contesto con prefissatespecifichesiadi parametri (autenticazione, identificazionepaziente, evento clinico in modalitàembedded)la funzionespecificadi order entrydelle richiestedi laboratorio. |
[Digitare il testo]
1.3.2 Servizio di formazione preventiva agli utilizzatori del sistema
Il servizio dovrà essere erogato da Tutor esperti con approfondite competenze sulle modalità d‟uso e di funzionamento del sistema da avviare. Il servizio dovrà essere pianificato in base ad un calendario settimanale concordato preventivamente con i referenti clinici ed infermieristici aziendali, nominati all‟uopo dalla Direzione Strategica dell‟Ente appaltante.
Dovranno essere pianificate due sessioni di formazione giornaliere così articolate:
• Una sessione al mattino, dalle ore 11,00 alle ore 13,00 (xxx), dedicata al personale infermieristico e assistenziale;
• Una sessione pomeridiana, dalle 14,30 alle 17,30 (xxx) dedicata al personale medico/clinico
Le sessioni di formazione dovranno essere eseguite continuativamente, nei giorni feriali, fino alla completa formazione del personale sanitario dell‟Ente e dovranno prevedere la partecipazione massima di 12 operatori cadauna. La formazione decorrerà dal primo lunedì successivo all‟approvazione, da parte della direzione dell‟Ente appaltante, del piano di erogazione, che la ditta appaltatrice sarà impegnata a consegnare entro 15 giorni di calendario dalla sottoscrizione del contratto di servizio, pena decadenza dello stesso.
Le ditte partecipanti dovranno formulare un diverso programma di formazione per ogni categoria di operatori, dettagliando gli argomenti da trattare e la durata di ogni argomento. La formazione dovrà comprendere l‟esecuzione, da parte degli operatori, di prove pratiche da effettuarsi con dati significativi seppur fittizi.
L‟Ente appaltante metterà a disposizione i locali da destinare alla formazione con le opportune Postazioni di Lavoro e dotazioni individuali, la cui configurazione quotidiana sarà responsabilità della ditta aggiudicataria.
L‟Ente appaltante, ai fini dell‟aggiudicazione dell‟appalto, valuterà l‟organizzazione del percorso formativo proposto, la fattibilità organizzativa dello stesso ed i contenuti del programma formulati dalle ditte partecipanti in sede di offerta tecnica.
1.3.3 Servizio di affiancamento agli operatori in fase di avviamento delle Unità Operative
Al completamento di ogni “sezione” di formazione, comprendente le diverse sessioni necessarie alla partecipazione di tutti gli operatori di ogni reparto o Unità Operativa, si provvederà all‟avviamento in produzione del sistema per il reparto stesso.
La ditta aggiudicataria dovrà fornire un servizio locale di affiancamento, agli operatori sanitari di ogni singola Unità Operativa in avviamento, per supportare la fruizione iniziale delle funzionalità disponibili. Tale servizio dovrà essere erogato da personale specialistico con competenze specifiche di prodotto e sulle modalità d‟uso della Cartella Clinica Elettronica CCE, sviluppata dall‟ASST Niguarda di Milano ed acquisita in riuso dall‟Ente appaltante.
Il servizio sarà valutato in base alle competenze ed alla numerosità del personale specialistico coinvolto nonché alla dimensione del periodo di affiancamento, proposto dalla Ditte partecipanti per ciascuna Unità Operativa da supportare nell‟avviamento del sistema.
1.3.4 Servizio di profilazione progressiva degli operatori
Il sistema acquisito in riuso dall‟Ente appaltante è dotato di un complesso insieme di funzionalità e strutture dati finalizzate a fornire le necessarie garanzie di autenticazione e autorizzazione per gli operatori sanitari che ne hanno accesso. Tali componenti, che assicurano piena conformità alle normative nazionali in tema di protezione dei dati personali sensibili, richiedono un insieme di attività preliminari finalizzate alla configurazione degli utenti e delle workstation dagli stessi utilizzate.
Il servizio richiesto è caratterizzato dall‟insieme di operazioni, da effettuarsi progressivamente in coerenza con il piano di formazione, finalizzate alla classificazione degli utenti, dei ruoli degli stessi e dei diversi livelli di autorizzazione operativa. Il sistema richiede altresì la classificazione e configurazione delle Postazioni di Lavoro personali che saranno autorizzate all‟accesso.
L‟esecuzione di tali attività costituisce un presupposto fondamentale per l‟attuazione del piano di formazione e del successivo avviamento in produzione delle singole Unità Operative. Il servizio richiede altresì l‟analisi e la mappatura delle informazioni presenti nel sistema aziendale di controllo del dominio (Microsoft Active Directory), ai fini della verifica di presenza e dell‟eventuale popolamento degli ulteriori dati, essenziali al funzionamento della Cartella Clinica Elettronica CCE.
Il servizio sarà valutato in relazione al possesso, da parte delle Ditte partecipanti, di utilities e procedure finalizzate all‟iniziale popolamento di massa dei profili interni alla Cartella Clinica Elettronica CCE ed all‟analisi delle anomalie eventualmente emergenti da tale popolamento.
Costituirà ulteriore elemento di valutazione la competenza acquisita, dalle Ditte partecipanti, nell‟esecuzione di analoghe attività per conto di altri Enti già aderenti all‟iniziativa di riuso del sistema.
La successiva manutenzione ed aggiornamento continuativo dei profili utente saranno demandati al servizio di Help Desk e supporto utenti più avanti definito.
[Digitare il testo]
2 SEZIONE GESTIONE
2.1 Ruolo e responsabilità
Il Servizio di Gestione (o struttura di produzione) dovrà richiamare le funzioni di Produzione della soluzione ed essere in tal senso il responsabile delle attività di Coordinamento, Gestione ordinaria e straordinaria della soluzione CCE.
I servizi continuativi richiesti da erogarsi nel periodo di validità del contratto a canone costante, sono:
• il servizio di monitoraggio e conduzione dell‟intero impianto, funzionale e sistemistico (escluso hardware e sistemi di virtualizzazione), ai fini della continuità di funzionamento del sistema;
• il servizio di supporto utenti e pronto intervento remoto (help desk di 2° livello) per la ricezione di segnalazioni relative ad eventuali malfunzionamenti;
• il servizio di adeguamento per la profilazione utenti del sistema ai fini autorizzativi;
• il servizio di manutenzione correttiva (bug fixing) e di evoluzione del codice sorgente, coordinato dall‟ASST Niguarda, a garanzia dei progressivi aggiornamenti e del rilascio di nuove versioni del sistema.
La ditta aggiudicataria dovrà disporre:
• di un Centro Unico di Contatto (SPOC) con competenze sistemistiche e funzionali, dimostrabili e continuamente aggiornate sulle evoluzioni funzionali del sistema Cartella Clinica Elettronica CCE, finalizzato a fornire con continuità (24h x 365) il supporto funzionale e di processo agli utilizzatori del sistema stesso;
• di una struttura specialistica finalizzata alla manutenzione correttiva e continuativa del sistema, operante di concerto con il “Board Strategico degli aderenti” organizzata dall‟ASST Niguarda di Milano;
• di una struttura sistemistica centralizzata, finalizzata al monitoraggio ed alla gestione continuativa del sistema, con funzioni di pronto intervento (24h x 365 gg) per malfunzionamenti, il cui servizio dovrà essere erogato in base ai Livelli di Servizio (SLA) già definiti dall‟ASST Niguarda di Milano in occasione del corrispondente procedimento ad evidenza pubblica;
• di una infrastruttura, opportunamente configurata e dimensionata, destinata ad ospitare l‟impianto di sviluppo e test per l‟adeguamento e la manutenzione correttiva del codice sorgente;
• di un‟infrastruttura di connettività adeguata alle esigenze di collegamento con l‟A.O. BMM di Reggio Calabria e l‟ASST Niguarda di Milano per consentire l‟erogazione dei servizi remoti sopra definiti;
• di una piattaforma open source di monitoraggio degli impianti relativi alla Cartella Clinica Elettronica CCE dell‟A.O BMM di Reggio Calabria che, al termine del periodo contrattuale, la ditta aggiudicataria dovrà mettere a disposizione dell‟Ente appaltante nell‟ambito degli impegni di exit contrattuali più avanti definiti.
2.2 Competenze richieste
Il Servizio di Gestione dovrà avere competenze relative all‟ingegnerizzazione e diffusione della soluzione, per l‟utilizzo in produzione all‟interno delle strutture cliniche con caratteristiche di performance ed affidabilità adeguate.
Caratteristiche distintive:
• Conoscenza delle architetture e delle modalità di esercizio di applicazioni business critical;
• Software factory allo stato dell‟arte in termini di processo di sviluppo software, comprensivo di testing, documentazione, produzione di eLearning, …;
• Scalabilità del Numero del personale di supporto e diffusione nell‟utilizzo (per attivazione in parallelo di più strutture cliniche);
• Help desk di supporto all‟esercizio ed alla gestione.
In questo paragrafo vengono brevemente illustrati i profili professionali e le competenze minime delle risorse ritenute indispensabili per l‟erogazione dei servizi.
Sarà responsabilità del Fornitore adeguare in termini qualitativi e quantitativi, per tutta la durata del contratto, le risorse utilizzate in modo tale da garantire gli SLA di capitolato.
[Digitare il testo]
L‟Ente si riserva di valutare e segnalare incompatibilità del personale (elencato in seguito nelle figure principali) predisposto dal Fornitore per l‟erogazione del servizio e richiederne la sostituzione.
2.3 Descrizione delle attività richieste
2.3.1 Sviluppo applicativo manutentivo e correttivo
Il servizio dovrà occuparsi dello sviluppo di manutenzione e correzione del Software seguendo una metodologia di bug-fixing.
• Bug (dovuti a segnalazioni di HD che a segnalazioni/rilevazioni interne all‟ICT Niguarda)
• Adeguamenti normativi
E‟ richiesta la descrizione della procedura per la gestione di risoluzione bug, specificando ruoli e responsabilità Niguarda-Fornitore.
2.3.2 Help Desk e Gestione Utenti
Il fornitore metterà a disposizione un servizio call center h24 x 365 g/anno che definisce un SPC agli utenti.
Il servizio dovrà fornire un unico punto di contatto (SPOC – Single Point Of Contact) per ogni tipo di richiesta di supporto da parte dell‟Help Desk di primo livello o direttamente degli utenti dell‟Ente, con conseguente diagnosi on-line e, quando possibile, ripristino immediato della corretta fruizione del prodotto/servizio.
Eventuali chiamate all‟Help Desk considerate non di propria competenza devranno essere comunque registrate e portate all‟attenzione del responsabile dell‟Ente.
Fatto salvo quanto messo a disposizione dall‟Ente, il Fornitore dovrà dotarsi degli opportuni strumenti di gestione (hardware e software) per garantire la perfetta conduzione dei servizi richiesti in fornitura, nel rispetto dei Service Level Agreement (SLA) di capitolato.
Oggetto del presente paragrafo dovrà pertanto organizzare un servizio di supporto specialistico con contatto diretto con l‟utente finale. Oltre alle attività di analisi “guasti” il servizio dovrà erogare i servizi di profilazione utente sull‟applicativo e più in generale su tutte le attività di gestione utente che si scaturiscono nella vita del prodotto software CCE.
Sarà responsabilità di quest‟ultimo servizio la risoluzione e la chiusura della chiamata tramite il sistema ticketing del gestore del call center. Il fornitore contraente del presente appalto dovrà adeguarsi alle soluzioni tecniche organizzative sulle modalità di trasferimento e assegnazione della chiamata.
2.3.3 assistenza 7 X 24
Il servizio di assistenza 7 x 24 si occupa di gestire le emergenze al di fuori delle fascie orarie di servizio dell‟Help Desk, e deve assicurare la continuità di servizio e eni casi di criticità avviare tutte le azioni per il ripristino della nuova funzionalità.
La gestione dell‟assistenza deve essere progettata in modalità proattiva, cioè attraverso un constante monitoraggio del buon funzionamento di tutte le parti del sistema in modo da intervenire immediatamente al verificarsi di qualche anomalia anche in assenza di una richiesta esplicita di intervento da parte di un utente.
La fornitura è orientata a un servizio di erogazione applicativo in termini di continuità di servizio.
Le modalità organizzative del servizio da parte del fornitore dovrà pertanto permettere la riduzione dei rischi di interruzione e una unità di crisi per la gestione proattiva del guasto.
Tale organizzazione deve essere presente ed erogato h24 per 265 g/anno.
Particolare attenzione da parte dell‟ente sarà data dalla metodologia tecnica/organizzativa (illustrata nel progetto presentato dal fonritore) nel monitoraggio continuativo e proattivo al “guasto” nell‟ottica della continuità di servizio al livello teorico “100%”.
2.3.4 Responsabilità e Supervisione degli standard di configurazione apparati
Il fornitore sarà responsabile della definizione e sua relativa manutenzione degli standard per la configurazione degli ambienti sistemistici degli apparati centrali hardware e software sui quali viene erogato il servizio applicativo CCE.
L‟attività dovrà essere continua al fine di ottimizzare al meglio gli aspetti prestazionali e di continuità di servizio. Nell‟ambito della stesura del progetto di gara il fornitore dovrà descrivere una prima idea progettuale a tal proposito.
2.3.5 Coordinamento organizzativo e tecnico
Il servizio dovrà pianificare, monitorare e coordinare tutte le attività.
La programmazione delle attività dovrà essere, costantemente aggiornata e pubblicata sul PMIS (Project Management Information System) dell‟ente.
Il fornitore, oltre al precedente, potrà impiegare strumenti propri, che già impiega, di programmazione e di timetable per la gestione dettagliata delle commesse. Il fornitore dovrà descrivere dettagliatamente gli strumenti software impiegati sia da un punto di vista applicativo che organizzativo.
[Digitare il testo]
Ad ogni staff meeting si dovranno riportare gli stati avanzamento lavori illustrando i progressi fatti e le criticità in atto. (vedere paragrafo Riunioni di AvanzamentoLavori).
Il coordinamento deve prevedere la gestione di:
• nuove funzionalità da realizzare
• supervisione alla progettazione e definizione dei requisiti
• supervisione alla definizione dei mockup
• pianificazione delle risorse
• supervisione alle fasi di sviluppo
• supervisione alle fasi di test
• supervisione alle fasi di messa in produzione
• definizione e coordinamento dei piani di avviamento e formazione
• piani preventivi e consultivi commesse
• supervisione e verifica livelli qualitativi del servizio
• supervisione e verifica non conformità e attivazione azioni correttive
[Digitare il testo]
3 SERVIZIEVOLUTIVI
Il Servizio di evoluzione (o struttura di evoluzioneo) dovrà intervenire ogni qualvolta l‟ente evidenzia la necessità di introdurre nuove funzionalità evolutive o di recepirne da quelle già messe a disposizione della community del riuso.
In linea di massima il principio che guida l‟evoluzione è di attuare percorsi di nuovi sviluppi che abbiamo elementi innovativi , questi possono essere ad uso esclusivo dell‟ente BMM o anche recepire esigenze al di fuori del “sito” BMM.
Per tali attività il fornitore dovrà produrre una valutazione tecnica della soluzione corredata da una stima degli effort necessari alla sua messa in produzione. Tali effort dovranno essere autorizzato dal basket FTE.
Gli scenari a titolo d‟esempio potranno essere i seguenti:
• adeguamento del codice sorgente ai regolamenti regionali ed alle progressive esigenze dell‟Ente Appaltante (basket di prestazioni/anno)
• presidio tecnico/applicativo a supporto dei progressivi mutamenti organizzativi dell‟Ente attesi per i prossimi esercizi (basket di prestazioni/anno)
• supporto locale alle eventuali esigenze quotidiane emergenti dal normale utilizzo del sistema
• progettazione, il coordinamento e l‟implementazione delle integrazioni progressive con i sistemi verticali in uso presso l‟Ente appaltante;
• la progettazione e implementazione di evoluzioni specifiche del sistema eventualmente emergenti successivamente all‟avviamento nel corso di validità del contratto
• supporto specialistico alla messa in funzione delle future “Major Releases” del Portale Clinico CCE: Update di sistema e di impianto, Aggiornamenti della Base Dati e delle utilities di gestione, Configuration Management e complementi formativi (e- learning).
3.1 Competenze richieste
Il Servizio Evolutivo dovrà pertanto avere competenze relative all‟innovazione della soluzione, in termini di funzionalità supportate, modalità di interazione con gli utenti, ergonomia, tecnologie hardware e software utilizzate, ecc.
Caratteristiche distintive:
- Attenzione ai requisiti utente e forte conoscenza dei processi ospedalieri;
- Conoscenza delle tecnologie informatiche e delle modalità di interazione web allo stato dell‟arte;
- Flessibilità e velocità nella creazione di prototipi da valutare e validare con i referenti clinici;
- Conoscenza del contesto normativo, organizzativo e relazionale in cui il sistema si va ad inserire.
3.2 Descrizione delle attività richieste
3.2.1 Servizio di analisi,progettazione e protipazione evolutive
Per migliorare il riuso e piu in generale il riempiego delle soluzioni sviluppate, la tecnica di sviluppo puo‟ pur non essendo obbligatorio recepire impostazioni di tecniche di sviluppo e di framework introdotte e perseguite dalla community del riuso.
Ad ogni modo il team deve preservare una base minima su cui si deve fondare l‟Infrastruttura Applicativa della CCE dovrà essere costituita da un Framework che copre le tipiche problematiche applicative (dalla Presentation all‟accesso ai dati) e guida la realizzazione dei vari filoni applicativi (sia di Reparto che Ambulatoriali) orientato ai servizi.
Inoltre lo sviluppo prototipale deve avere una precisa metodologia di sviluppo e prevedere oltre allo sviuppo l‟appropriata documentazione, criteri di performance e di test.
Nello specifico si devono prevedere gli opportuni deliverable per le seguenti attività:
• Analisi
• Up-front design
• Sviluppo
• Testing
• Documentazione
3.2.2 Interiazioni con il BOARD della Community di riuso CCE
[Digitare il testo]
Il Servizio di Evoluzione dovrà interagire con il BOARD di Coordinamento organizzativo e tecnicodella community del riuso CCE, responsabile di pianificare, monitorare e coordinare tutte le attività, andando a gestire in particolare:
• nuove funzionalità da realizzare
• supervisione alla progettazione e definizione dei requisiti
• supervisione alla definizione dei mockup
• pianificazione delle risorse
• supervisione alle fasi di sviluppo
• supervisione alle fasi di test
• supervisione alle fasi di messa in produzione
• definizione e coordinamento dei piani di avviamento e formazione
• piani preventivi e consultivi commesse
• supervisione e verifica livelli qualitativi del servizio
• supervisione e verifica non conformità e attivazione azioni correttive
La programmazione delle attività sarà costantemente aggiornata e pubblicata sul PMIS (Project Management Information System) dell‟ente.
Il fornitore, oltre al precedente, potrà impiegare strumenti propri, che già impiega, di programmazione e di timetable per la gestione dettagliata delle commesse. Il fornitore dovrà descrivere dettagliatamente gli strumenti software impiegati sia da un punto di vista applicativo che organizzativo.
Ad ogni staff meeting si dovranno riportare gli stati avanzamento lavori illustrando i progressi fatti e le criticità in atto. (vedere paragrafo Riunioni di AvanzamentoLavori).
[Digitare il testo]
4 SOLUZIONE APPLICATIVA TECNOLOGICA AS-IS
L‟Azienda Ospedaliera Bianchi Melacrino Xxxxxxx di Reggio Calabria, a seguito di apposita procedura di valutazione dell‟adeguatezza, della riusabilità e della convenienza economica effettuata secondo le linee guida AgID di riferimento, ha deciso di procedere al “riuso”, ed all‟acquisizione del codice sorgente, del software Cartella Clinica CCE (sviluppato dalla ASST Niguarda di Milano, di proprietà della stessa e presente nel catalogo nazionale AgID per il software in riuso al numero 284/2016), nonché all‟attuazione delle necessarie iniziative per la messa in produzione dello stesso.
Non essendo l‟Ente appaltante ad oggi in possesso delle necessarie infrastrutture hardware e software di base è stata valutata l‟opportunità di aderire alla logica di “riuso cooperativo” con servizi, promossa dall‟ASST Niguarda, che presuppone da parte della stessa l‟erogazione dei servizi di predisposizione iniziale, configurazione, personalizzazione e attivazione del sistema, finalizzati al collaudo dell‟intero impianto (infrastrutture, software di base e piattaforma applicativa) ed al successivo trasferimento e attivazione presso il costituendo Data Center dell‟Ente stesso.
Nell‟ambito di tali accordi l‟ASST Niguarda provvederà quindi all‟esecuzione di tutte le attività specialistiche iniziali (progettazione, predisposizione, integrazione, personalizzazione e popolamento delle basi dati) già identificate come essenziali per la messa in uso del sistema, da svolgersi in base alle caratteristiche peculiari dell‟A.O. BMM di Reggio Calabria, rilevate in occasione di apposito assessment, ed alle indispensabili competenze tecnico/funzionali sul sistema Cartella Clinica Elettronica CCE in possesso della ASST Niguarda di Milano.
Le attività ed i servizi di cui al presente appalto decorreranno quindi successivamente alla prevista data di collaudo dell‟intero sistema Cartella Clinica Elettronica CCE, concordata con l‟ASST Niguarda di Milano, entro l‟entrata in essere del presente appalto. Il sistema sarà quindi avviato e posto in uso mediante un Virtual Data Center appositamente predisposto a cura dell‟Ente appaltante entro tale termine presso un erogatore di servizi Cloud Computing accreditato.
Mediante l‟attuazione dell‟iniziativa di riuso della Cartella Clinica Elettronica CCE dell‟ASST Niguarda di Milano l‟A.O. BMM di Reggio Calabria intende perseguire i seguenti obiettivi:
1 - Implementazione di un sistema informatico a supporto dei processi ambulatoriali e di ricovero che garantisca la disponibilità e l‟integrità dei dati clinico/assistenziali ivi immessi e conservati;
2 - Disponibilità di un sistema integrato, comprendente funzioni di firma digitale, ai fini della dematerializzazione e conservazione sostitutiva della documentazione clinica dei pazienti, sia in regime di ricovero che ambulatoriale;
3 - Implementazione di misure per la sicurezza e la privacy conformi alle normative (testo unico sulla privacy Dgs 196/2003) e controllabili anche mediante tracciatura degli accessi;
4 - Adozione di specifiche finalizzate al ClinicalRisk Management (CRM) mediante applicazione della tecnica HFMEA (Healthcare Failure Mode and Effect Analysis);
5 - Alimentazione e consultazione mediante un unico sistema integrato con le Reti di patologie (REL, ROL, Diabete, ecc.) e con il Fascicolo Sanitario Elettronico regionale (FSE);
6 - Possibilità di gestione della “Presa in carico” del paziente ai fini delle emergenti necessità di continuità assistenziale e sociale sul territorio;
7 - Introduzione di un sistema software “orizzontale” completamente Open Source e in riuso, conformemente alle linee guida CNIPA, senza oneri di licenze e basato su piattaforme standard (Java, Apache, Jboss, PostgreSql, Linux, ecc.);
8 - Introduzione di una piattaforma software unificata ai fini dell‟accesso ai dati clinico/assistenziali e dell‟integrazione/comunicazione con i sistemi verticali (ADT, CUP, PS, RIS/PACS, ecc.) mediante profilazione e autorizzazione unica all‟accesso.
A garanzia del conseguimento di tali obiettivi, da parte dell‟Ente appaltante, le ditte partecipanti, nella documentazione tecnica, dovranno dichiarare esplicitamente, pena l‟esclusione dalla procedura di gara, l‟avvenuta presa visione delle caratteristiche del sistema (vedi scheda AgID 284/2016) nonché degli obiettivi prefissati dal BMM e che le informazioni raccolte sono sufficienti alla formulazione dell‟offerta, senza poter avanzare rivendicazioni o riserve successive in merito.
4.1 Caratteristiche funzionali del sistema
Attualmente la Cartella Clinica Elettronica CCE garantisce l‟acquisizione e gestione delle informazioni clinico assistenziali relative alle seguenti funzioni:
funzionalità per operatori clinici assistenziali
[Digitare il testo]
• Prenotazione, pianificazione e conferma ricoveri e pre-ricoveri
• Gestione delle informazioni anagrafiche Paziente
• Riepilogo dell‟episodio clinico
• Inquadramento clinico per specialità (generico, pediatrico, ostetrico, ginecologico) con valutazione assistenziale base
• Gestione Diario clinico assistenziale
o Programmazione e rilevazione BAI (Xxxxxxx assistenziali)
o Programmazione e rilevazione Parametri vitali
• Gestione richieste di consulenze, servizi diagnostici, consulenze e prestazioni assistenziali con verifica di avanzamento/esecuzione/refertazione
• Nuovo Ricettario Elettronico integrato MEF tramite piattaforma regionale Lombardia Informatica
• Gestione modulistica aziendale tramite form compilabili preformattata
• Gestione e Redazione Referti strutturati di conclusione episodio clinico:
o lettera dimissione clinica (con format diversi)
o lettera dimissione infermieristica strutturate
o referti ambulatoriali standard o specifici per specialità
o Gestione ed acquisizione “allegati” alla documentazione clinica anche da strumentazione
• Gestione della consultazione della documentazione clinica completa dell‟episodio o storica del paziente : tramite webservice lato impianto dipartimentali esterni al sistema CCE
• Prenotazione di prestazioni supplementari da ambulatorio, tramite integrazione contesto di modulo, se disponibile, del sistema CUP esterno al sistema CCE
• Movimentazione degenti (trasferimenti, dimissione) tramite integrazione contesto di modulo del sistema ADT esterno al sistema CCE
• Gestione, controllo e chiusura “Dossier clinico” dell‟episodio
Funzionali per utenti di servizi erogatori ospedialieri
o Gestione della schedulazione della programmazione prestazioni ambulatoriali, diagnostiche, ecc. sia per interni che esterni, funzionalità disponibile se presente webservices specifichi lato sistema CUP esterno al sistema CCE
Funzioni per utenti di amministrazione dell’impianto
o Amministrazione e gestione del sistema (Portale di Back Office CCE)
o configurazione della struttura organizzativa (CdR, CdC, Ambulatori, Medici, Infermieri, Specializzandi, Terapisti, Assistenti sociali, ecc.)
o profilazione dei singoli utenti ai fini dell‟autenticazione e autorizzazione degli stessi all‟uso del sistema, alla disponibilità delle singole funzioni e alla visibilità dei dati
o profilazione delle Postazioni di Lavoro, fisse e mobili, ai fini del controllo accessi ai dati dei pazienti
o profilazione dei ruoli operatore per accesso al sistema di auto formazione (e-learning) funzionale all‟aggiornamento ed all‟evoluzione del sistema
L‟implementazione del sistema produrrà un‟evoluzione degli attuali processi operativi in un‟ottica di ottimizzazione ed efficienza degli stessi. In tale ottica risulta indispensabile, da parte della ditta appaltatrice, una profonda conoscenza dei modelli di funzionamento del sistema, sottesi ai processi suddetti, nonché delle modalità di configurazione/adattamento dei singoli componenti oggetto di implementazione e avviamento.
4.2 Infrastruttura tecnologica
In relazione a quanto sopra esposto l‟ASST Niguarda di Milano ha reso la disponibilitàdella seguente infrastrutture abilitanti, già configurate, predisposte e funzionanti a seguito del collaudo del sistema:
• Impianto di produzione - Finalizzato all‟operatività continuativa del sistema Cartella Clinica Elettronica CCE, opportunamente dimensionato e configurato e composto da:
• 2 server virtualizzati con funzioni di Web Service e Balancing (Apache)
[Digitare il testo]
• 2 server virtualizzati (4 nodi) con funzioni di Application Service (JBOSS)
• 1 server virtualizzato con funzione di “Staging” per la gestione delle “Release”
• 1 server virtualizzato con funzione di integrazione verso sistemi “esterni”
• 2 server virtualizzati con funzioni di Data Base Manager (DB primario e replica sincrona) già popolati con i dati dell‟organizzazione e delle strutture aziendali rilevate
• 1 server virtualizzato per erogazione del servizio di e-learning (DOCEBO + Apache)
• 1 server virtualizzato per l‟erogazione dei servizi di Back Office
• 1 server per l‟erogazione del servizio di Enterprise Service Bus con messaggistica HL7
• Impianto di pre-produzione - Finalizzato alla verifica di conformità e correttezza di funzionamento delle “release” di sistema che verranno ivi distribuite dall‟ASST Niguarda a tale fine. Tale impianto rappresenta il contenitore degli aggiornamenti periodici da utilizzare, dopo i necessari controlli, per i passaggi in produzione delle nuove versioni del sistema Cartella Clinica Elettronica CCE dell‟A.O. BMM di Reggio Calabria. Il Data Base contiene dati di prova, opportunamente predisposti ai fini di una completa verifica preliminare di funzionamento. L‟impianto, opportunamente configurato, è composto da:
• 2 server virtualizzati con funzioni di Web Service e Balancing (Apache)
• 2 server virtualizzati (2 nodi) con funzioni di Application Service (JBOSS)
• 1 server virtualizzato con funzione di “Staging” per la gestione delle “Release”
• 1 server virtualizzato con funzione di integrazione verso sistemi “esterni”
• 1 server virtualizzato con funzioni di Data Base Manager
• 1 server virtualizzato per l‟erogazione dei servizi di Back Office
Sarà onere della ditta aggiudicatrice la predisposizione, su proprie infrastrutture, di un opportuno ambiente di sviluppo (Source Repository) e di test per consentire gli adattamenti e le modifiche al codice sorgente, il test delle singole funzionalità, le verifiche di non regressione e la compilazione del codice sorgente ai fini del trasferimento dei componenti modificati nell‟impianto di pre-produzione.
Sarà altresì onere della ditta aggiudicataria la compilazione in codice eseguibile dei diversi “branch” in cui è suddiviso il codice sorgente ed il trasferimento degli stessi sui server di “staging” di pre-produzione preposti dall‟ASST Niguarda di Milano per i progressivi rilasci.
Il corretto funzionamento delle nuove release del sistema, implementato volta per volta nell‟impianto di pre-produzione, sarà sottoposto a verifica, da parte dei referenti nominati dall‟A.O. BMM di Reggio Calabria e dalla Direzione ICT dell‟ASST Niguarda di Milano. Il successivo passaggio nell‟impianto di produzione sarà subordinato all‟esito positivo di tali verifiche.
4.3 Componenti del sistema disponibili per la ditta aggiudicataria
L‟Ente appaltante metterà a disposizione una stazione di lavoro, opportunamente configurata, per l‟analisi del codice sorgente da parte delle ditte interessate. Il sopralluogo, obbligatorio per tutte le ditte partecipanti a pena di esclusione, sarà supportato da uno specialista incaricato dall‟ASST Niguarda di Milano per consentire l‟analisi dell‟architettura e dei contenuti del codice sorgente. La visualizzazione dei contenuti avverrà mediante il software di editing “Eclipse”, già utilizzato dall‟ASST stessa quale strumento di sviluppo open source. Non sarà consentita la riproduzione dei codici sorgente né successivi approfondimenti in merito.
Le informazioni rilevate in tale occasione dovranno risultare sufficienti per la presentazione delle offerte da parte delle ditte partecipanti.
Successivamente all‟aggiudicazione definitiva l‟Ente appaltante provvederà alla trasmissione, alla ditta appaltatrice per mezzo di un supporto informatico USB, dei seguenti componenti, che costituiscono l‟insieme dei sorgenti disponibili ai fini dell‟avviamento in produzione del sistema Cartella Clinica Elettronica CCE:
• Il completo codice sorgente del sistema “Cartella Clinica Elettronica CCE”, così come fornito dall‟ASST Niguarda di Milano, inerente l‟informatizzazione di tutte le funzionalità descritte in precedenza;
• L‟insieme delle procedure finalizzate alla definizione dei dati (DDL) che costituiscono l‟intera base dati attuale della Cartella Clinica Elettronica CCE sviluppata dall‟ASST Niguarda di Milano;
• L‟insieme delle procedure di popolamento e gestione dei dati codificati e di struttura realizzate con i sistemi open source (ETL) in uso presso l‟ASST Niguarda di Milano;
• Gli “script” e le procedure asincrone necessarie per il corretto funzionamento operativo;
• La documentazione di analisi ed evoluzione funzionale ad oggi prodotta dall‟ASST Niguarda di Milano.
[Digitare il testo]
4.4 PRESCRIZIONI E VINCOLI PER LO SVILUPPO E INTERVENTO SUL SW CCE
La progettazione dei sistemi oggetto dello sviluppo richiesto dall‟Ente dovrà attenersi scrupolosamente ai principi architetturali descritti nel seguito. L‟aggiudicatario sarà formalmente impegnato ad osservare tali principi nello sviluppo delle componenti applicative. Lo sviluppo dovrà essere effettuato sugli impianti appositamente predisposti dall‟Ente e sarà supervisionato da un responsabile di conformità del codice sorgente nominato dall‟Ente stesso per lo svolgimento di tale funzione.
L‟inosservanza dei principi e vincoli sopra richiamati, valutata dal suddetto responsabile di conformità, sarà considerata grave inadempienza e comporterà l‟esercizio della clausola di rescissione del contratto da parte dell‟Ente, con escussione delle fidejussioni e recupero degli eventuali corrispettivi già maturati dall‟aggiudicatario.
L'architettura “server” dei sistemi e componenti software commissionati dovrà rispondere ai seguenti principi di base:
• ogni funzione applicativa, che in modo omogeneo raggrupperà interfacce e implementazioni inerenti una singola caratteristica funzionale (feature), dovrà essere inclusa in un modulo applicativo singolo ed univoco;
• dovrà essere utilizzato un canale a messaggi (message bus) per mettere in comunicazione i suddetti moduli fra di loro o con servizi applicativi “isolati” di utilizzo comune;
• ogni modulo che necessita di utilizzare caratteristiche (feature) di sistema non presenti nella propria implementazione utilizza i necessari messaggi per comunicare con il modulo (feature), il quale espone l'interfaccia ed implementa la funzionalità eseguibile.
L'adozione di queste regole caratterizza l'architettura applicativa (Micro Services Architecture) che sarà implementata dalla collaborazione di diverse caratteristiche (feature) implementate separatamente e comunicanti esclusivamente attraverso il canale a messaggi (message bus).
L'architettura prevede la divisione dei moduli in tre aree di competenza:
1. moduli e componenti finalizzati a supportare il funzionamento dell'architettura stessa per:
• l'attivazione e la prima inizializzazione del sistema
• l'implementazione del registro dei moduli e delle interfacce attive nel sistema
• il supporto alla gestione strumentale dei componenti del sistema
• il supporto alla gestione dell'installazione (deploy) e della configurazione in tempo reale delle modalità di funzionamento dell'applicazione
• la gestione dei moduli del sistema e le funzioni di inizializzazione dell'intera applicazione.
2. servizi di supporto al funzionamento di tutti le componenti applicativo/funzionali per:
• il supporto per la gestione della autenticazione utente
• il supporto all'accesso ai servizi di directory
• la gestione dei profili utenti e dei gruppi
• la gestione delle autorizzazioni all'uso di applicazioni, di specifiche funzioni e dati
• la gestione della sicurezza nelle trasmissioni e nell'utilizzo dei dati e dei moduli
• la gestione e mantenimento delle sessioni parallele degli utenti connessi
3. componenti applicativo/funzionali che implementano l'effettiva logica elaborativa (Business Logic) dell'intero nuovo sistema per:
• l'esecuzione di applicazioni a singolo modulo
• l'esecuzione di applicazioArchitettura per sviluppo da parte di terzini multi-modulo
• la gestione della sequenza di esecuzione (workflow) dei moduli nell'ambito di un'applicazione o funzione complessa
• l'esecuzione di moduli per l'integrazione di applicazioni esterne
Ogni componente server potrà comunicare con altri moduli attraverso il canale a messaggi (message bus). Il canale a messaggi sarà riservato esclusivamente alla comunicazione fra diversi moduli applicativi e di sistema. Questo canale non sarà disponibile per l‟accesso da parte di client senza la mediazione di un modulo specifico. I client, e i moduli o applicazioni batch o esterni, potranno accedere ai servizi applicativi solo attraverso i servizi REST (REpresentational State Transfer) esposti.
I moduli di cui al precedente punto 1 e 3 saranno messi a disposizione dall‟Ente unitamente alle interfacce necessarie ed alla documentazione d‟uso. I moduli di cui al precedente punto 2, descritti nel capitolo “Funzionalità CCE oggetto della realizzazione”, sono oggetto della progettazione e realizzazione richieste.
La configurazione della messaggistica in/out del Service Bus (0MQ) sarà gestita dallo stesso responsabile incaricato della verifica di conformità del codice sorgente che garantirà altresì l‟osservanza dei requisiti di comunicazione client-server.
Nel seguito lo schema dell‟impianto di riferimento per l‟implementazione e l‟esecuzione dei sistemi commissionati:
[Digitare il testo]
Architettura dell’impianto del nuovo Portale Clinico CCE
1 - Ambiente di esecuzione delle funzioni client
• Javascript/Ecmascript: nome ufficiale dello standard JavaScript che rappresenta il linguaggio standard definito da W3C per la manipolazione del DOM (Document Object Model), responsabile per il rendering delle pagine html all'interno dei browser.
• Jquery: composto da una libreria di funzioni e relativo framework (sviluppati in Javascript) che consentono di semplificare ed organizzare al meglio le applicazioni JavaScript che manipolano il rendering delle pagine html all'interno dei browser.
• RxJS: libreria che implementa il pattern “observable” e svolge un lavoro inverso a quello tipicamente svolto da una “queue”, distribuisce cioè eventi ai client che si sono registrati per la ricezione degli stessi (da non confondere con il meccanismo di tipo “push”).
• CSS3: standard W3C per il controllo degli stili nel rendering della pagine html all'interno dei browser.
• MetroUI: interfaccia di tipo “Metro” simile (e nominata) a quella introdotta da Microsoft per “Windows 10”.
2- Ambiente di implementazione delle connessioni Rest e di routing/balancing delle stesse
• Apache2: per l'accesso via reverse/gateway proxy versione 2.4 (e superiori) mediante il modulo mod_proxy unitamente ai componenti di supporto per le operazioni con i diversi protocolli utilizzati: http, https, ajp, ws, wss, ...
• Linkerd: modulo complementare ad Apache2 che implementa un transparentproxy funzionale al rilevamento di servizi, al routing,
[Digitare il testo]
alla gestione degli errori e alla visibilità delle applicazioni software (utile soprattutto per quelle di tipo RESTful).
3 – Ambiente di esecuzione dei servizi di sistema per il funzionamento dell’architettura
• WildFly: application server (java based) dedicato al funzionamento dei moduli di sistema, anche implementati utilizzando il frameworkWildFly/Swarm, per l‟esecuzione dei servizi di attivazione, registrazione e controllo dei moduli applicativi di back end richiesti ai server di cui al successivo punto 4.
• 0MQ: Message Bus per la comunicazione fra i diversi moduli implementati dall‟ambiente server di appartenenza e per l‟integrazione con i moduli esterni che richiedono servizi di sistema.
4 – Ambiente di esecuzione delle componenti applicative/funzionali oggetto dello sviluppo
• WildFly: application server (java based) dedicato al funzionamento dei moduli applicativi, anche implementati utilizzando il frameworkWildFly/Swarm, per l‟esecuzione delle componenti funzionali di back end (business logic) richieste dalle applicazioni client (RESTful, web socket).
• 0MQ: Message Bus per la comunicazione fra i diversi moduli applicativi di back end che implementano la logica funzionale (business logic) e l‟integrazione con i moduli esterni che erogano servizi comuni o di sistema.
5 – Ambiente di esecuzione dei servizi comuni funzionali all’esecuzione delle componenti applicative oggetto dello sviluppo
• WildFly: application server (java based) dedicato all‟erogazione dei servizi, anche implementati utilizzando il frameworkWildFly/Swarm, finalizzati all‟attivazione e mantenimento delle sessioni (autenticazione, autorizzazione, profilazione, ecc.) come specificati nello schema che precede.
• 0MQ: Message Bus per la comunicazione fra i diversi moduli di servizio che implementano le funzioni sopra specificate e l‟integrazione con i moduli esterni che erogano servizi di sistema o che eseguono le componenti funzionali applicative di back end.
6 – Ambiente di gestione della persistenza e di esposizione dei servizi documentali interoperabili in conformità agli standard nazionali (IHE)
• Postgresql: database server, eventualmente affiancato da PgPool-II con funzioni di caching, balancing ed High Availability del database stesso.
• WildFly: application server (java based) dedicato all‟esposizione dei servizi base di accesso al database server (CRUD) eventualmente richiesti da sottosistemi o applicazioni “esterne” all‟impianto.
Sarà consentita la realizzazione di componenti esterni all‟architettura sopra descritta solo se giustificati da motivazioni oggettive di “isolamento” degli stessi (ad esempio l‟implementazione di un sottosistema tipo CRM per la gestione del centro servizi PAI) che richiedano un funzionamento indipendente dal Nuovo Portale Clinico CCE. L‟eventuale presenza di tali componenti esterni all‟architettura (cioè sviluppati con tecniche e modelli differenti da quelli richiesti) sarà sottoposta ad una valutazione insindacabile di oggettività da parte della commissione, a pena di esclusione dal procedimento.
In tali casi, per l‟integrazione con il Nuovo Portale Clinico CCE, saranno resi disponibili dall‟Ente i servizi propri della piattaforma e/o i servizi CRUD di base per l‟accesso al repository clinico, mediati comunque dai moduli di autenticazione, autorizzazione e profilazione forniti dagli appositi server.
In ogni caso l‟accesso ai dati ed ai servizi del Nuovo Portale Clinico CCE da parte di applicazioni extra aziendali (o comunque parzialmente distribuite) dovrà essere implementato mediante applicazioni web esistenti ovvero da svilupparsi ed implementarsi sulla DMZ aziendale (vedi Portale on-line Niguarda) a cura dell‟aggiudicatario.
4.4.1 MODELLO E ARCHITETTURA DI SVILUPPO DEL SOFTWARE
Il modello di sviluppo richiesto per le componenti delle applicazioni oggetto del procedimento è quello definito con la sigla SPA (Single Page Application), che utilizza JavaScript (e librerie aggiunte) per creare una applicazione client completa all'interno di una singola pagina web utilizzando solo il rendering dei browser. Al fine di garantire uno sviluppo delle applicazioni conforme all‟assunto l‟aggiudicatario dovrà adottare i modelli schematizzati nel seguito.
CLIENT - Modello di riferimento per lo sviluppo delle componenti JavaScript:
[Digitare il testo]
Architettura client di font end
Gli apparati per lo sviluppo delle componenti client dei sistemi richiesti saranno resi disponibili dall‟Ente presso la propria unità operativa (U.O.C. ICT e tecnologie della comunicazione).
L‟installazione degli ambienti di sviluppo sarà effettuata da specialisti interni dell‟Ente e verificata dal Responsabile di conformità che ne certificherà il corretto utilizzo da parte degli sviluppatori e specialisti incaricati dall‟aggiudicatario.
SERVER - Modello di riferimento per lo sviluppo dei moduli di back-end Micro Services:
[Digitare il testo]
Architettura server di back end
Il modello di implementazione a Micro Services richiede lo sviluppo di componenti software, funzionali e di servizio, definibili “atomici” e capaci di concatenarsi automaticamente in funzione del contesto (mediante motori di Business Process Management), consentendo così la futura informatizzazione di processi complessi mediante la composizione di moduli funzionali già sviluppati in precedenza e composti come un puzzle per risolvere le progressive esigenze.
I moduli software sviluppati dall‟aggiudicatario saranno sottoposti al giudizio del garante di conformità dell‟Ente al fine di verificare l‟osservanza delle prescrizioni nelle soluzioni di volta in volta presentate.
4.4.2 SVILUPPO - Postazioni di lavoro e ambiente per lo sviluppo del software
Sarà messo a disposizione dall‟Ente un ambiente composto da quattro postazioni di lavoro, pre configurate e comprendenti i necessari strumenti di sviluppo, unitamente ad un impianto di servizi a supporto delle progressive fasi di lavorazione dei moduli software richiesti.
L‟ambiente da utilizzarsi per lo sviluppo dei sistemi richiesti è illustrato dallo schema che segue:
[Digitare il testo]
Strumentazione per lo sviluppo del software
4.4.3 METODOLOGIA
E‟ prevista la partecipazione e supervisione dei lavori da parte di specialisti dell‟Ente, per tutta la durata del processo di sviluppo del software.
Quale ulteriore garanzia di conformità dei risultati attesi l‟Ente ha deciso di adottare la metodologia di sviluppo e Project Management SCRUM, metodologia alla quale gli specialisti dell‟aggiudicatario si dovranno adeguare e della quale sono richieste agli stessi conoscenza ed esperienza dimostrabili.
Per completezza di informazione si illustra nello schema seguente il processo metodologico di sviluppo:
L‟osservanza delle tempistiche di cui sopra è elemento essenziale e sarà valutata dall‟Ente, unitamente all‟adozione delle prescrizioni illustrate in precedenza, per la valutazione della qualità del software prodotto ed il conseguente riconoscimento positivo del risultato nonché dei relativi corrispettivi.
E‟ quindi essenziale che la progettazione dei sistemi da sviluppare, oggetto della proposta tecnica, risulti conforme ai vincoli imposti dalla metodologia e garantisca la realizzabilità dei componenti software secondo le prescrizioni e i vincoli sopra illustrati.