Contract


PROCEDURA APERTA PER L’AFFIDAMENTO QUINQUENNALE DEL SERVIZIO DI MANUTENZIONE ADEGUATIVA, MIGLIORATIVA E CORRETTIVA (MAC), MANUTENZIONE EVOLUTIVA (MEV), INGEGNERIZZAZIONE ESB DEGLI APPLICATIVI DEL SISTEMA INFORMATIVO SANITARIO, COSTRUZIONE E GESTIONE DEL SISTEMA INFORMATIVO SANITARIO INTEGRATO REGIONALE DELLA BASILICATA (SISIR)


Allegato 3A Descrizione dei Servizi

Indice generale

1. SISTEMA INFORMATIVO SANITARIO INTEGRATO REGIONALE 3

1.1. OGGETTO DELLA GARA 3

1.2. SCOPO E CAMPO DI APPLICAZIONE 6

1.3. INTERVENTI E MODALITÀ 8

1.4. ACRONIMI E DEFINIZIONI 13

2. PROGETTAZIONE E REALIZZAZIONE DI ADEGUAMENTI ARCHITETTURALI ED INFRASTRUTTURALI DEL SISIR15

2.1. STATO DELL’ARTE DELL’INFRASTRUTTURA ICT 15

2.1.1. INFRASTRUTTURA DI TRASPORTO 16

2.1.2. SINTESI SULLA DISTRIBUZIONE DELLE MACCHINE SERVER PRESSO LE STRUTTURE 19

3. REQUISITI TECNICI 25

3.1. REQUISITI TECNICI E TECNOLOGICI PER I SISTEMI INFORMATICI APPARTENENTI AL SISIR 25

3.1.1. GESTIONE DELLA SICUREZZA 25

3.1.2. ACCESSIBILITÀ 26

3.1.3 INDIPENDENZA DALLA PIATTAFORMA E FRUIBILITÀ ANCHE DA DISPOSITIVI MOBILI 26

4. PROGETTI 27

4.1. PREMESSA METODOLOGICA PER I PROGETTI 27

4.2 INTERFACCIA UNICA S.I.S.I.R. E ADEGUAMENTO IHE 32

4.2.1 CARATTERISTICHE FUNZIONALI MINIME 34

4.3 DATA WAREHOUSE DEI FLUSSI SANITARI 36

4.3.1Flussi NSIS e verso Regione 36

4.4 ANAGRAFE UNICA CON REGISTRO CAUSA MORTIS E ANAGRAFICA CONTATTI 43

4.4.1 Caratteristiche 43

4.4.2 Descrizione 46

4.4.3 REGISTRO CAUSA MORTE 47

4.4.4 REGISTRO CAUSA MORTE Stato Attuale Del flusso informativo 48

4.5 DEMATERIALIZZAZIONE PRESCRIZIONI 49

4.6 REVISIONE ED AMMODERNAMENTO ARCHITETTURALE DEI SISTEMI SOFTWARE IN MANUTENZIONE 52

4.7 SISTEMA PER IL TRACCIAMENTO DELLA QUALITA' DEL SISIR PER LA GESTIONE DEL CODICE SORGENTE, DEL PROGETTO, DEL VERSIONAMENTO SISTEMI SOFTWARE/HARDWARE, DELLA DOCUMENTAZIONE E MANUALISTICA 58

5. SERVIZIO DI ASSISTENZA APPLICATIVA E SISTEMISTICA 60

5.1. SERVIZI DI “MANUTENZIONE” APPLICATIVA 60

5.1.1. MANUTENZIONE ADEGUATIVA, CORRETTIVA E MIGLIORATIVA(MAC) 60

5.1.2. MODALITÀ GENERALI DI EROGAZIONE DEL SERVIZIO 61

5.1.3 METODO DI STIMA DELL'IMPEGNO DI SVILUPPO e MEV 65

5.1.4. MODALITÀ OPERATIVA DI ATTIVAZIONE ED EROGAZIONE DEL SERVIZIO MAC 68

5.1.5. MANUTENZIONE EVOLUTIVA SOFTWARE DEL SISIR (MEV) 71

5.2 SERVIZI DI ASSISTENZA, SISTEMISTICA, OPERATIVA E FORMAZIONE A CONSUMO 77

6 PENALI 79

1. SISTEMA INFORMATIVO SANITARIO INTEGRATO REGIONALE

1.1. OGGETTO DELLA GARA

Intenzione della Regione Basilicata (indicata di seguito come SA) è di attivare una procedura di appalto di cui al presente capitolato consistente nei servizi di:

a) Servizio di Manutenzione Adeguativa, Migliorativa e Correttiva (MAC), Manutenzione Evolutiva (MEV), Ingegnerizzazione in Architettura ESB degli Applicativi del Sistema Informativo Sanitario, Costruzione e Gestione del Sistema Informativo Sanitario Integrato Regionale Della Basilicata (SISIR). Delle applicazioni oggetto del presente appalto la Regione Basilicata detiene la proprietà del codice sorgente, esse sono installate ed operative presso tutte le Aziende Regionali e presso la Regione;

1) ANAGRAFICA UNICA POPOLAZIONE ASSISTITA (art 22 comma 7);


2) GESTIONE CENTRALIZZATA DEI CENTRI ESTERNI ACCREDITATI;


3) PROGETTO TESSERA SANITARIA;


4) SISTEMA DI PRODUZIONE FLUSSI INFORMATIVI PER NSIS;


5) SISTEMA DI REPORTING DIREZIONALE;


6) PORTALE TELEMEDBAS;


7) GESTIONE DEI RICOVERI E DEGLI ACCESSI IN PRONTO SOCCORSO;


8) CUP CENTRO UNIFICATO DI PRENOTAZIONE;


9) CARTELLA AMBULATORIALE E REFERTAZIONE PRESTAZIONI;


10) FASCICOLO SANITARIO REGIONALE (LUMIR);


11) MEDICINA DI BASE (prescrizione presso ASL di appartenenza);


12) GESTIONE PIANO TERAPEUTICO SU REPARTO PORTABILITA’ INDIVIDUALE CLINICA (PIC);

13) ITM BROKER.


b) Gestione del ciclo di vita del Software, del Codice Sorgente, della Documentazione e delle versioni costituenti il patrimonio Informatico del SISIR Regionale e di un sistema di gestione dei ticket (preferibilmente integrato); l'installazione, la configurazione ed il mantenimento in esercizio dei sistemi in parola, è a totale carico della Ditta

Aggiudicataria (DA). La Regione fornirà idonei locali presso i quali installare i sistemi. In particolare i sistemi devono gestire il codice sorgente, la documentazione, tracciare tutti i rilasci, gestire la fase di staging, tracciare tutte le richieste di cambiamento e/o segnalazioni di malfunzionamento, le configurazioni e tutto quanto necessario a garantire la qualità di processo e di prodotto, in conformità agli standard internazionali ISO 12207, ovvero equivalenti, relativi al ciclo di vita dei software di proprietà regionale in dotazione al Sistema Sanitario della Basilicata. La DA deve assicurare tutto quanto necessario in termini di interventi, assistenza operativa, supporto e formazione per tutti gli operatori. La DA, per la manutenzione evolutiva per tutti gli sviluppi d'integrazione e per la realizzazione dei Progetti, pena la rescissione del contratto in danno, è obbligata ad utilizzare il metodo di calcolo degli Use Case Point per la stima del costo di sviluppo; a produrre, oltre alla documentazione minima richiesta nei paragrafi successivi, tutta la documentazione prevista dallo standard di qualità che intende adottare e per i quali ai è certificata. Si precisa che il valore dello sviluppo sarà calcolato sulle prestazioni effettivamente erogate. Al termine del contratto, tutti i sistemi installati e realizzati per la gestione del ciclo di vita, di progetto e dei ticket rimangono di proprietà della Regione Basilicata. Nel caso di utilizzo di sistemi proprietari, ovvero non a licenza open source, la DA deve fornire, a totale suo carico ed onere, tutti i codici, la documentazione, i progetti software, gli script di compilazione, gli ambienti di test in formato aperto e non proprietario nelle configurazioni opportune ed allineate ai rilasci e alle versioni installate, nelle quantità e qualità opportune. La DA rinuncia esplicitamente alla proprietà delle opere di intelletto realizzate durante l'esecuzione del contratto ed ad eventuali azioni di rivalsa sulle stesse opere relative a tutti i sistemi sviluppati appositamente per la Regione. Inoltre, per quanto attinente alle architetture di sistema impiegate e realizzate per l'erogazione dei servizi richiesti, in particolare alle architettura hardware, architetture dei sistemi operativi, database management system, framework software, web application, sistemi di gestione identità e profili utenze, formati documentali, la DA deve dimostrare che tutti i prodotti sono aperti, utilizzabili/riutilizzabili senza limitazioni di uso temporale e di numero e, per quelle parti per cui è applicabile, sono interoperabili e utilizzano standard aperti e documentati come previsto dal D.Lgs 235/2010 e ss.mm.ii.

c) Re-ingegnerizzazione, attraverso specifici progetti, degli applicativi e revisione delle architetture software in ottica SOA, migrazione verso applicazioni di tipo WEB 2.0

R.I.A che non hanno la necessità di installazione di driver applicativi sui clients autorizzati all'utilizzo e/o installazioni o configurazioni dei server dipendente dal client utilizzato. La Ditta Concorrente deve prendere visione delle configurazione dei sistemi (hardware e software) eroganti i servizi attuali e produrre, in sede di gara, dettagliata relazione tecnica della architettura che intende realizzare nel corso dell'esecuzione del progetto, evidenziando in maniera chiara, tutti gli S.L.A. per i servizi del SSR in termini di risposta alle transazioni, continuità di erogazione del servizio, politiche di sicurezza e disaster recory e tempi di ripristino in caso di indisponibilità.

I progetti di integrazione e revisione devono essere realizzati, collaudati, e messi in esercizio nella loro interezza e presso tutto il SSR della Basilicata entro i primi due anni (24 mesi) contrattuali a decorrere dalla data di stipula e sottoscrizione del contratto o entro le tempistiche DEFINITE MANDATORIE le cui attività derivano da programmazione stabilita da legislazione Regionale o Nazionale.

Il sistema di gestione del ciclo di vita del software, documentazione, versionamento, testing, staging, rilasci, tracciamento e presa in carico errori e segnalazioni (ticket) e gestione dei progetti deve essere in esercizio entro 60 giorni dalla stipula del contratto.

d) Assistenza Sistemistica e Formazione attività a consumo e su specifiche richieste delle AA. SS per un ammontare annuo massimo fisso e stabilito.

Il contratto d’appalto è di tipo “a consumo” e pertanto la prestazione è pattuita con riferimento ad un determinato arco temporale, per interventi non predeterminati nel numero, ma divenuti indifferibili secondo le effettive necessità della stazione appaltante.


Per i servizi di Assistenza Sistemistica e Formazione, i collaboratori del Direttore dell’esecuzione delle singole Aziende regionali, nell'ambito di quantità assegnate dalla SA, possono richiedere interventi che vanno in ogni caso comunicati al Direttore dell'esecuzione o suoi delegati. Le richieste di assistenza sono remunerate secondo le modalità descritte successivamente, con possibile variazione o riassegnazioni a parità di valore economico per le singole quantità previste e concordate con il Direttore dell'esecuzione. Le ristorazioni economiche degli interventi in parola, commissionati e collaudati dalle AA. SS., sono a carico e vanno fatturati alle AA. SS. richiedenti in conformità alle procedure previste dal contratto.

Gli interventi manutentivi MEV e di Assistenza che l’Appaltatore dovrà eseguire nel tempo utile del contratto saranno ordinati e disposti anche a più riprese dal Direttore dell'esecuzione.

Gli interventi manutentivi MAC che l’Aggiudicatario dovrà eseguire nel tempo utile del contratto saranno a canone fisso e, a seconda della tipologia, potranno essere automatici o commissionati anche a più riprese dal Direttore dell'esecuzione e/o richiesti dagli utilizzatori del sistema Informativo Sanitario, tracciati dalla Ditta Appaltatrice secondo gli standard dell'ingegneria del software, ma obbligatoriamente autorizzati dal Direttore dell’esecuzione.

Gli interventi di “Revisione/Ammodernamento Architetturale, Integrazione e Data Warehouse” degli applicativi che l’Aggiudicatario deve eseguire nel tempo di vigenza del contratto, individuati nel paragrafo “PROGETTI”, saranno remunerati secondo la quotazione prevista in sede di offerta economica, al netto di eventuali penali, secondo le procedure indicate nel contratto, dal Direttore dell'esecuzione se approvati anche dai singoli Referenti delle Aziende del Sistema Informativo SISIR, identificati di seguito con gli assistenti al Direttore dell’esecuzione ai sensi dell’art. 300, comma 3 del DPR n. 207 del 2010. Si precisa che, per la progettazione e gestione dei “PROGETTI” devono essere utilizzate le procedure definite, redatta tutta la documentazione minima richiesta e devono essere utilizzati gli

strumenti di gestione commissionati e realizzati di cui al punto precedente b) Gestione del CICLO DI VITA DEL SOFTWARE.

La DA è libera di proporre, in sede di offerta tecnica, la sostituzione intera o di parti del sistema, purché integrate con tutti gli applicativi di terze parti già in esercizio, nel rispetto del vincolo di proprietà intellettuale della SA dello stesso, ovvero, la Regione Basilicata diviene esclusivo proprietario di tutti i codici sorgenti e di tutto quanto necessario a produrre il sistema nelle versioni installate relativamente al contratto stipulato ed alle versioni realizzate durante lo svolgimento dello stesso. Inoltre, l'aggiudicatario deve assicurare che il sistema che intende sostituire è utilizzabile, nella sua interezza, direttamente in tutte le sue componenti (sistemi operativi, RDBMS, librerie, formati, servizi applicativi, interfacce dati, ecc.) senza limitazioni temporali di uso e di funzionamento regolare, derivanti da un qualsiasi componente del sistema informativo stesso. Più precisamente, il nuovo sistema dovrà essere riusabile liberamente senza limitazioni alcuna sulla proprietà intellettuale, se applicabile, è interoperabile e la fornitura comprendere anche i codici sorgenti nelle versioni apposite prodotte per la Regione Basilicata. Per la versione in esercizio al termine del contratto la Regione Basilicata detiene la proprietà intellettuale esclusiva. Infine, in caso di sostituzione, la Ditta deve raggiungere contemporaneamente per tutti gli operatori del SSR lo stesso grado di operatività ed utilizzabilità esistente all'atto della stipula del contratto per il sistema informativo sanitario in uso. In caso di sostituzione, la tempificazione massima per tutte le attività è di 24 mesi dalla data di stipula del contratto, con una previsione minima di parallelo con i sistemi sostituiti di 6 mesi.


1.2. SCOPO E CAMPO DI APPLICAZIONE

La Regione Basilicata ha, da tempo, avviato un importante piano di consolidamento, integrazione ed evoluzione, sia del sistema informativo regionale che dei sistemi informativi aziendali, afferenti al Sistema Sanitario Regionale (SSR), attraverso un insieme di strumenti programmatici ed azioni coordinate. L’attuale patrimonio informativo regionale risulta, di conseguenza, estremamente omogeneo, in quanto frutto di una gestione unitaria condotta nel tempo dalla Regione medesima e/o da apposite Unioni d’Acquisto Regionali. Tale approccio metodologico ha quindi prodotto:

 la omogeneizzazione delle infrastrutture tecnologiche di base;


 l’uniformità del livello di informatizzazione dei servizi applicativi aziendali.

In tale contesto e sulla base delle precedenti premesse, obiettivo della presente gara è:


Servizio di Manutenzione Adeguativa, Migliorativa e Correttiva (MAC), Manutenzione Evolutiva (MEV), Ingegnerizzazione in Architettura ESB degli Applicativi del Sistema Informativo Sanitario, Costruzione e Gestione del Sistema Informativo Sanitario Integrato Regionale Della Basilicata (SISIR). Delle applicazioni oggetto del presente appalto la Regione Basilicata detiene la proprietà del codice

sorgente, esse sono installate ed operative presso tutte le Aziende Regionali e presso la regione;

Il servizio richiesto deve coprire tutte le aree, sia con specifico riferimento alle singole aziende che al Dipartimento Regionale, manutenendo o fornendo parti dell’attuale sistema, in un’ottica generale di cooperazione per architetture software che integrano servizi orientati di tipo enterprise (architettura e-SOA) e deve evolvere verso il nuovo Sistema Informativo che, enfatizzando il concetto di Affinità di Dominio, rispondendo quindi a precisi requisiti funzionali, di sicurezza, omogeneità ed integrazione IHE e HL7, avvalendosi ed ottimizzando tutti gli investimenti infrastrutturali regionali.

Il raggiungimento degli obiettivi del sistema deve essere attuato, quindi, attraverso la salvaguardia dei:

 processi di lavoro attualmente già automatizzati;


 livelli di servizio per le transazioni interattive, con riferimento al tempo di risposta definito come risultante della somma del Transaction Server Processing time e application server processing time definiti nel documento CNIPA "I livelli di servizio. Come definirli e controllarli nei contratti della P.A. - X.Xxxxx". I tempi di risposta minimi richiesti indicati verranno misurati per le transazioni interattive realizzate nelle seguenti tipologie di servizio e migliorie dei tempi minimi indicati saranno oggetto di valutazione:

1. servizi di sportello tempo di risposta Max 10 sec;


2. servizi di back office tempo di risposta Max 15 sec;


3. produzione stampe tempo di risposta Max 10 sec;


4. statistiche ed estrazioni dati tempo di risposta max 30 sec;


 continuità di erogazione dei servizi: i servizi sono di tipo 24x7x365;


 funzionalità esistenti risultate efficaci ed efficienti;


 dati nell’ambito della standardizzazione complessiva;


 modalità di cooperazione applicativa con altri sistemi informatici;


 copertura attuale dell’automazione dei processi di lavoro e tutti i dati disponibili;


 gestione del data warehouse dei flussi informativi regionali/nazionali;


 evoluzione verso piattaforme software distribuite che erogano servizi fruibili anche in mobilità e scalabili ed indipendenti dalle architetture software di base.

Non si può e non si deve ignorare o trascurare il funzionamento dell’attuale sistema informativo che realizza il monitoraggio e il governo dei processi sanitari. Il Dipartimento Politiche della Persona,

infatti, nelle more del completamento del progetto del nuovo SISIR, ha la necessità di assicurare la corretta e completa funzionalità delle applicazioni di proprietà che attualmente sono in esercizio presso il Dipartimento stesso e presso tutti gli enti del Servizio Sanitario della Regione Basilicata al fine di:

 evitare rischi di interruzione e di discontinuità nei servizi erogati dal sistema del SSR;


 consentire di ottemperare alla produzione dei flussi informativi obbligatori ai fini del patto di stabilità del settore sanitario con certificazione del documento elettronico.


1.3. INTERVENTI E MODALITÀ

Gli interventi predisposti a tal fine, sono essenzialmente di:


 Manutenzione correttiva, migliorativa, ed adeguativa (MAC), assistenza operativa anche nel miglioramento dei tempi di risposta e nella usabilità dei sistemi software/hardware che attualmente costituiscono il Sistema Informativo Sanitario Regionale e che vengono utilizzati da tutte le Aziende del SSR;

 Assistenza, consulenza e manutenzione evolutiva (MEV) sugli stessi software di cui al punto precedente;

 Ammodernamento del sistema informativo con l'obiettivo di renderlo facilmente e totalmente integrabile con i requisiti e vincoli derivanti dalla messa in esercizio del Fascicolo sanitario regionale agli standard indicati dal Ministero della Salute, le modalità previste dai Tavoli di Sanità Elettronica Nazionali ed Europei e gli standard Internazionali IHE ed HL7.

 Ammodernamento delle architetture software dei sistemi in manutenzione per renderle indipendenti dalle architetture di base utilizzate, ovvero aperte (Sistema operativo, DBMS, librerie software, middleware, interfacce di visualizzazione etc.), cioè utilizzano formati dati non proprietari privi di limitazioni sull'utilizzo quindi realmente riusabili, inoltre, i sistemi costituenti il SISIR devono essere fruibili anche in mobilità e da dispositivi mobili.

I sistemi software costituenti il SISR che sono interessati ai suddetti interventi sono esplicitamente riportati nelle schede informative allegato 3B.

Scopo del presente documento è quello di descrivere il progetto, con i requisiti e i vincoli, allo scopo di delineare quali sono i software oggetto di affidamento, attualmente funzionanti in maniera corretta e dei quali si vuole mantenere caratteristiche e funzionalità (facilità di utilizzo per gli operatori, minimo impatto sugli stessi, minimo impatto sui costi per la formazione, etc.). Le schede descrittive degli applicativi, indicate nell’allegato, quindi, rappresentano un punto fermo delle funzionalità operative esistenti.

E' facoltà del partecipante sostituire interamente il sistema Informativo Sanitario Regionale attuale garantendo le caratteristiche elencate:

I. Consegna e inserimento nel sistema di gestione indicato del ciclo di vita, di tutto il codice sorgente, script, documentazione di progetto, manualistica tecnica ed utente e di tutto quanto necessario alla produzione degli applicativi con garanzia di qualità e manutenibilità costituenti il sistema informativo.

II. Rinuncia incondizionata alla proprietà del codice nella versione rilasciata appositamente e oggetto di tutto il presente appalto; il sistema diviene esclusiva proprietà della Regione Basilicata. Garanzia del totale riuso del sistema, in tutte le componenti (sistema operativo, gestore di database, middleware presentazione, elaborazione, autenticazione, autorizzazione ed accesso dati) senza vincoli nel numero, nel tempo e nella capacità funzionali derivanti da uno qualsiasi dei componenti l'architettura.

III. Fornitura di tutte le licenze per tutte le componenti in licenza d'uso senza limitazioni nel tempo e nel numero (Sistemi Operativi, Sistemi Hardware, Sistemi di DBMS, Framework Software, Librerie, formati di dati). Tutta la documentazione a corredo deve esser consegnata in formati aperti ampiamente conosciuti e non proprietari.

IV. Completare tutte le operazioni di sostituzione, formazione, fruizione e messa a regime contemporaneo di tutti gli operatori del SSR entro 24 mesi dalla stipula del contratto. Inoltre, garantire un parallelo con il vecchio sistema per almeno 6 mesi dalla data di attiva a regime del nuovo sistema eventualmente fornito.

In ogni caso, si precisa che i sistemi software (e le relative procedure, script, librerie oggetto della gara), prodotti e forniti nelle versioni appositamente realizzate per la Regione Basilicata sono di esclusiva proprietà della stessa; devono essere forniti anche in formato sorgente nella versione aggiornata alla ultima release approvata dalla SA e in esercizio, comprensivo di tutto quanto necessario alla sua realizzazione ed esercizio (script, librerie, procedure).

La fornitura è espressa in un unico lotto relativo alla manutenzione correttiva, migliorativa, adeguativa, evolutiva, integrazione e assistenza sistemistica/formazione degli applicativi di proprietà della Regione in uso nelle aree del SSR comprensivo delle seguenti quattro macro aree informative e giurisdizionali:

 Sistema Informativo del Dipartimento Salute, Sicurezza e Solidarietà Sociale.


 Sistema Informativo delle Aziende Sanitarie Provinciali ASP e ASM.


 Sistema Informativo della Azienda Ospedaliera San Carlo.


 Sistema Informativo dell'IRCCS-CROB.

Tali macro aree dovranno essere coperte da sistemi autonomi per quanto riguarda gli aspetti gestionali e/o clinico-diagnostico, aperti per la loro integrazione come componenti appartenenti ad un unico sistema per quanto attiene gli aspetti di programmazione, controllo, interscambio e cura.

L’appalto ha la durata di 60 (sessanta) mesi dalla data di stipula del contratto, salvo facoltà della stazione appaltante di richiederne l'esecuzione anticipata a far data dalla intervenuta esecutività del provvedimento di aggiudicazione definitiva.

La durata dell'appalto si intende comprensiva della fase di presa in carico dei sorgenti e della documentazione esistente (fase che non deve superare sessanta giorni), come descritto in seguito nel presente allegato.

Ove entro il termine di durata dell’affidamento non sia stato ancora completato il processo di realizzazione ed integrazione del nuovo Sistema Informativo Sanitario Regionale, alla definizione del cui affidamento la presente procedura è riferita, la Regione, libera di richiedere il pagamento delle eventuali penali applicabili, potrà richiedere alla Ditta aggiudicataria di assicurare, agli stessi patti e condizioni stabiliti nel contratto, la prosecuzione del servizio, onde evitare eventuali disservizi e garantire il corretto funzionamento degli applicativi in uso.

Si intende che la responsabilità progettuale e tecnica delle offerte è delle ditte concorrenti. Le ditte dovranno elaborare il progetto, considerando che la fornitura deve prevedere, al minimo:

 la totale e completa proprietà della Regione del software manutenuto o realizzato nell’ambito della manutenzione evolutiva (MEV) e, nel caso che una delle componenti del sistema sia proprietario, la cessione delle licenze d’uso dei software di base e relativi applicativi di base per i sistemi informatici oggetto del presente appalto, preventivamente autorizzati dalla Regione, necessari all'esercizio della completa funzionalità con un numero di licenze illimitate per l’implementazione dell’architettura proposta ed approvata dalla Regione;

 servizi di manutenzione adeguativa, evolutiva, correttiva, l’assistenza operativa agli utenti, servizi di formazione e sistemistici. La fornitura di un sistema chiavi in mano per la gestione del ciclo di vita del software, dei rilasci, di gestione dei progetti, della documentazione di progetto, dei manuali di progetto e di tutto quanto necessario alla tracciabilità e garanzia di qualità, nel rispetto degli standards ISO sulla qualità di produzione dei sistemi software. Il sistema di gestione deve essere privo di limitazioni di utilizzo nel tempo o nel numero.

 servizi di help-desk per la gestione delle richieste e segnalazioni di malfunzionamenti e/o miglioramenti di utilizzo del sistema gestionale installato presso la regione;

 i servizi di assistenza sistemistica e formazione a consumo per tutto il personale a vario titolo coinvolto nelle diverse fasi attuative del progetto;

 tutto quant’altro specificato nel presente capitolato e nella offerta, necessario al corretto esercizio del sistema informativo sanitario integrato regionale.

 Utilizzo di canali di trasmissione sicuri e protocolli sicuri di trasmissione dati sanitari;

 Memorizzazione di tutta la documentazione progettuale, così come riportato nel presente Allegato Tecnico, nel repository regionale di progetto avente le funzionalità descritte al paragrafo PROGETTI.

La professionalità del personale impiegato per l’erogazione dei servizi oggetto del contratto costituisce elemento di valutazione. Durante l’esecuzione del contratto la Ditta affidataria è obbligata a mantenere il personale indicato nell’offerta. In caso di sostituzione del personale, la Ditta deve comunicare, con almeno 30 giorni di anticipo, al Direttore dell'esecuzione o suoi delegati l’intenzione di sostituzione con nuovo personale di uguale e documentata esperienza. Il Direttore dell'esecuzione ha la facoltà di rifiutare la sostituzione e richiedere, motivando, a giudizio insindacabile, figura sostitutiva diversa da quella indicata entro 10 giorni dalla richiesta di sostituzione. In caso di mancato accordo la Ditta è tenuta a pagare la relativa penale indicata nel paragrafo “Penali”.

La conservazione in formato elettronico dei dati sanitari fa emergere anche un’ulteriore problematica di integrazione relativa alla sicurezza dei dati archiviati, soprattutto per quanto riguarda il profilo connesso alla protezione del dato da eventuali furti o intrusioni, sia da parte di soggetti terzi non autorizzati, sia da parte degli stessi soggetti autorizzati che, tuttavia, non possono agire in maniera libera e inconsapevole senza alcuna forma di controllo. Per tale scopo il progetto deve prevedere la caratteristica obbligatoria di totale ed incondizionata conformità ai principi fondamentali che attengono alla digitalizzazione dei documenti sanitari che sono contenuti nelle norme generali in materia di conservazione digitale dei documenti, ovvero nel Codice dell'Amministrazione digitale (D.Lgs. n.82 del 2005 – CAD) e nella Deliberazione CNIPA (ora AGiD) n.11 del 19 febbraio 2004. La particolare natura della documentazione sanitaria prevede l’adozione di particolari regole e accorgimenti a garanzia sia sotto il profilo dell'autenticità ed immodificabilità nel tempo, sia della protezione dei dati personali sanitari contenuti in tali documenti. Il sistema, così come richiesto dagli standard europei di integrazione, deve implementare opportune interfacce in grado di esporre servizi nativi di conservazione a norma compatibili con profilo di integrazione XDS.b - Cross-Enterprise Document Sharing e Audit Trail and Node Authentication IHE.

Anche ai sensi di quanto previsto dall’All. B del DLgs. 196 del 2003 a garanzia della totale protezione del dato sanitario, è di fondamentale rilevanza, inoltre, predisporre un Piano per la sicurezza Operativa redatto in base alle norme BS 25999:2 e ISO 27001:2005, che garantisca la sicurezza in caso di grave compromissione dei dati che possa pregiudicare, comunque e nonostante le previste sicurezze, il dato sanitario. Tale Piano dovrà essere costantemente revisionato e gestito anche analizzando e gestendo tutte le problematiche rilevate e gestite nel corso di attuazione dei servizi oggetto della gara.

Obbiettivo della proposta tecnica è dimostrare i passi e i processi implementativi che la DA intende utilizzare e mettere in atto per costituire un architettura software del SISIR di tipo HUB & SPOKE. Un modello che eviti tutte le integrazione di tipo PUNTO-PUNTO dei diversi sistemi informativi sanitari. Nella descrizione deve essere chiaramente evidente l'architettura del Enterprise Service Bus che si intende realizzare, rimuovendo qualsiasi collegamento fra i produttori e consumatori dei

servizi telematici. L'obiettivo che si vuole raggiungere è che tutti i processi di integrazione (presenti e futuri) interni all'area Sanitaria Regionale e Sociale, Aziendale, Regionale e Nazionale nell’ambito del Sistema Informativo Socio Sanitario Integrato Regionale devono essere gestiti dal ESB; cioè il disaccoppiamento fra i produttori di informazioni economiche- gestionali, sanitarie e i consumatori delle stesse, evitando integrazioni puntuali. Inoltre, localizzare tutte le funzionalità a supporto, quali sicurezza, routing, garanzia di consegna, trasformazione, integrazione, audit e log, su un unico livello di trasporto, così disaccoppiando il trasporto dell’informazione, dal produttore e dal consumatore. Si intende che la responsabilità progettuale delle offerte è a totale onere delle ditte concorrenti. Le ditte dovranno elaborare il progetto producendo un documento in cui sia contenuta la VISIONE IMPLEMENTATIVA, L'ARCHITETTURA DI SISTEMA, TUTTI I FRAMEWORK DI BASE E NON UTILIZZATI, LA SPECIFICA DEL SISTEMA ESB IN TERMINI DI ARCHITETTURA SOA DEL SISIR, TUTTI I FORMATI HL7 CDA2, TUTTE LE INTEGRAZIONI PREVISTE IN TEMINI DI ATTORI E TRANSAZIONI E TUTTI I CASI D'USO DESCRIVENTI TUTTI GLI SCENARI DI UTILIZZO

Per semplicità di esposizione, nel prosieguo sarà utilizzato il termine generico di fornitura, pur riferendosi in generale, alla pluralità di prestazioni descritte in precedenza.


1.4. ACRONIMI E DEFINIZIONI



Acronimo

Definizione

AA. SS.

Aziende Sanitarie

AGID

AGenzia per l’Italia Digitale

ANPR

Anagrafe nazionale persone residenti

ASL

Azienda Sanitaria Locale

ASM

Azienda Sanitaria provinciale di Matera

ASP

Azienda Sanitaria provinciale di Potenza

AUCR

Anagrafe Unica Contatti Regionale

CAD

Codice Amministrazione Digitale

CEA

Centro Esterno Accreditato

CISIS

Centro Interregionale per il Sistema Informatico ed il Sistema Statistico

CNIPA

Centro Nazionale per l’Informatica nella Pubblica Amministrazione

COC o CC

Complessità ciclomatica

CUP

Centro Unico di Prenotazione

DA

Ditta Appaltatrice

DWH

Data Warehouse

ESB

Enterprise Service Bus

FSE

Fascicolo Sanitario Elettronico

XX0

Xxxxxx Xxxxx Xxxxx

XX0 XXX0

XX0 Clinical Document Architecture Versione 2

HTML

HyperText Markup Language

ICAR

Interoperabilità e Cooperazione Applicativa tra le Regioni

IHE

Integrating the Healthcare Enterprise

J2EE

Java 2 Enterprise Edition

LOC

Lines Of Code

XXXXX

XXxxxxx Xxxxxx In Rete

MAC

Manutenzione Adeguativa e Correttiva

MdS

Ministero della Salute

MEF

Ministero dell’Economia e delle Finanze

MMG

Medici di Medicina Generale

MVC

Model View Controller

PLS

Pediatri di Libera Scelta

RIA

Rich Internet Application

RUPAR

Rete Unitaria della Pubblica Amministrazione Regionale

SA

Stazione Appaltante

SAML

Security Assertion Markup Language

SISIR

Sistema Informativo Sanitario Integrato Regionale

SISR

Sistema Informativo Sanitario Regionale

SLA

Service Level Agreement

SOA

Service Oriented Architecture

SPC

Sistema Pubblico di Connettività

SSO

Single Sign ON

SSR

Sistema Sanitario Regionale

XACML

eXtensible Access Control Markup Language

XML

eXtensible Markup Language

UML

Unified Modeling Language


2. PROGETTAZIONE E REALIZZAZIONE DI ADEGUAMENTI ARCHITETTURALI ED INFRASTRUTTURALI DEL SISIR

Il sistema informatico regionale per le componenti relative alla gestione delle degenze (AIRO), del centro unificato prenotazioni (CUP), degli ambulatori (ARCA) e dell’Anagrafe Assistiti, è basato su una architettura di tipo centralizzato MS-Terminal Server, ed una distribuzione nelle diverse aziende.

Tale infrastruttura, con l’aumentare dei processi concorrenti, anche in presenza di incrementate risorse di calcolo, ha evidenziato molte criticità, per i tempi medi di risposta, per i processi di stampa che spesso vanno in time-out oltre ad avere una durata media altissima e una gestione delle stampanti sul client inadeguata.

Tanto premesso, si richiede al concorrente di produrre, in sede di offerta, un dettagliato progetto di interventi che indichi tutte le componenti interessate ed il conseguente piano temporale di realizzazione.

Gli interventi devono tener conto delle realtà elaborative delle singole Aziende e della Regione e prevedere tutte le attività, revisione ARCHITETTURALE ed aggiornamenti necessari ad implementare il progetto proposto.

Il sistema realizzato avente le parti aggiornate e/o sostituite e/o integrate verrà verificato e sottoposto a collaudo sulla base degli SLA proposti dal concorrente in sede di gara o sulla base degli SLA richiesti.


2.1. STATO DELL’ARTE DELL’INFRASTRUTTURA ICT

Come già indicato, da tempo la Regione Basilicata


ha avviato progetti di informatizzazione dei principali settori delle Aziende Sanitarie e Ospedaliere e di adeguamento dei sistemi ICT nell’area sanitaria, al fine di raggiungere un miglioramento dei servizi offerti dalle strutture sanitarie pubbliche alla propria utenza. Gli obiettivi già raggiunti sono correlati:

 alla realizzazione del Sistema Informativo Sanitario Regionale (SISR) come insieme degli applicativi, connessi in rete tra loro, che gestiscono le principali aree sanitarie (prestazione specialistiche e farmaceutiche, medicina di base, anagrafe assistiti e medici, ricoveri ospedalieri, specialistica ambulatoriale, etc.);

 al collegamento telematico di tutte le strutture operanti nell’ambito del Servizio Sanitario Regionale (ospedali, servizi specialistici, medici di base, aziende sanitarie, Assessorato alla Sanità, etc.) grazie ad una rete regionale comune;

 alla realizzazione di un Sistema di Supporto alle Decisioni per il governo della spesa sanitaria, destinato ai dirigenti delle Aziende Sanitarie ed alla amministrazione regionale;

 alla creazione di alcuni servizi reali per l'utenza delle Aziende Sanitarie e Ospedaliere fruibili sul portale Basilicatanet.



Figura 1: La Regione Basilicata e le sue strutture sanitarie (con le ex ASL oramai divenute ASM e ASP)


Gli interventi realizzati in tali aree hanno inteso raggiungere un miglioramento dei servizi offerti dalle strutture sanitarie pubbliche adeguando il sistema informatico esistente alle nuove tecnologie informatiche e costruendo nelle AZIENDE le infrastrutture necessarie per lo sviluppo di servizi telematici per la sanità su scala regionale. Tutte le applicazioni prodotte nell’ambito degli interventi menzionati si basano, per la realizzazione dei necessari interscambi informativi, sulla connessione, attraverso la rete regionale, delle diverse strutture operanti nell’ambito del servizio sanitario regionale (presidi ospedalieri, distretti, sub distretti, medici di base e farmacie, etc.).


2.1.1. INFRASTRUTTURA DI TRASPORTO

La rete GIGARupar è stata disegnata ponendo particolare attenzione agli aspetti di trasporto dei servizi ed alle applicazioni erogate dalle pubbliche amministrazioni aderenti al progetto. La soluzione realizzata è una rete multilivello integrata nei servizi e nell’infrastruttura che:

 ha permesso un ottimo processo di migrazione nel passaggio dalla vecchia rete RUPAR all’innovativa rete GIGARupar,

 assicura servizi di trasmissione dati multimediali, di telefonia analogica, digitale, ed IP,

 consente di avere prestazioni di rete adeguate alle necessità attuali e future, grazie alla facile evoluzione della rete verso altissime capacità di banda su singola coppia di fibre e con supporto multi servizio,

 implementa un sistema di gestione semplice ed efficiente.

Inoltre, particolare attenzione è stata posta agli aspetti di continuità del servizio; infatti, tutte le piattaforme offerte rendono disponibili efficaci meccanismi di protezione e di affidabilità. Dal punto di vista architetturale la rete è organizzata a più livelli:

 Back-bone regionale ottico;


 Back-bone regionale Ethernet Routing Switching e reti metropolitane;


 Connettività GIGARupar verso Internet;


 Piattaforma per i servizi di IP-telephony e multimediali;


 Servizi di connettività al territorio.

Le modalità di connessione delle PAL alla community network della Regione sono le seguenti:


 Tramite collegamento in fibra all’anello ottico regionale;


 Tramite collegamento HDSL/ADSL che converge sull’anello ottico regionale;


 Tramite collegamento WiFi che converge sull’anello ottico regionale;


 Tramite collegamento con accesso dialup (ISDN) che converge sull’anello ottico regionale.

Link Logico

LinkFibra Ottica Fisico

( Xxxxxx Xxxxxx )

LA VEL LO

NORT EL ERS 8610

MON TEMILON E

ME LFI

NORT EL ERS 5510

R APO LLA

VE NO SA

NORTEL Optera5200

BARILE

G IN ESTRA

RIO NERO IN

V ULTU RE

MASCH IT O

PAL AZZO

S .

Sededi rigener azione Segnale

R

GE RVASIO

RI PACA NDIDA

BA NZI

RU VO DE L

AT ELL A

FO RE NZA

G ENZA NO DI XXXX XXX

MO NT E

RAP ONE

FI LI ANO

PESC OP AGA NO

ACE RENZ A

SAN FEL E

OPP ID O LUC ANO

I RSIN A

CA STELG RAN DE

AVI GL XXX X

PI ET RAG ALL A

M at er a Re gion e

BE LLA

CA NCEL LARA

XXXX XXXX NO

TOL VE

MATER A

B ARA GI ANO

R UO TI

P OTE NZA

VA GL IO D I

BASI LICATA

S C. H IRI CO

N UO VO

G RO TTO LE

T XXX XXXXX

GR ASSANO

B ALV ANO

*

PI CER NO

ALB ANO

D I LUC ANI A

VI ETR I DI

P OT ENZA

BR IND ISI

MO NTA GN A

MI GL IO NI CO

CALC XXX X

CAMPO MAG GIO RE

SAVO IA DI

L UCAN IA

PI GNO LA

TR IV IG NO

GAR AGU SO

MONT ESCA GLIO SO

TIT O

O LIV XXX

XXXX NO

SALA NDRA

CASTE LMEZZ ANO

S ANG ELO

SAT RIANO

AN ZI

PO MARI CO

L. E FRAT TE DILU CANIA

ABR IO LA

FE RRA NDINA

R

XXXXX XX

A CCET TUR A

P IE TRAP ERT OSA

SA N MA URO

FOR TE

SASSO DI

CASTA LDA

R

L AURE NZA NA

B XXXX LDA

C ALVE LLO

CI RI G LIA NO

C OR LETO

PE RTICAR A

STIGL IA NO

MA RSICO NU OVO

CRA CO

P ISTI CC I

G OR GO GL IO NE

XXXXXXX

V ETER E

V IG GIAN O

GUA RDIA

P ERTICA RA

P ATE RNO

ALI ANO

MO NTAL BANO J .

A RMENT O

TRA MUTO LA

MISSANE LLO

SCAN ZAN O J .

GR UMENT O NO VA

MO NTEMU RRO GA LLICCH I O

TUR SI

S A R. CAN GE LO

.

S MART IN O '

D AG RI

ROC XXXX VA

C OLO BRA RO

SARCO NI SPIN OSO

PO LICOR O

MO LIT ERN O

S . C HI RICO RA PAR O

RO TO NDE LLA

CASTR ON UOV O S

. A .

SENI SE

VAL SIN NI

NO VA SIRI

CASTE LSARA CENO

CAL VERA

LAG ON EGR O

SAN GIO RGI O

CAR BON E TEAN A CHI AR OMO NTE

LUCA NO

FARD ELLA

N OEP OL I

LATR ONI CO

R

N EMOL I

E PI SCOP IA

FRA NCA VIL LA S

*

CER XXXXXX

XXXXXX X

XXX RIA

S. CO STAN TI NO

ALB ANESE

C XXXXX XXX CIO SUP

S . SEVE RI NO

.

L UCAN O

S . PA OL O A LBAN ESE

T REC CHINA

CAST ELLU CCI O INF

.

MAR ATE A

V IG G XXX ELLO

TER RANO VA

D I PO LLINO

RO TO NDA



Figura 2: La GIGARupar e il territorio


La rete è realizzata da due livelli di connessione:


 Rete Primaria: realizzata in tecnologia ottica; ha come nodi di interconnesione gli ospedali di CROB, Melfi, Venosa, San Carlo, Villa D'Agri, Xxxxxxxxx, Matera, Policoro e Lagonegro; inoltre, sulla rete primaria sono attestate l'Università di Basilicata Macchia Romana, Rione Francioso e Matera, le sedi regionali di Potenza e Matera, la sede del comune di Potenza Piazza Sedile;

 Rete Secondaria: realizzata con tecnologie miste WIFI e wired che si dirama a partire dai nodi primari della rete, in particolare connette l'ospedale di Chiaromonte, l'ospedale di Xxxxxx e l'ospedale di Pescopagano.

La rete è interconnessa con il Sistema Pubblico di Connettività (SPC) e con la rete internet.


2.1.2. SINTESI SULLA DISTRIBUZIONE DELLE MACCHINE SERVER PRESSO LE STRUTTURE

Di seguito, viene riportato il quadro di sintesi sulla distribuzione delle macchine server (in seguito brevemente chiamate server) presso le strutture sanitarie. La distribuzione riguarda la vecchia organizzazione territoriale delle ASL in cinque aree. Si può facilmente riportare la distribuzione alle attuali due ASL, conoscendo che l’ASL di Potenza raggruppa ASL 1, ASL 2 e ASL 3, invece l’ASL di Matera raggruppa ASL 4 e ASL 5.

Tabella 1: Elenco delle applicazioni software e dei loro utilizzatori


AZIENDA/APLICATIVO

ASP

ASM

S.Carlo

CROB

REGIONE

Centro Prenotazione

Anagrafe

l'azienda si è dotata

Singolo Server


Windows(R) Server 2003 R2, Enterprise Edition MS-SQL Server 2000

Unico Cluster


6 server front end (Windows Server 2003) + 2 server back-end (Windows Server 2003 -

SQLServer 2005) +

3 server di integrazione Web Services (Etichette Laboratorio Analisi, Referti RIS-Pacs ESAOTE,

Pagamento ticket e CUP Online)

Unico Cluster composto da due Front end Due Business e due Data Base Bckend


Sistema operativo Windows Server 2003 enterpise escluso Un front end con window s 2008 e MS SQL

Server 2005




di un blade di cui si


allegano le


caratteristiche. Ha


4 lame, 72 GB di


ram, 2 Intel® Xeon®


X5650 (6 core, 2.66


GHz, 12MB L3,


95W) x lama,


Windows 2008


server datacenter,


1 SQL Server 2008


R2 Enterprise


(*)per tutte le


applicazione


attivate

ARCA

(*)

no

(*)

(*)



AIRO

(*)

Cluster Load Balancing composto da 2 server Microsoft(R) Windows(R) Server 2003, Standard Edition

MS-SQL Server 2005

(*)

(*)



BASMED







XXX

(*)

(*)

(*)

(*)



XXX

(*)

(xxxx Xxxx)

(*)

(*)



LUMIR


Singolo Server


Windows(R) Server 2003 R2, Enterprise Edition MS-SQL Server 2005 standard

1 server virtualizzato (Windows Server 2003)

Singolo Server


Windows(R) Server 2003 R2, Enterprise Edition MS-SQL Server 2005 standard



NSIS







PIC







Reporting







TelemedBas







Tessera Sanitaria








Tutti i nodi periferici inoltre convergono sul nodo centrale dipartimentale, dove è presente un sistema che replica i dati presenti a livello delle strutture, ma che sono anche di interesse regionale. Un quadro descrittivo della dotazione centrale viene riportato di seguito:

• N.1 Server database avanzato quadriprocessore IBM con 7 HD da 146 GB

• N. 2 Server database biprocessore IBM con 2 HD da 36 GB e 5 HD da 146 GB

• N. 2 Server web biprocessore IBM con 4 HD da 36 GB

Occorre comunque considerare che la situazione attuale è in evoluzione, di conseguenza sarà cura delle ditte concorrenti verificare i dati di distribuzione sopra riportati attraverso adeguato sopralluogo presso le Singole Aziende e il Dipartimento. Gli attestati di sopralluogo, rilasciati da ciascuno Responsabile CED delle Aziende e dal Funzionario regionale devono essere allegati alla documentazione amministrativa.

Nella Tabella 2 si elencano i principali sistemi applicativi associati ai relativi utilizzatori


Tabella 2: Elenco delle applicazioni (ANNERITI) software e dei loro utilizzatori


Applicativi

Aziende

ASP

ASM

X. Xxxxx

XXXX

Anagrafe



ARCA




AIRO


BASMED



CEA



CUP


NSIS

LUMIR

PIC

Reporting

TelemedBas

Tessera Sanitaria

GSO Flussi Ospedalieri

Repository Documentazione Clinica

ARCO (Gestione Anagrafica Fascicoli integrazione AIRO)




Nella Tabella 3 si elencano, a titolo puramente informativo, gli utenti che risultano registrati, nel tempo, per l’accesso alle principali procedure:

Tabella 3: Numero di utenti



Numero utenti


Sistema Software

Modalità di Fruizione

Call

Center Regionale

ASP

Potenza

ASM

Matera

A.O. San Carlo

PZ

IRCCS

Crob Rionero


Totali

Anagrafe Unica Popolazione

Assistita

Termina Server/ Client Server



122


73




ARCA

Terminal Server


129

51

528

220


AIRO

Terminal Server


000

00

0000

220


BASMED

Client Server







CEA(*)

Terminal Server

60

5

5




CUP

Terminal Server/WEB


1000

659

1252

220


NSIS

WEB Application


10



10


Lumir

WEB Application







PIC

Terminal Server





220


Reporting

Terminal Server







TelemedBas

WEB Application







Tessera Sanitaria

Terminal Server


150

344


10


ITM Brocker

Terminal Server





220


ARCO

Terminal Server





10









(*)Sono presenti 60 centri accreditati regionali.


3. REQUISITI TECNICI

3.1. REQUISITI TECNICI E TECNOLOGICI PER I SISTEMI INFORMATICI APPARTENENTI AL SISIR

Nell’ambito degli sviluppi software realizzati per la messa in esercizio dei Progetti, per gli interventi di manutenzione evolutiva (MEV), il Sistema dovrà essere integrabile secondo i paradigmi SOA su canale ESB con tutte le altre applicazioni sanitarie ed amministrative, anche non di proprietà della Regione, funzionanti presso le Aziende del SSR e la Regione.


3.1.1. GESTIONE DELLA SICUREZZA

 Sicurezza di accesso: il sistema deve:

conformarsi ai sistemi di sicurezza (e.g. firewall), normalmente adottati dalle Aziende Sanitarie o dalla Regione, relativi ai livelli di protezione;

integrarsi e conformarsi ai sistemi di autenticazione e di autorizzazione informatica adottati dalla Regione;

essere eventualmente dotato di un meccanismo di autenticazione unico per tutte le componenti disponibili (Single Sign On) e che permetterà di accedere a tutte le funzionalità associate allo specifico profilo utente in linea con le indicazioni del D.Lgs 196/2003;

prevedere tutte le funzioni atte a facilitare verifiche periodiche relativamente agli accessi eseguiti dagli utenti e allo stato delle abilitazioni (accounting); gestione unica ed univoca dei profili di abilitazione per i singoli utenti. Gli accessi verranno registrati e storicizzati su un log consultabile dagli autorizzati e, in caso di accessi ai dossier/fascicoli da ogni singolo cittadino assistibile (in questo caso, ovviamente, solo per gli accessi ai dati sanitari relativi) consultabile dall'assistito.

 Sicurezza dei dati:

il sistema deve prevedere controlli che garantiscano la sicurezza dei dati anche in caso di intrusioni sulle banche dati, oppure negli strumenti di comunicazione e il ripristino delle informazioni contenute ad uno stato consistente;

la soluzione applicativa deve essere in grado di garantire l’uso di strumenti di firma elettronica e crittografia che permettano di dare validità legale ad alcuni documenti (e.g. Referti Strutturati e non), di interfacciarsi con sistemi di archiviazione/conservazione a norma e di proteggere la trasmissione di eventuali dati sensibili secondo le indicazioni e

modalità contenute nel d.lgs. 196/2003 (Codice in Materia di Protezione dei Dati Personali), suoi allegati e successive modifiche.

Sicurezza dei dossier sanitari prodotti dalle singole strutture sanitarie, del fascicolo sanitario elettronico del Cittadino. Capacità di ripristino dei servizi con soluzioni di continuità e ripristino dei dati in caso di disastri ed in ottemperanza alle indicazioni contenute nella DCR n.190/2011 della Regione Basilicata “Regolamento di servizio per la consultazione dei documenti clinici: istituzione e gestione del fascicolo sanitario e del dossier sanitario elettronico nel Servizio Sanitario Regionale”.


3.1.2. ACCESSIBILITÀ

Requisiti di accessibilità per tutti i progetti ed evoluzioni:


 accessibilità e libera utilizzabilità della struttura dati e disponibilità della documentazione a tal fine necessaria. Relativamente alle applicazioni oggetto del contratto, dovranno essere fornite inoltre le informazioni necessarie alla realizzazione di tutte le operazioni di interrogazione, statistiche, stampe, interfacce di visualizzazione e aggiornamento, eseguibili direttamente dall'azienda o anche affidate a terze parti; la ditta sarà tenuta a rilasciare tutte le informazioni necessarie a favorire l'integrazione dei sistemi software in manutenzione con i sistemi aziendali;

 conformità agli standard di accessibilità ed usabilità secondo quanto previsto dalla Legge 9 gennaio 2004, n. 4;

 utilizzo di standard aperti, conosciuti e non proprietari di rappresentazione dati, trasmissione dati, documentazione software, sviluppo software, progettazione software e test software. Ovvero, tutti i prodotti realizzati dai “progetti” possono essere riusati liberamente senza limitazioni alcuna sulla proprietà intellettuale, nel numero degli utenti e nel tempo da parte di altri soggetti pubblici o privati. Tutti i componenti delle architettura di sistema, le componenti della architettura realizzate e le componenti di base (sistemi operativi, librerie, frameworks, DBMS, linguaggi di programmazione) possono essere riusate senza alcuna limitazione nel numero e nel tempo e, se applicabile, devono consentire l'interoperabilità.


3.1.3 INDIPENDENZA DALLA PIATTAFORMA E FRUIBILITÀ ANCHE DA DISPOSITIVI MOBILI

Requisiti di riuso ed indipendenza per tutti i progetti ed evoluzioni:


 un sistema scalabile e riusabile senza limitazione alcuna nel numero degli utenti, nella tipologia, nelle architetture, nei formati dati e nel tempo. Sono preferibili e saranno oggetto di valutazione architetture orientate al WEB 2.0 di tipo RIA, che non prevedano installazioni sui singoli dispositivi del fruitore/utilizzatore, fruibili anche da dispositivi mobili.


4. PROGETTI

4.1. PREMESSA METODOLOGICA PER I PROGETTI

Nella presente documentazione tecnica di gara verranno presentati un insieme di progetti che la stazione appaltante ritiene di realizzare entro i primi due anni dall’avvio del contratto con la formula “chiavi in mano”, comprensivi cioè del mix di attività/professionalità necessarie alla realizzazione di software, installazione, addestramento all’uso/formazione, collaudo, avvio, supporto al tuning, supporto operativo e manutenzione correttiva, adeguativa, migliorativa fino al termine del contratto e garanzia di conformità alla vigente legislazione in materia di protezione dei dati personali. Per comodità di esposizione dei requisiti, si procede ad una trattazione separata, l'obbiettivo primario rimane comunque quello di avere una architettura del sistema informativo sanitario integrato e indipendente, aperto, intrinsecamente sicuro, che enfatizzi il concetto di Hub&Spoke delle Informazioni Clinico/Sanitarie e Gestionali disaccoppiando al massimo i produttori di dati dai consumatori degli stessi.

Per ciascun progetto, se applicabile, è necessario prevedere una fase di parallelo con i sistemi esistenti in produzione di almeno 3 mesi.

Occorre precisare che i criteri di qualità e documentazione del software sviluppato e previsti, per la fornitura dei servizi di MEV, devono essere comunque rispettati. Gli interventi previsti per ciascuno dei progetti indicati devono includere e documentare le attività di analisi, sviluppo, installazione, assistenza all’avvio e redazione di manualistica utente. L’attività di analisi potrà includere anche incontri diretti con gli utenti dell’intero sistema sanitario regionale ivi compreso il personale delle Aziende Sanitarie. Tutta la documentazione tecnica, ad eccezione della documentazione ad uso degli operatori, deve essere sviluppata secondo le indicazioni del manuale di qualità e relative procedure e certificazioni della DA, deve essere conforme agli standard regionali reperibili alla uri xxxx://xxx.xxxxxxx.xxxxxxxxxx.xx/xxxxxx/xxxx/xxxxxx/xxxxxxxxxx.xxx?xxxx000000&xxxxx000000&xxxxxx0 e come contenuto minimo deve includere:

 Documento di analisi, modellazione e specifica dei requisiti e criteri di Uscita contenente al minimo:

1. Determinazione dei Requisiti;

 Raccolta;

 Identificazione;

 Classificazione;

 Requisiti non Funzionali;

 Requisiti Funzionali;

2. Analisi e Specifica dei Requisiti;

 Modelli Di Casi D’Uso;

 Diagrammi Di Casi D’Uso;

 Diagrammi di package di casi d’uso;

 Descrizione di Casi d’uso;

 Scenari;

 Estensioni;

3. Analisi di Consistenza dei requisiti

 Documento di Analisi e Disegno Logico e criteri di uscita composto al minimo da:


1. Diagramma Delle Classi


2. Diagrammi di sequenza;


3. Diagramma di Collaborazione;


4. Diagrammi di Transizione;


5. Diagrammi di Attività


6. Diagrammi di Interazione;


 Documento di Analisi e Disegno Fisico e criteri di uscita;


1. Diagramma delle Componenti;


2. Diagramma di Distribuzione


 Collaudo e relativi criteri di uscita:


1. Piano dei test di unità, Piano dei test di copertura (White BOX), Piano dei Test Funzionali (Black Box), Piano dei Test di Integrazione, Piano dei Test di Sistema, Piano dei Test di Carico, Piano dei Test di Usabilità;

2. Lista anomalie riscontrate per ogni iterazione ed azioni di uscita;


 Schema dei Dati completo di:


1. Schema Concettuale;

2. Vincoli non esprimibili nello schema;


3. Volume dei dati;


4. Dizionario dei dati


5. Progetto Fisico


6. Vincoli Referenziali e di Derivazione;


 Manuali di installazione;


 Manuali d’uso;


Saranno inoltre redatti manuali per l’utente e documentazione per l’amministrazione e d’installazione del singolo applicativo e dell’ambiente di base e verticale.

Tutta l’attività inerente la realizzazione dei Progetti deve essere eseguita dalla DA in proprie sedi ed utilizzando un proprio ambiente e le proprie procedure di gestione del ciclo di vita e della qualità del software provvedendo ad aggiornare in maniera sincrona il sistema di gestione del ciclo di vita e della qualità installato dalla DA ed in esercizio presso la Regione.

Le modalità di esecuzione del servizio di realizzazione progetti sono le seguenti:


A seguito della firma del contratto, la DA presenterà, entro un massimo di 60 giorni lavorativi, un progetto di dettaglio conforme a quanto indicato in offerta, per ciascuno dei progetti richiesti saranno evidenziati la stima del costo, ovvero il numero di casi d’uso da realizzare, ed il numero dei prototipi rilasciati prima della messa in esercizio dei sistemi. Il progetto includerà altresì la calendarizzazione dettagliata delle attività giornaliere e del personale impiegato per l’espletamento delle attività. La stima del costo delle singole attività risulterà dai casi d’uso calcolato secondo le modalità indicate nel paragrafo “Metodo di Stima dell'impegno MEV”. La calendarizzazione dovrà prevedere l’inizio delle attività entro un tempo massimo di 60 giorni lavorativi successivi alla consegna dei progetti di dettaglio alla SA e l’impegno continuativo delle risorse indicate e necessariamente terminare con il collaudo dei progetti entro 24 mesi dalla stipula del contratto. Le

attività di installazione e redazione di relativa documentazione non saranno oggetto di quotazione né genereranno oneri aggiuntivi.

In relazione alla manutenibilità/modificabilità e qualità del codice sviluppato per la realizzazione dei singoli PROGETTI, la DA, allo scopo di dimostrare la qualità delle realizzazioni, è obbligata a produrre tutta la documentazione nella quantità e nelle tempistiche previste nel paragrafo “Manutenzione Evolutiva Software del SISIR (MEV)”.

Nel seguito si riportano i progetti che la stazione appaltante intende realizzare e per i quali è richiesta la formulazione di apposita scheda, in sede di presentazione dell'offerta tecnica, di progetto che riporti al minimo e non esclusivamente:

La descrizione dell’intervento.

Le componenti del sistema informativo sanitario interessate.

La descrizione funzionale di massima che riporti, quale informazione minimale, gli elementi del sistema informatico sanitario regionale che verranno variate, cancellate, sostituite e/o prodotte ex novo.

I tempi di attuazione.

Le fasi di attività e, per ognuna, gli impieghi di risorse umane e materiali.

I requisiti, i prerequisiti di realizzazione e le risorse della SA richieste per la piena attuazione.

Il numero dei prototipi rilasciati prima di procedere al collaudo ed esercizio del sistema.

Le metodologie di verifica della usabilità del sistema con i criteri di uscita.


Per la realizzazione dei progetti ogni fornitore ha facoltà di riutilizzare quanto già in possesso della stazione appaltante ovvero di integrarlo o sostituirlo in toto o in parte per la realizzazione di quanto richiesto nel rispetto dei vincoli architetturali, di riutilizzo/riuso e di formati dati aperti e documentati.

In ogni caso il raggiungimento degli obiettivi progettuali nei tempi indicati sarà a totale carico della DA.

Dopo la firma del contratto, per l’avvio dei progetti la stazione appaltante, secondo il piano presentato dal fornitore, dopo aver ricevuto il documento con l’analisi di dettaglio e, in contraddittorio con il fornitore, determinerà le eventuali variazioni introdotte da fattori esterni al progetto.

La stazione appaltante non approverà variazioni che dovessero essere indotte da fattori già presenti/conosciuti al momento della redazione dell’offerta, fatto salvo per quelle situazioni ritenute rilevanti dalla SA e previo accordo con la stessa.

Qualora il progetto dovesse discostarsi significativamente rispetto a quanto proposto in sede di offerta, atteso che i progetti non possono subire rialzi di prezzo, la stazione appaltante ha facoltà di non realizzare il singolo progetto decurtando per intero la parte economica prevista per la sua realizzazione.

Con la formale approvazione del documento di progetto di dettaglio il progetto si intende avviato e verrà realizzato secondo i tempi previsti nel progetto offerta e non oltre 24 mesi successivi alla firma del contratto.

La stazione appaltante si riserva la facoltà di convertire il budget previsto per il singolo progetto non realizzato in MEV.

I progetti previsti sono:


I. INTERFACCIA UNICA S.I.S.I.R. ADEGUAMENTO T.S.E;


II. DATA WAREHOUSE FLUSSI SANITARI;


III. ANAGRAFE UNICA ASSISTITI REGIONALI E ANAGRAFICA UNICA CONTATTI;


IV. DEMATERIALIZZAZIONE DELLE PRESCRIZIONI OSPEDALIERE E MMG/PLS;


V. ADEGUAMENTO ARCHITETTURALE DELLE PROCEDURE IN MANUTENZIONE;


VI. SISTEMA PER IL TRACCIAMENTO DELLA QUALITA' DEL SISIR PER LA GESTIONE DEL CODICE SORGENTE, DEL PROGETTO, DEL VERSIONAMENTO SISTEMI SOFTWARE/HARDWARE, DELLA DOCUMENTAZIONE E MANUALISTICA.

per ognuno di essi nelle sezioni che seguono viene riportata una breve descrizione, si precisa che l'obbiettivo della presente richiesta è di realizzare un sistema unico integrato, disaccoppiando i produttori di informazione dai successivi consumatori.


4.2 INTERFACCIA UNICA S.I.S.I.R. E ADEGUAMENTO IHE

Nel rispetto della sicurezza dei dati e della privacy, nonché di scambio di informazioni tra applicazioni, il Sistema Informativo Sanitario Integrato Regionale, si deve basare su una architettura aperta costituita da una serie di componenti principali che implementano profili di integrazione standard IHE basati su DOCUMENT REPOSITORY e DOCUMENT REGISTRY unico Aziendale e Regionale. Di seguito si elencano a titolo esemplificato alcuni elementi insieme alle loro caratteristiche fondamentali appartenenti alla famiglia ISO/TC 215.

1. Un repository e registry unico aziendale integrato in grado di gestire tutte le informazioni cliniche ed organizzative, con possibilità di mantenere una certa storicità, conforme allo standard internazionale ISO-EN 12967 “Health Informatics – Service Architecture” (HISA) che supporti i profili IHE nativamente o incorporare componenti che lo implementi che implementino i profili/attori Cross-Enterprise Clinical Documents Share (XDS.b per i Document Consumer, Document Registry, Document Repository, Document Source); Audit Trail and Node Authentication (ATNB per gli attori Audit Record Repository, Source Node, Secure Application).

2. Possibilità di poter estrapolare, dai vari applicativi, dati a supporto dei processi clinici ed organizzativi nei vari settori. Queste applicazioni, se non direttamente basate sul modello HISA, devono essere in grado di:

 prevedere funzioni di “export” parametrizzabili da importare nei “Repository” aziendali;


 utilizzare in maniera spinta classificatori (es. ICD9, ICD10, LOINC, AIC, ecc.);

3. per assicurare la continuità dei processi clinico-assistenziali con sistemi di terze parti, il sistema, nel suo complesso e nelle varie aree applicative, deve essere in grado di interagire mediante messaggi conformi allo standard HL7.

4. per poter acquisire immagini dal PACS e consentirne la visualizzazione, il sistema deve prevedere le interfacce DICOM;

5. per lo scambio tra enti dei dati clinici strutturati vengono seguite le prescrizioni di ISO-EN 13606 “Eletronic Health Record Communications”;

6. i documenti clinici (referti, lettera di dimissione, ecc.) possono essere scambiati e gestiti nel formato standard ANSI/HL7 “Clinical Document Architecture” (CDA) versione 2 firmati digitalmente.

L’applicazione di tali standard riconosciuti a livello italiano, europeo e mondiale (UNI, CEN, ISO, HL7) permetterà così notevoli vantaggi quali:

 l’utilizzo di prodotti/servizi forniti da produttori differenti;


 la garanzia di poter trattare e regolamentare dati sensibili;


 la possibilità di dialogo verticale, fra enti gerarchicamente dipendenti fra loro, e orizzontale, tra enti/attori che su specifiche tematiche necessitano di trasferire informazioni nel rispetto delle vigente normativa in materia di protezione dei dati sanitari personali.

Tutto il sistema di gestione clinica pazienti si colloca nell’ambito del Sistema Informativo Sanitario della Regione Basilicata ed in particolare al sistema ospedaliero/territoriale con cui dovrà essere perfettamente integrato ed integrante. Nello specifico deve configurarsi come un sistema informativo integrato e trasversale ai diversi processi e regimi di cura divenendo, nel tempo, il riferimento informativo clinico-sanitario avente quale fulcro il paziente.

I requisiti minimi da soddisfare sono:


 Completa aderenza agli standard ed alla normativa in tema di sanità elettronica;


 Completa integrazione con il repository e registry unico aziendale;


 Aderenza alle linee guida relative alla digitalizzazione delle cartelle cliniche ospedaliere con ottimizzazione del workflow medico-infermieristico all’interno dei diversi percorsi di cura di un paziente;

 Raccolta di tutte le informazioni cliniche di un paziente, soddisfacendo sia gli aspetti di privacy e continuità della disponibilità dei dati, sia gli aspetti medico-legali;

 Completa integrazione con il Sistema Informatico Ospedaliero con il quale deve condividere tutte le informazioni di carattere clinico dando la possibilità di integrarle;

 Alto livello di personalizzazione dei dati clinici in modo da poter efficacemente implementare le informazioni relative a specifici ambiti quali ad esempio oncologia, cardiologia, reumatologia, etc.

 Gestione del rischio clinico.


 Ulteriori funzionalità del sistema, quali, a titolo di esempio:


 Fornire una base informativa finalizzata a garanti, re continuità di cura al paziente, documentando il quadro clinico, il percorso e i risultati conseguiti nel corso della cura, sia in un episodio di ricovero che in un episodio ambulatoriale.

 Costituire un mezzo di comunicazione tra tutti gli attori responsabili nel tempo dell’assistenza al paziente, che possono così, grazie alle informazioni riportate, comunicare e assisterlo con continuità.

 Facilitare l’integrazione di competenze multi professionali nel processo diagnostico- terapeutico, favorendo la costituzione di un’informazione clinica completa e organica.

 Consentire la tracciabilità delle diverse attività svolte, in termini di responsabilità delle azioni intraprese dal personale sanitario, la loro cronologia, le modalità d’esecuzione delle stesse.

 Supportare tutte le attività e integrare dati provenienti da diverse fonti, interne ed esterne, e i processi di diagnosi e di erogazione delle cure.


4.2.1 CARATTERISTICHE FUNZIONALI MINIME

La gestione clinica/ambulatoriale dei pazienti dovrà essere organizzata in sezioni che consentono di raccogliere l’insieme di dati clinici/ambulatoriali comuni a tutte le articolazioni ospedaliere/territoriali e un insieme di dati specialistici propri di ogni disciplina. Le sezioni, sia dal

punto di vista dell’interfaccia utente sia dal punto di vista delle informazioni in esso contenute, dovranno essere personalizzabili a seconda delle esigenze dei singoli reparti e dei singoli utenti mediante un portale di amministrazione, nel quale l’utente potrà inserire e impostare i tipi di dati di cui necessita. Nello specifico, la gestione clinica dovrà consentire o interfacciare sistemi in grado di gestire:

al termine dell’episodio clinico, la chiusura della cartella, seguendo una sequenza ordinata di operazioni: verifica che tutte le informazioni definite come obbligatorie siano presenti, presentazione di un riepilogo dei dati inseriti e delle operazioni eseguite dall’utente durante la stesura dei documenti, creazione del documento finale con apposizione di firma digitale, stampa da consegnare al paziente e archiviazione della versione digitale sul repository e registry clinico aziendale;

di gestire numerosi tipi di informazioni cliniche tra cui: inquadramento clinico, valutazione infermieristica, trasferimento tra reparti e dimissioni, diario della degenza medico e infermieristica, rilevazione dei parametri vitali, scheda nutrizionale, piano di riabilitazione e altre informazioni e l’apposizione di firma digitale e marcatura temporale ove l'azienda abbia l'infrastruttura e i servizi attivi;

l'acquisizione dei documenti cartacei in formato digitale e loro conservazione sostitutiva a norma.

E’ indubbio che il trend evolutivo della sanità, nel suo complesso, è orientato verso una gestione che si avvale sempre di più di processi supportati da documentazione digitale.

L’obiettivo del passaggio da una sanità “analogica” ad una completamente digitale “Patient- Centric” non è né semplice né tanto meno raggiungibile nel breve periodo, in quanto per poter evolvere completamente, oltre a dover adeguare l’infrastruttura tecnologica risulta necessario aggiornare i processi e, conseguentemente, rivedere l’organizzazione.

Per l'enunciate ragioni il completo passaggio al “digitale” dovrà necessariamente avvenire per fasi successive avendo cura di mantenere-adeguare i sistemi informatici affinché cooperino e conferiscano le informazioni clinicamente rilevanti ad un “contenitore strutturato” che è stato denominato “Repository-Registry”.

Ad oggi i Repository nelle diverse aziende sono già costituiti ma possono non essere unici e, soprattutto, non omogenei, non aggiornati o semplicemente non adeguatamente documentati per consentirne un utilizzo immediato.

Ulteriore requisito è quello di unificare ed uniformare i Repository ed attivare il Registry verso un unico modello di istanze per azienda e regione attribuendo allo stesso specifici standard di conferimento e reperimento delle informazioni.

Ciò renderà possibile :

 la redazione di un unico documento su scala regionale sulle specifiche di interfaccia al repository e registry;

 determinare un unico punto per il conferimento delle informazioni cliniche;


 la realizzazione di un’unica banca dati sia per i documenti firmati digitalmente che non firmati nei formati, PDF, HL7-CDA2, DICOM, etc;

 l’univocità dei documenti informatici e la sicurezza di accesso indipendente dall’area informativa richiedente: cartella clinica elettronica, dossier sanitario, referti on-line, Fascicolo Sanitario Elettronico, expertise sanitario/consulenze/II opinion;

 l’uniformazione delle regole di accesso e consultazione;


 l’univocità della correlazione al paziente.


Le funzionalità richieste si inseriscono in una più facile integrazione della documentazione clinica/ambulatoriale Aziendale con il sistema di gestione del FSE e gli eventuali sistemi regionale/nazionale di gestione delle identità personali dei cittadini residenti.

Per consentire, nell’immediato, una alimentazione del repository anche dai documenti cartacei, è richiesto nel progetto l’inserimento di apposite funzionalità che consentono la digitalizzazione, su richiesta del cittadino, di documentazione cartacea e su archiviazione e conservazione a norma per un loro utilizzo nell’area dell’archivio cartelle cliniche e fascicolo sanitario elettronico.

Il progetto che si andrà a sviluppare, oltre a tenere conto di quanto innanzi richiesto, dovrà indicare le modalità e i metodi per il suo esercizio, rispettando le specificità preesistenti nelle Aziende Sanitarie ed in Regione.


4.3 DATA WAREHOUSE DEI FLUSSI SANITARI

Nell’ottica di ottemperare alle direttive del Ministero della Salute relative al progetto NSIS, e per creare un sistema di programmazione che si basi su analisi delle serie storiche dei dati economici e sanitari, è fondamentale attivare/gestire un data Warehouse di “Gestione Flussi NSIS” per automatizzare la produzione dei file per i flussi informativi consentendo, inoltre, la visualizzazione e la stampa dei file prodotti da parte dei referenti responsabili presso le Aziende ed il Dipartimento Politiche Della Persona contribuendo a realizzare e manutenere un sistema DWH dei flussi Regionali.

Per tutti i datamart creati deve essere gestita l’esportazione dei dati in formati aperti (xml, csv, ODF etc.) con la gestione centralizza degli accessi e della profilazione utenti, deve essere prevista la gestione separata del dato “sanitario” dal dato assistito nel rispetto delle prescrizioni previste e indicazioni derivanti dal D.Lgs n. 196/2003 e ss.mm.ii. e D.Lgs n. 82/2005

4.3.1Flussi NSIS e verso Regione

Il progetto “Gestione Flussi NSIS” deve mirare a facilitare la produzione dei file relativi ai flussi richiesti dal Ministero della Salute e Ministero delle Finanze che trovano il punto di raccolta nel sistema informativo NSIS. La proposta come requisito primario deve creare un DATA WAREHOUSE regionale dei flussi offrendo, ai referenti responsabili presso le Aziende ed il Dipartimento Politiche della Persona, tutte le funzionalità per produrre in automatico i flussi di verificare la correttezza, per costruire indicatori di supporto alla programmazione sia aziendale che dipartimentale.

Per brevità di esposizione, in seguito sono indicati solo alcune funzionalità ritenute indispensabili, in ogni caso sarà valutata la completezza del sistema offerto in generale:

 automatizzazione della produzione dei file per i flussi per i quali esistono nelle Aziende Sanitarie procedure informatizzate che gestiscono le relative informazioni;

 modifica e completamento delle informazioni reperite dalle procedure informatizzate presso le Aziende Sanitarie e ritorno sui dati aziendali;

 produzione esportazione in formati aperti dei file;


 invio al sistema NSIS nelle modalità richieste.

In particolare l’obiettivo deve essere di:


 raccogliere e monitorare in un unico punto tutti i flussi da inviare, avendo così l’immediata visibilità e disponibilità dei singoli flussi e delle relative scadenze, superando l’attuale frammentazione sia tecnologica che organizzativa derivante dalla presenza di diversi sistemi;

 controllare, validare e certificare digitalmente il contenuto dei flussi sulla base di quanto previsto dalle regole imposte dai tracciati regionali/ministeriali; sarebbe auspicabile poter parametrizzare tali regole;

 rispettare la tempistica di raccolta ed inoltro dei flussi; possibilità di invio di msg e/o alert.;


 caricare in maniera automatizzata i dati sul sistema NSIS nazionale;


 elaborare, anche in maniera autonoma indicatori ritenuti utili alla programmazione e/o verifica degli obbiettivi.


Il sistema informativo per la gestione dei flussi NSIS deve produrre, mediante funzioni automatizzate, flussi dati che andranno ad alimentare il sistema NSIS nazionale, da applicativi preesistenti quali AIRO (per la gestione dei ricoveri), CUP (Centro Unificato prenotazioni), CEA (Centri Esterni Accreditati) e Sistema Contabile (per la gestione del magazzino) Anagrafe e altro.


CUP

AIRO

CEA

Banca Dati dei Flussi

ARCA




Sanità


Intranet


Tramite il progetto NSIS il Ministero della Salute raccoglie informazioni gestionali ed economiche e di monitoraggio dai vari utenti del sistema al fine di eseguire statistiche sui livelli di servizio.

Per l’alimentazione del sistema NSIS da parte delle Aziende Sanitarie ed ospedaliere sono stati predisposti i seguenti flussi informativi:

Modello FLS.11 dati di struttura e di organizzazione delle Unità Sanitarie Locali (Anagrafe Sanitaria - MMG)

Modello FLS.12 convenzioni nazionali di Medicina e di Pediatria (Anagrafe Sanitaria - MMG) Modello FLS.18 assistenza sanitaria colletiva in ambiente di vita e di lavoro

Modello FLS.21 assistenza sanitaria di base (Anagrafe Sanitaria)


Modello STS.11 dati anagrafici delle strutture sanitarie (CUP, AIRO, CEA)


Modello STS.14 apparecchiature tecnico biomediche di diagnosi e cura presenti nelle strutture sanitarie extraospedaliere (Procedura Inventario)

Modello STS.21 assistenza specialistica territoriale – attività clinica, di laboratorio, di diagnostica per immagini e di diagnostica strumentale (CUP – TabCentr, AIRO, CEA)

Modello STS.24 assistenza sanitaria semiresidenziale e residenziale

Modello RIA.11 istituti o centri di riabilitazione ex art.26 legge 833/78 Modello HSP.11 dati anagrafici delle strutture di ricovero (AIRO - PS)

Modello HSP.11 bis dati anagrafici degli istituiti facenti parte della struttura di ricovero


Modello HSP.12 posti letto per disciplina delle strutture di ricovero pubbliche ed equiparate (AIRO

- PS)


Modello HSP.13 posti letto per disciplina delle case di cura private


Modello HSP.14 apparecchiature tecnico biomediche di diagnosi e cura presenti nelle strutture di ricovero

Modello HSP.16 personale delle strutture di ricovero equiparate alle pubbliche e delle case di cura private

Modello HSP.22 bis posti letto delle strutture di ricovero pubbliche ed equiparate (AIRO - PS) Modello HSP.23 attività delle case di cura private

Modello HSP.24 day-hospital, nido, pronto soccorso, sale operatorie, ospedalizzazione domiciliare, nati immaturi (AIRO - PS)

Altri flussi di consumo/monitoraggio prodotti ai fini del rispetto degli adempimenti Ministeriali, riparto dei fondi per le Aziende e/o accordi interregionali:

 Assistenza Domiciliare Integrata


 Attività del pronto soccorso


 Centri di Costo dei Farmaci


 Distribuzione Diretta Farmaci


 Dispositivi medici


 Anagrafe Soggetti Esenti/Esenzioni


 Assistenza Ospedaliera


 Farmaci ospedalieri


 Farmaceutica Territoriale


 Farmaceutica File F


 Prestazioni Termali


 Trasporti Sanitari

 Medicina Territoriale


 Assistenza per i Disturbi del Comportamento Alimentare


 Mobilità Sanitaria Interregionale


 Personale


 Psichiatria territoriale


 Schede di Dimissione Ospedaliera


 Schede di Morte


 Schede di Prestazioni di Specialistica Ambulatoriale


 Tempi di Attesa per le Prestazioni di Specialistica Ambulatoriale/Sospensione Attività


 Emergenza Urgenza 118


 Flusso Assistenza Residenziali/Semi-residenziale


 Consumi Dispositivi Medici


 Flusso Hospice


 Sistema Informativo Nazionale Dipendenze


 Screening


 Contatti anagrafici


 Eventi Sentinella

Per completezza nella tabella sono indicati tutti i flussi nazionali gestiti o le attività di controllo svolte con l'eventuale riferimento normativo se esiste:


Flussi / Attività

Rif. Normativo

Anagrafe Assistiti Esenzioni

Varie

Assistenza Medica Base

Accordo Interregionale per la Compensazione della Mobilità Sanitaria, etc.

Assistenza Domiciliare Integrata (A.D.I.)

D.M. 17/12/2008

Assistenza Sanitaria Internazionale (ASPE-C/ ASPE UE / TECAS)


Certificati Assistenza Parto (CEDAP)

D.M. 16/07/2001

Cure Termali

Accordo Interregionale per la Compensazione della Mobilità Sanitaria, etc.

Dati di struttura e di attività Aziende - Flussi economici (FLS/STS/RIA/HSP - CE/SP/LP/LA/CM)

Varie

Disturbi comportamento alimentare (SDCDA)

DGR 676 del 5/12/2006

Elaborazione Mensile Prestazioni Specialistiche Strutture Pubbliche

Art. 50 L.326/2003 - Accordo Interregionale per la Compensazione della Mobilità Sanitaria

Emergenza - Urgenza (118)

D.M. 17/12/2008

Emergenza - Urgenza (Trasporti)

Accordo Interregionale per la Compensazione della Mobilità Sanitaria

Emergenza - Urgenza (DEA - P.Soccorso)

D.M. 17/12/2008

Ex Esposti Amianto e Tremolite

Varie

Emocomponenti / Emoderivati (Prodotto del frazionamento del sangue intero / Trattamento di patologie rare delle immunodeficienze primarie)

Accordo Interregionale per la Compensazione della Mobilità Sanitaria

Farmaceutica (Territoriale)

Accordo Interregionale per la Compensazione della Mobilità Sanitaria

Farmaceutica (Diretta o per Conto)

D.M. 31/07/2007

Farmaceutica (Ospedaliera)

D.M. 04/02/2009

Farmaceutica (File F)

Accordo Interregionale per la Compensazione della Mobilità Sanitaria

Hanseniani (Prestazioni verso cittadini affetti dal morbo di Xxxxxx)

Accordo Interregionale per la Compensazione della Mobilità Sanitaria

Hospice

DM 06/06/2012

IBMDR (Registro italiano dei donatori di midollo osseo)

Accordo Interregionale per la Compensazione della Mobilità Sanitaria

Monitoraggio Consumi Dispositivi Medici

D.M. 11/06/2010

Monitoraggio errori in sanità (SIMES)

D.M. 11/06/2010

Monitoraggio Tempi di Attesa Prestazioni Specialistiche (PNGLA): Settimane Indice

Piano Nazionale governo liste di attesa (rif. L 120/2007)

Monitoraggio Tempi di Attesa Sospensione Attività di Erogazione (PNCTA)

Piano Nazionale contenimento tempi di attesa

Percorsi Diagnostico Terapeutici

Piano Nazionale governo liste di attesa (rif. L 120/2007)

Prestazioni ambulatoriali Pubbliche (CUP)

Varie

Prestazioni ambulatoriali Private (CEA)

Varie

Residenziali/semiresidenziali (FAR)

D.M. 17/12/2008

Residenziali/semiresidenziali (ex. Art 26 - AIAS)

ex art. 26 L. 833/1978

Residui manicomiali (MANIC) (Prestazioni erogate verso assistiti residuati in Italia dalla chiusura/conversione degli ospedali psichiatrici)

Accordo Interregionale per la Compensazione della Mobilità Sanitaria

Rete di Assistenza (MRA)

Xxxxx

Rete Infarto Miocardico Acuto

DGR 175/2011

Ruoli Professionali

Varie

Salute Mentale

D.M. 15/10/2010

Schede dimissione ospedaliera (SDO)

Varie



Screening prevenzione Cancro / Screening Oncologici

DGR 170/2007 / ex DGR 298/2012 e DGR 337/2014

Sociale / Volontariato Associazioni Culturali

Varie

Stereotassica (Tecnica radiologica che permette di localizzare nello spazio le strutture anatomiche)

Accordo Interregionale per la Compensazione della Mobilità Sanitaria

Strutture Complesse (Elenco Nazionale Direttori)

DL 13/9/2012 n. 158

Studio Passi (Progressi Aziende Sanitarie Salute Italia)


Tessera Sanitaria

Art. 50 L.326/2003

Tossicodipendenza (SIND)

DGR 1492/2005


4.4 ANAGRAFE UNICA CON REGISTRO CAUSA MORTIS E ANAGRAFICA CONTATTI

Creare un'anagrafica paziente unica con l'implementazione di un servizio di Master Patient Index (MPI) per l'intera Regione, interrogabile anche da applicativi terzi mediante web services, standard aperti (SOA, XX0, XXXX) e profili di integrazione IHE (Integrating the Healthcare Enterprise).

Creare un'anagrafica unica MEDICI DEL SSR con l'implementazione di un servizio di Master Medical Index (MMI) per l'intera Regione, interrogabile anche da applicativi terzi mediante web services, standard aperti (SOA, XX0, XXXX) e profili di integrazione IHE (Integrating the Healthcare Enterprise).

Creare un'anagrafica unica OPERATORI DEL SSR con l'implementazione di un servizio di Master NONMedical Index (MNI) per l'intera Regione, interrogabile anche da applicativi terzi mediante web services, standard aperti (SOA, XX0, XXXX) e profili di integrazione IHE (Integrating the Healthcare Enterprise).

Il progetto si propone, inoltre di aggiornare l’attuale software, rendendolo stabile, maggiormente fruibile da parte degli operatori ed adeguato alla vigente normativa.

Realizzare tutti gli adeguamenti derivanti dalla approvazione della Legge n.221/2012.


Realizzare tutti gli adeguamenti derivanti dalla entrata in esercizio dell'Anagrafe Nazionale Persone Residenti e dell'Anagrafe Nazionale Assistiti.

Le modalità operative e funzionali indicate nei paragrafi successivi, per comodità, sono relative alla sola anagrafica paziente, è inteso che per le restanti anagrafi, in analogia, si devono prevedere uguali funzioni e uguali modalità operative.


4.4.1 Caratteristiche

1. Anagrafe Unica Contatti Regionale (A.U.C.R. Master Patient Index)


Si costituisce una banca dati dei Contatti a Livello regionale.


La Banca dati si compone delle anagrafiche degli assistibili Regione Basilicata, delle anagrafiche degli assistiti fuori regione e Stranieri che hanno avuto/accedono alle strutture sanitarie della Regione Basilicata e degli assistiti temporaneamente non identificabili con replica sincrona presso tutte le Aziende del sistema sanitario regionale.

Le nuove anagrafiche devono essere inserite prioritariamente nell’Anagrafe Unica Contatti e quindi trasferite sulle Anagrafiche Locali.

L’anagrafe unica Contatti è replicata in modo sincrono con storicizzazione del''evento in locale per ragioni di performance e/o continuità dei servizi.

In caso di indisponibilità del sistema regionale, si genera una posizione temporanea a livello locale che deve essere ricongiunta successivamente con l’AUCR non appena si ripristina il sistema.

L’AUCR espone un servizio HL7 per l’integrazione con la stessa attraverso messaggistica standard:


a) - Inserimento Anagrafica


b) - Modifica Anagrafica


c) - Unione Anagrafiche


d) - Cancellazione anagrafica


e) – Query su paziente


Espone un servizio interno SISIR per:


a) Richiesta ID univoco


b) Ricerca Anagrafica


c) Insert Anagrafica


d) Unione Anagrafiche

Espone un servizio locale per:


a) Validazione Anagrafica (SOGEI/ANPR)


b) Ricerca Anagrafica Sogei/ANPR (codice fiscale) Espone un servizio Backoffice per:

a) Ricerca Posizioni non validate


b) Validazione Posizione


c) Sostituzione anagrafica


d) Unione Posizioni


Si precisa che le Funzionalità indicate in precedenze sono minimali, ulteriori funzioni saranno oggetto di valutazione.

2. MCI (Master Code Index)


Anagrafe unica regionale dei codici di decodifica (comuni, stati, diagnosi, prestazioni etc..) storicizzata per anno.

Lo scopo è la costruzione di una anagrafe unica dei codici e delle decodifiche delle tabelle utilizzate nelle procedure SISR e nelle Integrazioni con esso.

L’MCI espone servizio con messaggistica standard per


a) Richiesta ID univoco


b) Ricerca descrizione


c) Ricerca codice


d) Insert Codifica


e) Modifica Codifica


3. Anagrafe (registro/indice) Contatti (AC)


Costituzione a livello locale di una anagrafe dei contatti costituita da:


 id Unico Contatto, Tipo contatto, Id Anagrafe Unica, data ora, Servizio, Procedura, chiave procedura

Lo scopo è quello di tracciare il percorso dell’assistito nell’ambito di un evento sanitario. L’AC è gestita attraverso un servizio dedicato che espone i servizi:

a) Richiesta ID contatto.


b) Insert evento Contatto.


c) Sostituzione Anagrafica Contatto.


d) Aggiornamento evento contatto


4.4.2 Descrizione

L’anagrafe contatti è un sistema di funzionalità e servizi integrati all’interno degli applicativi Ospedalieri (AIRO, ARCA, CUP, ecc.) per la gestione delle anagrafiche associate agli eventi gestiti.

Le sue funzionalità consentono di identificare il paziente con un unico codice identificativo interno e seguire i suoi contatti sanitari nell’ambito della stessa azienda.

Il codice interno è utilizzato in alternativa al codice sanitario per la gestione dei contatti anonimi, dei fuori regione, delle identificazioni provvisorie (vedi urgenze) e per l’identificazione degli stranieri.

In fase di accettazione del paziente viene verificata la sua presenza nel sistema, in caso contrario viene creata una nuova posizione ed assegnato un codice univoco aziendale.

In Fase di accettazione, se il paziente è un “fuori regione”, gli applicativi dovranno ricercare il paziente sul DB del MEF attraverso apposito web service, successivamente cercare una corrispondenza nell’AC e, in caso negativo, creare il nuovo record se il paziente non è censito, oppure storicizzare il precedente e crearne uno nuovo in caso di presenza con valori diversi. In caso di indisponibilità del DB MEF, la procedura effettuerà la ricerca solo sull’AC, creando una posizione temporanea; in caso di mancato riscontro, il paziente verrà inserito in una lista di “non riscontrati” che successivamente, il personale preposto dovrà rielaborare non appena il server del MEF ritorna disponibile. Il codice assegnato segue il paziente nell’ambito dei contatti con la struttura (AC). Il codice AC (anagrafe contatti) è utilizzato come identificativo assistito nel SISIR e nelle integrazioni con altri sistemi dipartimentali (RSI, LIS, ANP, SIREP etc.) .

Le funzionalità dell’Anagrafe Contatti permettono quindi:


 la gestione delle fasi di identificazione del paziente;


 la gestione delle variazioni anagrafiche;


 l’unione di posizioni anagrafiche;


Il prodotto consta dei seguenti moduli:

 Identificazione assistito;


 Unione posizioni anagrafiche;


 Integrazioni.


Il sistema di gestione dell’Anagrafe dei Contatti rende disponibile all’utente un modulo unico per la gestione della scheda anagrafica dei pazienti. Il modulo deve essere interfacciabile dai sistemi esterni.

L’identificazione avviene sia attraverso ricerca dei dati anagrafici che con lettura della tessera sanitaria.

Il modulo deve consentire la ricerca delle diverse posizioni associate ad un assistito, l’identificazione dell’anagrafica principale e l’associazione delle rimanenti alla principale. Con l’unione delle posizioni, gli eventi sanitari noti sono ricondotti all’anagrafica principale. Le anagrafiche secondarie vengono rese invisibili agli operatori.

Il sistema deve essere integrato con tutti i prodotti oggetto della presente procedura di affidamento.


Inoltre deve essere integrato con i sistemi SIREP, LIS, RIS, ANP attraverso l’interfaccia CUP come Servizio Web Dedicato, in generale, integrazione con tutti i sistemi software ospedalieri/territoriali che utilizzano un anagrafica assistibili.

Il servizio web dedicato consente l’accesso all’Anagrafe per la Ricerca dell’assistito e per l’inserimento di nuove posizioni.

L’applicativo, come si può leggere nella relativa scheda funzionale, gestisce una serie di informazioni necessarie a tutti gli altri applicativi regionali per gestire gli assistiti.

L’applicativo gestisce due DataBase, uno per ciascuna Azienda Sanitaria, più un terzo, posto in regione, che rappresenta la somma dei due, da questi riceve gli aggiornamenti e viene usato dalle Aziende Ospedaliere per i propri applicativi, e dalle Aziende Sanitarie per recuperare i dati degli assistiti regionali non di propria competenza.

Gli applicativi regionali (CUP, AIRO, ARCA, ecc.) hanno al proprio interno un’anagrafe dei contatti dalla quale attingono, per le informazioni dei pazienti trattati, in particolar modo per quelli di fuori regione.

Il progetto si propone una revisione architetturale in ottica SOA dell’applicativo sulla stregua degli altri applicativi regionali, la revisione e l’adeguamento alle vigenti normative attuali e future, di tutte le funzionalità presenti oltre che la revisione dell’integrazione dei DB, sia delle anagrafi sanitarie che dei contatti, con gli altri applicativi regionali.

4.4.3 REGISTRO CAUSA MORTE

La mortalità costituisce uno dei principali strumenti di monitoraggio dello stato di salute della popolazione e un indicatore indispensabile per la definizione delle patologie più diffuse e quindi dei bisogni sanitari della popolazione. L’analisi dei dati di mortalità supporta, infatti, le indagini epidemiologiche sia per l’individuazione e lo studio dei fattori di rischio, sia per la verifica di ipotesi eziologiche e per conoscere in modo preciso l’incidenza delle diverse patologie. La qualità e la tempestività dei dati di mortalità rappresenta, quindi, la premessa indispensabile per una corretta utilizzazione degli stessi ai fini statistici, epidemiologici e per i futuri flussi del patient file.

Per quanto detto si rivelano fondamentali:


 una corretta compilazione della scheda ISTAT, da parte del medico per quanto riguarda la causa di morte, poiché ciò diventa il punto di inizio di ogni valutazione statistica ed epidemiologica;

 un celere aggiornamento dell’anagrafe sanitaria, perché origine dell’evento conclusivo della vita del Patient File che segue l’assistito dalla nascita al decesso.

La scheda dell’ISTAT per la registrazione delle cause di morte, unico strumento in atto, a livello nazionale per la registrazione dei dati relativi all’evento decesso, prevede due diversi modelli :

1. MOD ISTAT D.4 scheda di morte oltre il 1° anno di vita;


2. MOD ISTAT D.4 bis scheda di morte nel 1° anno di vita. La scheda ISTAT si compone di due parti:

 la parte A, relativa alla causa di morte, compilata a cura del medico curante o necroscopo


 la parte B, relativa ai dati anagrafici del defunto, compilata a cura dell’ufficiale di stato civile del comune nel cui territorio è avvenuto il decesso, il quale oltre a riportare i dati di sua competenza relativi agli archivi anagrafici e di stato civile è tenuto alla verifica dell’esatta identità della persona deceduta.


4.4.4 REGISTRO CAUSA MORTE Stato Attuale Del flusso informativo

Al fine di rendere più celere ed efficiente il meccanismo di comunicazione diretta dell’evento decesso è necessario, preliminarmente, effettuare un’analisi dei procedimenti amministrativi e dei relativi punti critici, descrivendo nel dettaglio il processo di costruzione dei dati nell’attuale sequenza temporale e la loro movimentazione onde evidenziare le criticità che rallentano il processo di comunicazione. Si riportano, pertanto, in sintesi, tutte le fasi del processo di comunicazione del decesso attraverso il percorso della scheda ISTAT, unico strumento regolamentato per legge che allo stato attuale segue, inoltre, due flussi distinti a carico di due enti diversi (Comuni ed ASL), al momento non collegati per legge.

Fasi in cui si costruisce l’informazione ed i contenuti informativi


1. Il primo soggetto coinvolto nella produzione dei dati è il medico certificatore (medico curante, medico necroscopo, medico dell’istituto di cura) cioè colui il quale compila la parte A, relativa alla causa di morte, della scheda ISTAT. Entro 24 ore dal decesso la scheda ISTAT, compilata, è trasmessa, da uno dei congiunti o da persona convivente col defunto o da un altro delegato (dichiarazione di morte DPR 396/2000 art.72), all’Ufficio di Stato Civile del Comune dove è avvenuto il decesso, che rappresenta il secondo soggetto coinvolto.

2. L’Ufficio di stato Civile, verifica l’esatta identità della persona deceduta in modo da poter compilare la parte B della scheda originale ISTAT, relativa ai dati anagrafici del deceduto, ed entro 30 giorni, trasmette la copia della scheda ISTAT all’Azienda ASL nel cui ambito ricade il Comune del decesso (DPR 285/90). Dopo l’accertamento dell’identità del deceduto, se questi non è risultato essere residente nel comune dove è avvenuto il decesso, l’ufficio di stato Civile ha l’obbligo di inviare prontamente copia dell’atto di morte alle istituzioni previste dal DPR 396/2000 art.81, 82 e 83.

3. L’Azienda ASL del comune del decesso che riceve la scheda ISTAT costituisce il terzo soggetto coinvolto in ordine temporale. L’Azienda ASL è tenuta a conservare un registro dei decessi avvenuti nel proprio territorio secondo il DPR 285/90. Qualora il deceduto fosse residente nel territorio di una Unità Sanitaria Locale diversa da quella ove è avvenuto il decesso, quest’ultima deve inviare copia della scheda di morte all'Unità Sanitaria Locale di residenza.


4.5 DEMATERIALIZZAZIONE PRESCRIZIONI

La Regione Basilicata ha affrontato l’applicazione della nuova normativa riguardante la dematerializzazione delle ricette sanitarie (ricette rosse) in due fasi distinte.

Nella prima fase la normativa è stata applicata alla dematerializzazione delle “ricette specialistiche prescritte ed erogate internamente alle strutture pubbliche”, ed ha riguardato solo l’invio, l’annullamento e la lettura delle sole ricette di prestazioni specialistiche e non quelle relative ad i farmaci prescritti.

Nella prima fase sono state portate a termine le seguenti attività:


1. Costruzione di un Web Service che colloquia con il SAC che implementa:


 Il Servizio per l’invio dei dati della ricetta al SAC per la generazione della ricetta elettronica;

 Il Servizio di visualizzazione dei dati della ricetta elettronica;

 Il Servizio per l’annullamento della ricetta elettronica.

2. Modifiche agli applicativi Arca e Pronto Soccorso per:


 Modifica applicativo ARCA per la stampa della ricetta rossa;


 Modifica applicativo Pronto Soccorso per la stampa della ricetta rossa;


 Stampa del promemoria della ricetta secondo il nuovo formato in sostituzione della stampa della ricetta rossa per la prescrizione di prestazioni specialistiche;

 Invio ricetta al SAC.

3. Visualizzazione Ricetta Elettronica inviata al SAC


4. Xxxxxxx Xxxxxxx Elettronica inviata al SAC


5. Gestione esito negativo invio Ricetta Elettronica al SAC


La fase 2, che rimane da implementare ed oggetto del progetto, deve trattare tutti gli aspetti che riguardano la dematerializzazione di tutte le ricette prescritte nella Regione Basilicata.

Oltre alle ricette specialistiche prescritte ed erogate internamente alle strutture pubbliche occorre estendere la dematerializzazione a:

(a) Ricette farmaceutiche prescritte ed erogate nella Regione Basilicata coinvolgendo tutti i Medici di Base e le Farmacie;

(b) Ricette specialistiche prescritte nella Regione Basilicata ed erogate in strutture regionali pubbliche o private convenzionate coinvolgendo tutti i Medici di Base, le Strutture Erogatrici Pubbliche e tutte le Strutture Erogatrici Private (CEA);

(c) Ricette specialistiche prescritte fuori Regione Basilicata ed erogate in strutture regionali pubbliche o private convenzionate coinvolgendo tutte le Strutture Erogatrici Pubbliche e tutte le Strutture Erogatrici Private (CEA).

Nella seconda fase devono essere implementate le seguenti funzionalità:


1. Il Web Service per il colloquio con il SAC, che è stato sviluppato nella Fase 1, deve essere arricchito dei servizi necessari per la gestione dei dati della ricetta elettronica presente presso il SAC/SAR da parte delle strutture di erogazione;

2. Visualizzazione esclusiva dei dati della ricetta elettronica;


3. Sospensione/Revoca della ricetta elettronica da erogare;

4. Invio dei dati della ricetta al SAC per la comunicazione di chiusura dell’erogazione di una ricetta elettronica.

Modifiche agli applicativi Cup, CeaCup e CupInLinea per:


1. Acquisizione esclusiva di una Ricetta dal SAC (Accettazione Ricetta);


2. Invio notifica di revoca sospensione (sblocco) della ricetta al SAC (Annullo Impegnativa);


3. Invio di notifica di erogazione di prestazioni presenti di una ricetta al SAC (Registrazione Accessi);

4. Gestione indisponibilità Ricetta Elettronica;


5. Gestione esito negativo invio Erogazione al SAC Modifiche dell’applicativo AIRO per:

1. Acquisizione esclusiva di una Ricetta dal SAC (Accettazione Ricovero);


2. Invio notifica di revoca sospensione (sblocco) della ricetta al SAC (Annullo Ricovero); Modifiche dell’applicativo CEAWEB per:

1. Acquisizione esclusiva di una Ricetta dal SAC (Accettazione Ricetta);


2. Invio notifica di revoca sospensione (sblocco) della ricetta al SAC (Annullo Impegnativa);


3. Invio di notifica di erogazione di prestazioni presenti di una ricetta al SAC (Registrazione Accessi);

4. Gestione indisponibilità Ricetta Elettronica;


5. Gestione esito negativo invio Erogazione al SAC

Inoltre, è fondamentale e necessario predisporre opportune funzionalità che permettano, durante ed al termine del ciclo di effettiva erogazione della prescrizione farmaceutica, specialistica ed altra prescrizione, il contestuale aggiornamento del DOSSIER/FASCICOLO elettronico dell'assistito. Si precisa che in sede di presentazione del progetto la tempificazione deve obbligatoriamente rispettare le indicazioni del ministero della Sanità e del ministero dell'Economia e Finanze e della Ragioneria Generale dello Stato e lo stato di attuazione, ovvero prima di procedere alla presentazione del progetto tecnico, le aziende sono obbligate, pena esclusione, a richiedere al Responsabile del procedimento lo stato di attuazione, rispettando le tempistiche indicate nel capitolato, mediante istanza a mezzo PEC ed ad allegare la risposta all’offerta tecnica, o in sede di sopralluogo come indicato in precedenza.


4.6 REVISIONE ED AMMODERNAMENTO ARCHITETTURALE DEI SISTEMI SOFTWARE IN MANUTENZIONE

Come più volte evidenziato, anche nei paragrafi precedenti, i requisiti fondamentali imprescindibili che devono essere posseduti dagli applicativi costituenti il SISIR sono:

1. Sicurezza dei dati di tipo architetturale.


2. Indipendenza architetturale da componenti che ne limitino il riuso sia in termini temporali che di numerosità.

FASCICOLO

Il sistema SISIR deve implementare una logica di “Single Sign On”, gestire profili di autorizzazione e accounting che consenta a tutti gli utenti di accedere, con credenziali riferite a differenti profili di utilizzo del sistema, alle componenti applicative per cui sono abilitati, per gli ambiti funzionali consentiti e per dati sanitari autorizzati. Parallelamente, il sistema deve implementare un ambiente unificato mediante il quale consentire, agli uffici aziendali e regionali preposti, di definire in modo centralizzato i profili di abilitazione per ogni utente, sia esso assistito e/o operatore, alle singole




A 1

A 2

A 3


A P L I C A Z I O N E


A P L I C A Z I O N E

A N


P

P

P

P

L

L

L

L

I

I

I

I

C

C

C

C

A

A

A

A

Z

Z

Z

Z

I

I

I

I

O

O

O

O

N

N

N

N

E

E

E

E

Autenticazione, Autorizzazione, Account

Gestione Politiche e Profili

Garanzia Integrità e Disponibilità

applicazioni, secondi i livelli di accesso consentiti e verificare le modalità di utilizzo del sistema e delle componenti evidenziando eventuali abusi. Tali requisiti di sicurezza di tipo architetturali sono necessari a garantire la tutela dei dati sanitari dell'assistito nei termini e nelle modalità previste dal D.Lgs 196/2003. La soluzione proposta deve assicurare:

1. elevate caratteristiche d'interoperabilità;


2. elevate capacita di difesa dalle minacce informatiche attuali e future;


3. essere completamente trasparenti all'utilizzatore (operatore/assistito);


4. costi operativi sostenibili anche nel tempo;

I vincoli indicati dai quattro punti precedenti derivano da considerazione di natura esse stesse architetturali, il Fascicolo/Dossier sanitario è il risultato del lavoro di soggetti differenti, collocati in organizzazioni diverse e con profili di responsabilità dipendente dall’organizzazione, quindi diritti di accesso alla consultazione dei dati vincolati a prescrizioni legislative differenti. Inoltre, il Fascicolo/Dossier sanitario non è proprietà di chi lo produce e nemmeno di chi lo mantiene, ma di un soggetto terzo ben individuato, cioè l'assistito. Questi, a suo piacimento, può decidere di attivarlo/disattivarlo, dettare dei criteri di accessibilità diversi odi attivarlo parzialmente oscurando le informazioni sanitarie. Quindi, la sicurezza nella gestione delle informazioni non è un requisito aggiuntivo a tutti i requisiti, ma una caratteristica intrinseca di ciascuno dei requisiti funzionali presenti e futuri, in definitiva è un requisito architetturale.

Secondo requisito architetturale costruire nuovi componenti utilizzando standard aperti, conosciuti e non proprietari di rappresentazione dati e trasmissione dati. Ovvero, l'applicazione può esser riusata liberamente, da parte di altri soggetti pubblici o privati, senza limitazioni alcuna nel numero degli utenti e nel tempo. Tutti i componenti delle architettura di sistema e in particolare, le componenti di base (sistemi operativi, librerie, frameworks, DBMS, linguaggi di programmazione) possono essere riusati senza alcuna limitazione nel numero e nel tempo e consentono l'interoperabilità.

La soluzione architetturale che si intende venga realizzata, in questo progetto, è di tipo ESB che integra e rende disponibili le informazioni prodotte da ogni singolo applicativo SOA costituente il sistema informativo sanitario. Tali informazioni devono essere fruibili anche per realizzare il sistema di DWH regionale.


Il modello implementativo è rappresentato in figura, si precisa che per comodità sono indicate solo parte delle componenti di business, ciascuna delle componenti genera e/o consuma messaggi. Gli eventuali ulteriori livelli di elaborazione sono propri di ciascuna delle componenti applicative di business, mentre il livello di persistenza è demandato a componenti ben individuati che nascondono dettagli implementativi. Il canale di trasporto è intrinsecamente sicuro e utilizza protocolli ben documentati ed aperti. Per completare il processo di evoluzione del sistema SISIR che abbia una

visione centrica dell'assistito quale imprescindibile requisito, risulta necessario adeguare il sistema in modo che esso divenga completamente aderente a quanto stabilito dal Decreto Crescita (D.L. n° 48 del 04/10/2012) e dai successivi decreti attuativi in tema di Fascicolo Sanitario Elettronico e in particolare dal D.Lgs 179/2012.

Adeguamenti ed ampliamenti evolutivi si rendono anche necessari per consentire al sistema di integrare i repository e registry delle aziende con la documentazione digitale che via via sarà resa disponibile dai soggetti produttori secondo gli standard dell’X-Xxxxxx (XX0, XXX0, DICOM, IHE, TAVOLO TSE, ICD9-CM, LOINC, AIC, ATC).

Anche dal punto di vista dei soggetti fruitori è necessario che il sistema venga adeguato, anche per tenere conto di una corretta gestione dei pazienti, alla necessaria integrazione tra il sistema di gestione del FSE ed ai presenti e futuri sistemi di gestione delle identità digitali dei cittadini.

Il sistema deve supportare la corretta presa in carico del paziente nell’ambito dell’assistenza territoriale attraverso una infrastruttura di servizi multi livello in rete che consenta agli operatori socio-sanitari (medici di base, medici specialisti, analisti di laboratorio, etc.) di conoscere in qualsiasi momento e in qualsiasi posto la storia clinica del paziente mediante informazioni affidabili, sintetiche o complete riguardanti gli episodi sanitari consumati dai cittadini. Tali informazioni sono generate da sistemi informatici clinici, locali alle singole organizzazioni e al sistema della continuità assistenziale.

Le informazioni provengono dai documenti clinici (prescrizioni, referti, ricoveri, lettere di dimissione, etc.) memorizzati nei repository e registry distribuiti sul territorio, presso le varie organizzazioni fornitrici di servizi sanitari e gestiti da un registry federato in conformità con le specifiche del Fascicolo Sanitario Elettronico NAZIONALE elaborate dal Tavolo della Sanità Elettronica e conforme al Regolamento Regionale.

Il sistema include un servizio di gestione dei documenti che rappresenta un’implementazione conforme alla specifica TSE inerenti la sanità elettronica. Per lo sviluppo del sistema di gestione “Pacient Centrics”, oltre agli standard internazionali di integrazione, già citati più volte, IHE e HL7, si devono rispettare le indicazione contenute nei documenti approvati, in corso di approvazione o futuri prodotti dal Tavolo di Sanità Elettronica Nazionale e di Fascicolo Sanitario Elettronico:

 Standard tecnici per la creazione del “Documento di Prescrizione” secondo lo standard HL7- CDA Rel. 2

 Specifiche tecniche per la creazione del “Documento di Referto” secondo lo standard HL7- CDA Rel. 2

 Standard tecnici per la creazione del “Documento di Prescrizione da inviare al SAC” secondo lo standard HL7-CDA Rel. 2

 Specifiche tecniche per la creazione della "Lettera di Dimissione Ospedaliera" secondo lo standard HL7-CDA Rel. 2

 Specifiche tecniche per la creazione del “Profilo Sanitario Sintetico” secondo lo standard HL7-CDA Rel. 2

 Specifiche tecniche per la creazione del “Documento di Referto di anatomia patologica secondo lo standard HL7-CDA Rel. 2

 Specifiche tecniche per la creazione dei "Documenti di raccolta e gestione del consenso" secondo lo standard HL7-CDA Rel. 2


In particolare, devono essere implementate entro 24 mesi dalla stipula del contratto le seguenti funzionalità:

 disponibilità di servizio di accesso dell'assistito ai propri dati sanitari e di tutte le funzionalità per la gestione del consenso e per singoli eventi sanitari nelle modalità previste dall’art. 64 del CAD e specifici profili in attuazione della Legge 98/2013 e Legge 221/2012 e ss.mm.ii.;

 Disponibilità di servizi di collegamento, alimentazione e interoperabilità per MMG/PLS, strutture sanitarie pubbliche/private accreditate, nelle modalità previste dal CAD, secondo architetture orientate ai servizi e secondo specifici profili e formati previsti in attuazione della Legge 98/2013 e Legge 221/2012 e ss.mm.ii.

 Disponibilità dei servizi di gestione dei referti di laboratorio, per immagini e delle prescrizioni ambulatoriali, nelle modalità previste dal CAD, secondo architetture orientate ai servizi e secondo specifici profili e formati previsti in attuazione della Legge 98/2013 e Legge 221/2012 e ss.mm.ii.

L'architettura funzionale a strati del nuovo sistema integra perfettamente tutti gli applicativi sanitari ed i documenti strutturati sanitari garantendo:

 persistenza documentale basata sui concetti di registry e repository integrati e federati;


 continuità e garanzia di servizio ed accesso;


 autenticazione autorizzazione e verifica dei diritti, relativi al profilo di accesso, accurati e granulari derivanti dalla sensibilità delle informazioni contenute;

 integrazioni di dati di vari tipi utilizzando lo standard IHE ed un unico motore HL7 unico per tutto il sistema documentale sanitario;

 sicurezza di accesso basata sulle asserzioni contenute nello stesso documento strutturato conservato nei repository aziendali al quale si intende accedere;

 scambio di informazioni con altri sistemi basati su messaggi, propri delle architetture basate sui servizi SOA basate su un ESB unico regionale;

 servizi di consultazione verifica e gestione fruibili in mobilità e tramite dispositivi mobili;


funzionalità di cartella clinica virtuale che fornisce servizi di alto livello applicativo, consente una conoscenza approfondita e autorevole dello stato di salute di ogni assistito, la storia clinica e suoi percorsi di cura in essere;

 servizio avanzato di notifica di eventi sanitari o gestionali che può gestire reti SOA virtuali basate su profili di utenza.

 un sistema di Editing ed un motore per l’esecuzione semi-automatizzata di percorsi assistenziali integrata con la Cartella Clinica Virtuale (Service & Process Editor, Service & Process Execution Engine);

 un sistema per l’organizzazione e la gestione intelligente di cruscotti sanitari (Profili del Paziente) che sintetizzino in modo efficace ed ottimizzato lo stato di salute di un assistito rispetto ad una particolare patologia (e.g. diabete, scompenso cardiaco, BPCO, etc.) o situazione sanitaria (gravidanza, vaccinazioni, screening, etc.);

 un Portale della Salute, fruibile anche da dispositivi mobili ed in mobilità con garanzia di sicurezza di accesso, che integri e sostituisca gli attuali (CUP WEB, Cittadini in Salute, Pagamento Ticket) e quindi funga da unico punto d’accesso per il cittadino e per gli operatori al complesso dei sistemi e servizi previsti nel progetto, ovvero enucleati nei punti precedenti, in particolare per i residenti consenta di gestire tutte le funzionalità previste per gli assistiti, tipo prenotare visite ambulatoriali, pagare ticket, consultare documenti clinici, definire viste con possibilità di modifica della visibilità di ogni singolo evento sanitario contenuto nel suo fascicolo, consenta di gestire ogni evento in corso con il sistema sanitario Regionale;

Il sistema ESB del SISIR deve garantire al minimo le seguenti caratteristiche e/o funzionalità:


1. ALTA AFFIDABILITÀ, garanzia di trasporto dei messaggi 24x7x365 con architettura distribuita.

2. RILASCI A CALDO cioè consentire la messa in produzione di aggiornamenti funzionali, nuovi componenti, aggiornamenti di base, processi, metodi ed operazione deve avvenire senza fermare in servi di trasporto e/o monitoraggio e/o sicurezza.

3. SCALABILE, cioè l'architettura del sistema (hardware/software) deve essere in grado di assicurare maggiori prestazioni aumentando il numero di sistemi eroganti i servizi ed indipendentemente dalla collocazione fisica. In ogni caso la configurazione minima deve garantire un carico di lavoro di 550 transazioni/secondo con picchi di 2000 transazioni/secondo con latenza non superiore a 3 secondi;

4. MULTI-PIATTAFORMA, cioè deve essere indipendente dall'hardware, dal sistema operativo, dal database, da componenti di midleware, da formati di rappresentazione di dati;

5. TOTALMENTE RIUTILIZZABILE, cioè ciascuno delle componenti o formato dati costituente il sistema utilizzato a qualsiasi livello di elaborazione deve essere a sorgente aperto e non proprietario, deve essere liberamente riutilizzabile senza limitazione di uso, di numero e di tempo;

6. PERSISTENZA DEI MESSAGGI, deve garantire funzionalità di persistenza tramite data base;

7. MOTORE DI BUSSINES RULE, deve fornire un motore per la gestione delle regole di elaborazione utilizzabile anche da non programmatori.

8. SISTEMA DI ROUTING STANDARD, garantire attività di instradamento dei messaggi basati sugli standard internazionali e/o sul contenuto del messaggio.

9. PROCESSARE GLI ALLEGATI AI MESSAGGIO, deve processare o rifiutare i messaggi XXXX, XXXX, XXXX00, XXXXX, MTOM/XOP etc.

10. SUPPORTARE LA MESSAGGISTICA STANDARD SOA, scambio di messaggistica nei formati standard per le architetture enterprise fra cui SOAP, WSDL, REST, XML, JSON, JAX etc.

11. SUPPORTARE I PATTERN SOA EVENT DRIVEN E PUBLISH SUBSCRIBE, capacità di processare sia messaggi sincroni/asincroni che elaborazioni di transazioni sincrone/asincrone.

12. GESTIONE DI MESSAGGISTICA STANDARD SANITARIA, in particolare messaggistica HL7 versione 2.x e 3, DICOM, ASTM e, in ogni caso, tutti gli standard italiani/europei per l'interscambio o la rappresentazione di dati socio-sanitari e/o economico- sanitari.

13. SUPPORTARE L'INTEGRAZIONE IHE prevedere nativamente o tramite componenti esterni integrati i profili di integrazione XDS.B e ATNA e successiva certificazione nei Connectathon IHE.

14. FUNZIONI DI VALIDAZIONE, deve fornire servizi di test per validare le componenti delle interfacce per lo scambio di dati.

15. FUNZIONI DI LOG E DI SLA, deve garantire attraverso cruscotti grafici, per tutti i messaggi scambiati, le funzioni di monitoraggio, ricerca, tracciabilità, recupero, eventuale modifica, gestione di eventuale nuovo invio, sia nella fase di sviluppo delle componenti che per la fase di regime delle componenti. Inoltre, deve gestire gli indicatori chiave per la misurazione della capacita/disponibilità di elaborazione, anche tramite cruscotti grafici, per qualsiasi metodo e/o servizio esposto e/o proxato

16. IL MOTORE DI BUSSINES PROCESSES MANEGEMENT deve supportare al minimo l'orchestrazione dei processi di business in formati aperti; la possibilità per gli sviluppatori di definire la logica di business attraverso la modellazione grafica o documenti strutturati

XML o attraverso la scrittura di codice, combinando questi strumenti per risolvere efficacemente al più tutta la gamma di esigenze di elaborazione; integrare il MOTORE DI BUSSINES RULE in modo che per cambiare il comportamento dei processi si modificano le regole e non il codice; separazione delle regole dalla logica di elaborazione per un loro riuso; gestire workflows integranti sistemi automatizzati, workflows integranti risorse umane e mix dei due workflows; funzionalità di verifica stato del processo e gestione avvisi integrato con il MOTORE DI BUSSINES RULE.

17. RENDERIG STANDARD, l'estrazione, la trasformazione, l'elaborazione, la visualizzazione dei messaggi xml e o in formato aperto deve esser basata su interfacce visuali basate su codice e/o tecnologie xpath, xquery, XSLT etc.

18. MONITORAGGIO IN TEMPO REALE, analisi istantanea del traffico gestito dal ESB per fornire servizi di gestione indicatori in tempo reale;

19. GESTIONE PROFILI E RUOLI STANDARD basati sugli standard ABAC, RBAC, IBAC, XACML E XRML e supporto obbligatorio degli standard quali WS Security 1.1, WS Policy, WS Addressing, SAML2, LDAP, X.509, XML Signature, XML Encryption, SSL/ TLS, PKI WS Reliability, WS ReliableMessaging;

Altri standard attinenti l'integrazione per componenti, per il dominio applicativo della Sanità Elettronica, saranno comunque vagliati e valutati attentamente.


4.7 SISTEMA PER IL TRACCIAMENTO DELLA QUALITA' DEL SISIR PER LA GESTIONE DEL CODICE SORGENTE, DEL PROGETTO, DEL VERSIONAMENTO SISTEMI SOFTWARE/HARDWARE, DELLA DOCUMENTAZIONE E MANUALISTICA.

La DA per la conduzione del progetto deve, entro 30 giorni dall'avvio del contratto, installare presso la sala server della regione un sistema (hardware e software) per la gestione del ciclo di vita del software, monitoraggio stato di avanzamento, programmazione e verifica attività di progetto e gestione ticket integrati, al fine di assicurare la qualità del progetto e la qualità del software del SISIR. L'implementazione Hardware e Software, del sistema per la gestione progetto e gestione del ciclo di vita del software è a totale carico della DA aggiudicataria. La Regione dovrà indicare la sede presso il quale installare il sistema. La modalità di accesso al sistema di gestione del ciclo di progettazione e sviluppo software, gestione del versionamento, gestione stato avanzamento progetto e di gestione e tracciamento delle richieste/notifiche deve essere fruibile è in modalità 24x7x360 con interfaccia Web 2.0 RIA indipendente dalla tipologia di dispositivo e/o browser utilizzato.

Al termine del contratto il sistema realizzato ed installato presso i locali regionali diviene di esclusiva proprietà della Regione Basilicata.

In particolare devono essere fornite le funzionalità per tracciare i bug e le richieste di miglioramenti/estensione provenienti da tutti gli operatori pubblici del SSR, le funzionalità di “Controllo di Versionamento ” con capacità di tracciare e gestire anche più diramazioni di progetto, le funzionalità per la gestione della generazione automatica dell'eseguibile (codice oggetto), le

funzionalità di vista storica di progetto su singolo report e le funzioni statistiche per bug, utenti, richieste, frequenze, gestione roadmap di progetto e gestione storicizzata delle risoluzioni degli errori. Il sistema deve consentire anche il tracciamento delle risorse impegnate, dello stato del progetto e dei sotto progetti relativi, delle attività in corso/terminate da attivare/attivate, gestione della rubrica di progetto con capacità di comunicazione diretta fra tutte le risorse impegnate nella realizzazione del progetto. Tutte le funzionalità devono essere fornite attraverso una interfaccia web; lo scopo è la gestione della manualistica, della documentazione di analisi, documentazione di progetto, sorgenti, documentazione di test, documentazione derivanti da processi/procedure di gestione e produzione codice, documentazione per la messa in esercizio e tutto quanto attinente e relativa ai processi di gestione del ciclo di vita del software.

Nel caso di utilizzo di sistemi proprietari di gestione, ovvero non a licenza open source, la DA deve fornire, a totale suo carico ed onere, tutti i codici, la documentazione, manualistica, i progetti software, gli script di compilazione, gli ambienti di test in formato aperto e non proprietario. Tutti i prodotti derivanti dalla esecuzione del contratto devono essere forniti nelle configurazioni opportune ed allineate ai rilasci ed alle versioni e/o diramazioni installate, nelle quantità e qualità adeguate indicando che la DA rinuncia esplicitamente a qualsiasi forma di proprietà e/o ad azioni di rivalsa su eventuali brevetti derivanti dai sistemi sviluppati nella gestione del contratto oggetto della presente gara di appalto. Inoltre, per quanto attinente alle architetture di sistema impiegate e realizzate per l'erogazione del servizio richiesto, in particolare alle architettura hardware, architetture dei sistemi operativi, database management system, framework software, web application, sistemi di gestione identità e profili utenze, formati documentali, la DA deve indicare chiaramente che sono aperti, utilizzabili/riutilizzabili senza limitazioni di uso temporale e di numero, e, per quelle parti a cui è applicabile, interoperabili e utilizzano standard aperti e documentati come indicato dal D.Lgs 235/2010 e ss.mm.ii. e Legge n. 221/2012 conversione del Dl. 179/2012.

La descrizione del sistema deve essere chiara e puntuale circa il processo/fase/attività che il sistema o l'integrazione di sistemi gestionali automatizza, inoltre, devono essere indicati schemi, standard documentali, procedure di gestione utilizzati ed automatizzati per mezzo del sistema di gestione realizzato. Descrizioni di generiche funzionalità/capacità di sistemi software non saranno oggetto di valutazione.


5. SERVIZIO DI ASSISTENZA APPLICATIVA E SISTEMISTICA

Nei paragrafi seguenti sono indicati le procedure ed i processi che la DA devi utilizzare nella erogazione dei servizi richiesti.


5.1. SERVIZI DI “MANUTENZIONE” APPLICATIVA


5.1.1. MANUTENZIONE ADEGUATIVA, CORRETTIVA E MIGLIORATIVA(MAC)

Il servizio richiesto al presente paragrafo consiste nell’affidamento, secondo le modalità meglio specificate di seguito, dei seguenti servizi:

 manutenzione correttiva e adeguativa, migliorativa degli applicativi affidati in manutenzione;

 assistenza operativa a tutti gli utenti del sistema per le attività del punto precedente nella modalità 6x10h dalle 7:30 alle ore 17:30 (dal lunedì al sabato) e verifica dei tempi di risposta minimi per ogni transazione dei sistemi;

 gestione della configurazione di ogni singolo applicativo/sistema ;


 gestione di tutta la documentazione a corredo del software, documentazione di requisiti di progetto, di disegno, di realizzazione, di test, di messa in esercizio, operativa e gestione del materiale formativo;

 gestione della tracciabilità di tutti i cambiamenti effettuati per il codice, per la relativa documentazione e per l'architettura Hardware/Software;

 tracciamento di tutti i ticket gestiti nel corso di esecuzione del contratto;


 gestione stati di avanzamento dei progetti in corso di visualizzazione;


 statistiche di intervento, errori, tempi di risposta, numero di transazione, etc..


 gestione della qualità di tutto il codice sorgente e codice oggetto realizzato/fornito, requisiti funzionali e non funzionali (esente da errori di progetto o programmazione), ovvero prodotto, ovvero preso in manutenzione, dei sistemi messi in esercizio e di tutti gli ambienti di staging ed esercizio presi in carico a totale onere della DA.


5.1.2. MODALITÀ GENERALI DI EROGAZIONE DEL SERVIZIO

Subito dopo l’entrata in vigore del contratto, il referente del SSR fornirà al referente della Ditta i sorgenti degli applicativi oggetto del servizio, gli script di generazione degli schemi dei relativi database e la documentazione tecnica ed utente eventualmente disponibile. La Ditta prenderà in carico gli applicativi, nel periodo massimo di sessanta (60) giorni solari a partire dall’entrata in vigore del contratto. La data di presa in carico coincide con l'istallazione e la messa in esercizio della versione 1.0 nominata versione di avvio, per messa in esercizio si intende l'avvio, collaudo ed esercizio presso tutte le AA. SS. Si evidenzia che tale versione deve prevedere tutte le funzionalità ed i servizi già erogati alla data di sottoscrizione del contratto. I servizi del contratto di cui ai punti 1, 2, 3, 4, 5 e 6 del paragrafo successivo “Modalità operativa di attivazione ed erogazione del servizio MAC” comunque sono erogati a far data dalla stipula del contratto.

In caso di inadempienza della Ditta relativamente alle date di presa in carico degli applicativi il Dipartimento per il tramite del Direttore dell'esecuzione si riserverà il diritto di applicare la penale di cui al paragrafo “Penali”.

Sarà cura della Ditta provvedere a mantenere presso proprie sedi e presso la Regione, idonei strumenti di gestione automatizzata del codice, della configurazione, dei rilasci, della tracciabilità dei cambiamenti per tutti gli ambienti software necessari allo svolgimento delle attività di erogazione dei servizi in modo che siano perfettamente allineati a quelli di produzione in esercizio presso le singole Aziende e presso il Dipartimento. Strumenti di gestione open source e web saranno oggetto di valutazione tecnica.

I servizi di manutenzione, progettazione e realizzazione del software dovranno essere resi da personale in possesso di comprovate esperienze nella gestione del ciclo di vita del software e progettazione/realizzazione di sistemi informatici.

L’interfaccia del Dipartimento verso la Ditta per l’erogazione dei servizi è il Direttore del esecuzione e suoi Assistenti ex art. 300 d.P.R. 5 ottobre 2010, n. 207, individuati nel presente documento anche come referenti delle Aziende e del Dipartimento.

Il referente del Dipartimento si impegna a comunicare al referente della Ditta ed a mantenere aggiornata la lista dei suoi assistenti, eventualmente differenziati per applicativi; analogamente il referente della Ditta si impegna a mantenere aggiornati i propri recapiti, in caso di inadempienza

verranno applicate le penali previste. Tutte le comunicazione dovranno avvenire utilizzando strumenti di PEC e dovranno essere archiviati sulla base informativa del progetto, integrata con la PEC che la Ditta ha installato presso la Regione

Tutte le attività che coinvolgono l’interfaccia del Dipartimento e gli utenti saranno svolte in orario lavorativo. Le attività di installazione e configurazione sui server e sulle postazioni utente e le attività di formazione degli utenti saranno svolte on site presso le sedi delle singole Aziende del Sistema Sanitario Regionale della Basilicata e presso le sedi della Regione pertinenti. Per la formazione si devono prevedere anche modalità di tipo Formazione A Distanza (FAD).

I numeri telefonici, e-mail, PEC e fax che la Ditta metterà a disposizione per l’erogazione dei servizi di cui al paragrafo “Modalità operativa di attivazione ed erogazione del servizio” dovranno essere raggiungibili tramite chiamata a tariffazione urbana senza scatto alla risposta verso numero verde disponibile anche da telefono mobile con tariffazione uguale a quella indicata ovvero tariffazione urbana senza scatto alla risposta. Il servizio telefonico sarà fornito tramite operatore (persona fisica), sono ammessi sistemi di IVR solo allo scopo esclusivo di migliorare e facilitare l'utente che deve utilizzare il servizio telefonico. Servizi di assistenza voip/video e/o web 2.0 saranno oggetto di valutazione.

Gli operatori della ditta dovranno tracciare le richieste anche sul sistema installato presso la regione.


Il servizio dovrà essere dimensionato in modo da garantire la presa in carico delle chiamate entro il tempo massimo di cinque minuti negli orari di erogazione. La connessione con l’operatore potrà essere eventualmente preceduta da selezioni operate dall’utente con un albero di selezione composto al più di due livelli. In ogni caso tutte le richieste di intervento, ad onere della Ditta, devono essere tracciate sul proprio sistema di gestione dei Ticket e su quello in regione. Il sistema regionale è l’unico utilizzato per calcolare eventuali inadempienze.

In caso di inadempienza, il Dipartimento si riserva il diritto di applicare le penali previste al paragrafo “Penali”.

La DA deve sincronizzare il proprio sistema di gestione automatica dei ticket con quello installato e gestito presso la Regione ed effettuare la tracciatura automatica dei ticket di richiesta interventi con quello regionale e mappare ogni richiesta sul sistema Regione che diventa sistema di riferimento per la redazione delle rendicontazioni relative agli interventi effettuati, formazione utente, assistenza operativa e misura della soddisfazione utente per i servizi resi.

La DA, ovvero, deve mantenere aggiornato ed allineato il sistema di gestione automatizzato della configurazione, dei rilasci, della tracciabilità dei cambiamenti per tutti gli ambienti software necessari allo svolgimento delle attività di erogazione dei servizi di manutenzione, ad ogni rilascio e, in ogni caso, al termine del contratto, per tutti gli applicativi che rientrano nell’ambito dell’esecuzione del contratto, compresi i sorgenti, inclusivi delle modifiche prodotte nel corso dell’attività, e tutta la documentazione redatta.

La proprietà degli applicativi e dei sistemi utilizzati, compresi le eventuali nuove realizzazioni prodotte nell’ambito della manutenzione evolutiva (MEV), delle modifiche software apportate e della documentazione redatta dalla Ditta in attuazione dell'offerta è, in ogni caso, sia nel periodo di vigenza del contratto sia dopo il suo termine, unicamente della Regione Basilicata . Tutti gli interventi software effettuati sono garantiti dalla Ditta per 24 mesi anche dopo la scadenza del contratto su eventuali malfunzionamenti e/o difformità funzionali o di requisiti non prima rilevate con, ove applicabile, le penali previste nel presente documento.

Tutta la documentazione tecnica relativa ai servizi di manutenzione correttiva, adeguativa ed evolutiva dovrà essere sviluppata con metodologia UML e dovrà essere fornita dalla Ditta in formato elettronico secondo le modalità previste dalle procedure di qualità vigenti e/o nelle modalità, procedure e formati contenuti nella proposta tecnica o concordati all'avvio del contratto. La documentazione comprenderà almeno i prodotti standard di seguito elencati:

1. Determinazione dei Requisiti;

 Raccolta;

 Identificazione;

 Classificazione;

 Requisiti non Funzionali;

 Requisiti Funzionali;

2. Analisi e Specifica dei Requisiti;

 Modelli Di Casi D’Uso;

 Diagrammi Di Casi D’Uso;

 Diagrammi di package di casi d’uso;

 Descrizione di Casi d’uso;

 Scenari;

 Estensioni;

3. Analisi di Consistenza dei requisiti

 Documento di Analisi e Disegno Logico e criteri di uscita composto al minimo da:


1. Diagramma Delle Classi


2. Diagrammi di sequenza;


3. Diagramma di Collaborazione;


4. Diagrammi di Transizione;


5. Diagrammi di Attività


6. Diagrammi di Interazione;


 Documento di Analisi e Disegno Fisico e criteri di uscita;


1. Diagramma delle Componenti;


2. Diagramma di Distribuzione


 Collaudo e relativi criteri di uscita:


1. Piano dei test di unità, Piano dei test di copertura (White BOX), Piano dei Test Funzionali (Black Box), Piano dei Test di Integrazione, Piano dei Test di Sistema, Piano dei Test di Carico, Piano dei Test di Usabilità;

2. Lista anomalie riscontrate per ogni iterazione ed azioni di uscita;


 Schema dei Dati completo di:


1. Schema Concettuale;


2. Vincoli non esprimibili nello schema;


3. Volume dei dati;


4. Dizionario dei dati

5. Progetto Fisico


6. Vincoli Referenziali e di Derivazione;


 Manuali di installazione;


 Manuali d’uso;


Saranno inoltre redatti manuali operativi per l’utente e documentazione per l’amministrazione e l’installazione del singolo applicativo e dell’ambiente di base e verticale.

La documentazione includerà, inoltre, il conteggio degli use case, calcolati in modo diretto e non attraverso metodologie di “backfire”, utilizzando la metodologia USE CASE POINT come di seguito indicato.

La documentazione dei casi d’uso conterrà le modalità di calcolo seguite per la loro elaborazione. In caso di inadempienze, il Dipartimento si riserva il diritto di applicare la penale prevista al paragrafo “Penali”.


5.1.3 METODO DI STIMA DELL'IMPEGNO DI SVILUPPO e MEV

Per Caso d'uso si intende “ Una sequenza di transazioni di un sistema, il cui compito è di conseguire un risultato di valore misurabile per un singolo attore del sistema”.

Il calcolo del numero di CASI D'USO (Use Case Point's UCP) da realizzare, onnicomprensivi di codifica, test, documentazione, e messa in esercizio esclusa la formazione per la stima economica del impegno è:

UCP = TCF*ECF*(UAW+UUCW).


Si intende per:


TCF = Fattore di Complessità Tecnica.


ECF= Fattore di Complessità Ambientale.


UUCP= Valore del Case Point non Pesato.


Dato UUCP =UAW+UUCW.


Definito UAW come Peso della Tipologia di Attore per il caso d'uso (sole per l'attore generale);

definito attori di tipo 1 i sistemi interagenti via API/SOA WEB SERVICES; attori di tipo 2 i sistemi interagenti via protocolli di comunicazione internet TPC/IP livello 6 ISO/OSI; attori di tipo 3 gli operatori umani;

definito N1 = numero di attori di tipo 1, N2 = numero attori di tipo 2 e N3 = numero di attori di tipo 3;

si ha che UAW=1*N1+2*N2+3*N3


Definito UUCW come Peso della Categoria di Caso d'Uso (la categoria è di tipo 5 se l'interfaccia utente scrive su un 1 o 2 tabelle dati e viene completata in un massimo di 4 transazioni e la sua implementazione coinvolge massimo 5 classi; è di tipo 10 se l'interfaccia utente scrive da 2 a 7 Tabelle Dati e viene completata da 3 a 8 transazioni e la sua implementazione coinvolge tra 5 classi a 10 classi; è di tipo 15 se supera tutti i valori precedenti). Dato M1 il numero di casi d'uso di valore 5, M2 il numero di casi d'uso di valore 10 e M3 il numero di casi d'uso di peso 15 si ha UUCW=5*M1+10*M2+15*M3. Si evidenzia che la stima del peso del caso d'uso non si applica per sistemi che effettuano solamente la trasformazione di contenuti statici xml e/o xhtml anche se essi sono prelevati da dbms. Per tali sistemi la stima dell'impegno richiesto è la realizzazione ed messa in esercizio di una pagina web per ora di impegno.

In caso di programmazione procedurale il valore di traduzione fra classe <=> procedure con interfacce dichiarate esplicite e pari a tre (ogni classe è equivalente ad almeno tre procedure con dichiarazione esplicita della interfaccia dati e scrittura su db). Per il calcolo dei DB utilizzati nella realizzazione del caso d’uso si considerano solo i db effettivamente scritti e non quelli utilizzati come appoggio e/o aiuto.

Si intende per: PF = Fattore di Produttività.

Assunto un valore di complessità Tecnica TCF = 0,96. Un Fattore di complessità ambientale ECF = 1,21.

Un Fattore di Produttività PF di 8 ore uomo per Caso d'Uso indipendente dalla complessità e figura professionale.

Calcolato il numero di casi di uso UCP=0,96*1,21*UUCP.


Definito C costo orario indipendente dalla figura professionale impiegata.


Si ha che CT, il costo totale stimato per la progettazione, realizzazione, test, produzione documentazione tecnica e sua messa in esercizio esclusa la formazione di interventi di MEV, espresso in ore uomo, ovvero CT=UCP*8*C.

Per interventi diversi dalla progettazione, realizzazione, test, messa in esercizio, di sistemi software ad-hoc il calcolo sopra esposto non si applica, in tali casi si considera la realizzazione di una pagina web statica che contenga almeno due immagini e 100 righe di testo per ora lavorata.

Per il calcolo del numero degli Attori Effettivi si tenga presente che se la classificazione degli attori individuati, nei casi di uso descriventi il sistema, non riflette una chiara differenziazione di ruoli e di interfacce di comunicazione, ma i diversi attori indicati sono effetto della schematizzazione ed essi sono riconducibili ad una categoria di Attore Generale, viene contato un unico attore generale.

Per il calcolo dei Casi D'uso Effettivi, si considerano solo i casi d'uso in relazione diretta con l'Attore Generale individuato, i casi d'uso derivanti da relazione di inclusione o estensione non sono conteggiati ai fini della stima del costo.


5.1.4. MODALITÀ OPERATIVA DI ATTIVAZIONE ED EROGAZIONE DEL SERVIZIO MAC

Lo scopo dell’attività è la manutenzione correttiva ed adeguativa degli applicativi in dotazione al SSR della Regione Basilicata oggetto della presente procedura di affidamento.

Lo scopo della manutenzione correttiva è la rimozione delle cause e degli effetti degli errori degli applicativi a fronte di malfunzionamenti verificatisi per qualunque causa, garantendo il corretto comportamento delle funzionalità ed usabilità degli applicativi coinvolti e l’eventuale ripristino dei database allo stato precedente il malfunzionamento. Per lo svolgimento di tali attività la SA riconosce un canone fisso onnicomprensivo.

Lo scopo della manutenzione adeguativa/migliorativa è il mantenimento delle funzionalità degli applicativi ed il loro tunning a fronte di modifiche o innovazioni dell’ambiente tecnico, sicurezza e/o legislativo sia Regionale (Leggi o Delibere) che Nazionale e la verifica e certificazione con cadenza mensile che i tempi di risposta degli applicativi (tempi di esecuzione transazione) rientrino nella soglia massima indicata in sede di offerta dalla DA per ciascun sistema. Per le difformità rilevate sui tempi soglia stabiliti, la DA è obbligata a svolgere le indagini del caso e attuare la soluzione se dipendente dai sistemi in manutenzione, o indicare la soluzione se il malfunzionamento è imputabile alla rete Aziendale Lan o alla rete Regionale. Per lo svolgimento di tali attività la SA riconosce un canone fisso onnicomprensivo.

La manutenzione correttiva ed adeguativa e l'assistenza operativa telefonica (help desk) sono rendicontati a canone ed erogati in modalità 6x10h. Il flusso delle attività è il seguente:

1. registrazione da parte dell'Help Desk della segnalazione di malfunzionamento nel sistema di gestione ticket della DA e sua assegnazione al tecnico di riferimento per l'area applicativa interessata (con notifica via e-mail dell'apertura ticket al Responsabile di contratto della Regione ed all’operatore dell'Azienda, tramite il sistema installato in regione; l’operatore o il Responsabile può segnalare il malfunzionamento anche attraverso il sistema di gestione ticket regionale);

2. rimozione del malfunzionamento tramite gli opportuni interventi sull'applicativo (in ambiente di sviluppo e test);

3. intervento sul sistema in esercizio con eventuale installazione delle patch sulle postazioni clients (se previsto) e sui server;

4. aggiornamento della documentazione relativa all'applicativo;


5. documento di approvazione e chiusura positiva attività;


6. tracciamento del cambio di stato e chiusura del ticket con notifica via e-mail al Responsabile di contratto della Regione e all’operatore anche attraverso il sistema di gestione ticket installato in regione.

Per la verifica dei tempi di risposta alle transazioni la DA in accordo con la SA rende disponibili, per tutti gli operatori, entro 90 giorni, separate funzioni per la verifica, su richiesta, dei tempi di esecuzione delle transazioni sul sistema in esercizio presso le aziende.

Gli interventi di cui al punto 2 e 3 devono essere conclusi al massimo entro 4 ore lavorative dalla segnalazione per i guasti bloccanti, entro 4 giorni solari per i guasti non bloccanti.

Si precisa che la manutenzione correttiva relativa a funzionalità realizzate, ovvero, in manutenzione dal fornitore del servizio, sono garantite per almeno 24 mesi prive di errori di programmazione, errori di analisi per requisiti già noti e di progettazione e/o disegno. La correzione di errori di programmazione e di errori di analisi/progettazione/disegno sono a totale carico della Ditta per l'intera durata della garanzia, ovvero tutte le forniture oggetto del contratto sono da considerarsi prive di errori di programmazione o di analisi e tutti gli oneri di ripristino sono a carico del fornitore. Per le attività di manutenzione correttiva è riconosciuto un canone fisso stabilito dal contratto erogato a scadenza quadrimestrale decurtato delle eventuali penali accertate nel quadrimestre di riferimento.

Per quanto riguarda la manutenzione adeguativa/migliorativa, la DA prenderà in carico tutte le richieste provenienti dal SSR regionale, facendone immediata comunicazione al Direttore dell'esecuzione o ai suoi assistenti, nei tempi e modalità stabiliti al paragrafo “Modalità generali di erogazione del servizio”, inoltre deve prevedere per ciascun applicativo sistemi di misura dei tempi di risposta per le transazioni di tutti gli applicativi in manutenzione.

A fronte della richiesta di miglioramento per cambiamenti tecnologici, nuove modalità di erogazione delle funzionalità esistenti, cambiamenti legislativi Regionali e Nazionali e carenza dei tempi di risposta, previa autorizzazione da parte del Direttore dell'esecuzione o suo assistente, la DA avvia le procedure di gestione della richiesta realizzando tutta la documentazione ed attività elencate:

1. redazione di un documento che descrive lo stato di fatto delle funzionalità e del codice interessato;

2. redazione di un documento descrittivo del cambiamento funzionale/tecnologico richiesto e del suo impatto sul sistema;

3. stesura di una relazione tecnica relativa all’intervento da realizzare e stima dell’impegno necessario alla completa e totale messa in esercizio del sistema, evidenziando le giornate uomo per singole figure professionali necessarie e la calendarizzazione delle attività indicate se applicabile;

4. acquisizione della relativa autorizzazione all’intervento e avvio o gestione delle attività secondo la tempificazione prevista;

5. test del sistema in ambiente di staging e realizzazione del report dei risultati ottenuti;


6. installazione/disinstallazione degli applicativi relativamente alle postazioni degli utenti ed ai server qualora, per qualunque motivo, se ne rilevi la necessità per tutte le attività finalizzate alla corretta messa in esercizio del nuovo sistema ivi compreso gli ambienti e software di base ed ambienti verticali di esercizio; le attività in parola andranno effettuate presso ciascuna sede del SSR Basilicata;

7. aggiornamento o redazione della documentazione del sistema ivi compresa la documentazione relativa alla configurazione di base, di ambiente verticale, di test e di codice sorgente;

8. tutte quante le attività necessarie a garantire la qualità, la tracciabilità, la replicabilità e l’adeguatezza dell’intervento effettuato;

9. consegna del report delle risorse effettivamente impiegate con dettaglio di ciascuna delle attività svolte e prodotti effettivamente rilasciati/realizzati e attestazione delle modifiche effettuate sul codice oggetto dell’intervento e di tutte le attività relative;

10. documento di approvazione e chiusura positiva attività;


11. tracciamento del cambio di stato e chiusura del ticket con notifica via e-mail al Responsabile di contratto della Regione e all’operatore anche attraverso il sistema installato in regione. Aggiornamento del report quadrimestrale delle attività approvate, svolte e concluse per la rendicontazione.

Tutte le attività previste ai punti dal n. 1 al numero n. 11 si devono concludere in maniera positiva a partire dalla data di autorizzazione. Si intende conclusa un attività solo se è stata acquisita e storicizzata la dichiarazione di fine attività firmata/approvata dal Direttore dell'esecuzione e, se applicabile, dai singoli Responsabili delle Aziende del SSR interessate, questa approvazione avviene non oltre i giorni lavorativi previsti dal crono programma di cui al punto 3.


5.1.5. MANUTENZIONE EVOLUTIVA SOFTWARE DEL SISIR (MEV)

Lo scopo del servizio è garantire la manutenzione evolutiva del parco applicativo oggetto dell’affidamento, al fine di adeguarlo a nuove esigenze funzionali degli utenti del sistema SISIR.

Tutti i prodotti della attività in parola, oltre al codice sorgente, sono di proprietà della Regione Basilicata che ne dispone in maniera totale e completa anche al termine del contratto e il fornitore rinuncia a qualsiasi azione legale che riguardi il diritto di autore su tutti i prodotti realizzati e le implementazioni eseguite durante tutta la fase esecutiva del contratto oggetto dell'appalto.

Gli interventi svolti in base alle indicazione contenute in questo paragrafo potranno:


(a) modificare o integrare le funzionalità degli applicativi indicati in precedenza;


(b) ristrutturare le funzionalità e l'architettura degli applicativi;


(c) realizzare nuovi applicativi.


In merito agli applicativi oggetto di intervento, la DA si impegna a garantire, nella versione rilasciata derivante dall'esecuzione dell'intervento previsto, senza alcun onere aggiuntivo, tutti i servizi previsti nei paragrafi precedenti ovvero i servizi di MAC.

La DA è obbligata a calcolare, secondo la modalità indicata, gli USE CASE POINT realizzati. Le modifiche devono essere analizzate ed approvate dalla SA.

La manutenzione evolutiva è richiesta tramite l’acquisizione di casi d’uso, onnicomprensiva di tutti gli oneri di codifica, test, documentazione, installazione e messa in esercizio esclusa la formazione se richiesta. L’eventuale attività di formazione andrà concordata eventualmente con i destinatari. La formazione, se richiesta, deve essere formalizzata e fornita secondo le modalità indicate nel paragrafo “Servizi di assistenza sistemistica e formazione a consumo” ed il valore economico di ciascuna giornata non potrà essere superiore al valore del costo giornaliero dell'assistenza sistemistica.

Per le realizzazioni di MEV la DA quoterà, nel progetto redatto, il numero dei casi d'uso da realizzare stimando il costo relativo di realizzazione in giornate uomo, utilizzando il metodo di calcolo indicata in precedenza. La DA deve rilasciare la documentazione obbligatoria relativa ai

casi d’uso realizzati secondo le modalità e nella numerosità prevista dal presente appalto, oltre alla documentazione minima indicata nei paragrafi precedenti, tutta la documentazione prevista dai manuali di qualità relativi alla produzione di sistemi software per l'azienda e/o le aziende deve essere certificata.

Le attività saranno remunerate sulla base dei casi d’uso effettivamente sviluppati (nuovi, modificati o cancellati), positivamente collaudati e portati in esercizio.

Il costo unitario per CASO D'USO modificato (CHG) e per CASO D'USO cancellato (DEL) è pari rispettivamente al 40% ed al 10% del costo unitario per nuovo CASO D'USO realizzato ex novo (ADD) e valorizzato nelle modalità indicate. Il pagamento degli interventi sarà fatto a consuntivo quadrimestrale, sulla base della verifica dell’effettivo svolgimento delle attività di messa in esercizio.

Le attività di documentazione dei casi d'uso esistenti, se richieste, saranno remunerate al 2% del valore calcolato nelle modalità descritte.

Le attività di refactoring, se richieste, saranno remunerate al 10% del valore stimato.


Le attività di estrazioni dati e di interrogazioni particolari che non comportano aggiunta di nuove funzionalità, se richieste, saranno remunerate al 10% del valore stimato nelle modalità descritte e comunque valorizzato dal direttore dell'esecuzione.

Gli interventi includono le attività di analisi, sviluppo, installazione, assistenza all’avvio e redazione di documentazione. L’attività di analisi potrà includere anche incontri diretti con gli utenti dell’intero sistema sanitario regione ivi compreso il personale delle Aziende Sanitarie. Tutta la documentazione tecnica, ad eccezione della documentazione ad uso degli operatori, deve essere sviluppata secondo quanto previsto in precedenza, nel rispetto degli standard regionali di documentazione (xxxx://xxx.xxxxxxx.xxxxxxxxxx.xx/xxxxxx/xxxx/xxxxxx/xxxxxxxxxx.xxx?xxxx000000&xxxxx000000&xxxxxx0) e deve prevedere al minimo:

 Documento di analisi, modellazione e specifica dei requisiti e criteri di Uscita contenente al minimo:

1. Determinazione dei Requisiti;

 Raccolta;

 Identificazione;

 Classificazione;

 Requisiti non Funzionali;

 Requisiti Funzionali;

2. Analisi e Specifica dei Requisiti;

 Modelli Di Casi D’Uso;

 Diagrammi Di Casi D’Uso;

 Diagrammi di package di casi d’uso;

 Descrizione di Casi d’uso;

 Scenari;

 Estensioni;

3. Analisi di Consistenza dei requisiti

 Documento di Analisi e Disegno Logico e criteri di uscita composto al minimo da:


1. Diagramma Delle Classi


2. Diagrammi di sequenza;


3. Diagramma di Collaborazione;


4. Diagrammi di Transizione;


5. Diagrammi di Attività


6. Diagrammi di Interazione;


 Documento di Analisi e Disegno Fisico e criteri di uscita;


1. Diagramma delle Componenti;


2. Diagramma di Distribuzione


 Collaudo e relativi criteri di uscita:

1. Piano dei test di unità, Piano dei test di copertura (White BOX), Piano dei Test Funzionali (Black Box), Piano dei Test di Integrazione, Piano dei Test di Sistema, Piano dei Test di Carico, Piano dei Test di Usabilità;

2. Lista anomalie riscontrate per ogni iterazione ed azioni di uscita;


 Schema dei Dati completo di:


1. Schema Concettuale;


2. Vincoli non esprimibili nello schema;


3. Volume dei dati;


4. Dizionario dei dati


5. Progetto Fisico


6. Vincoli Referenziali e di Derivazione;


 Manuali di installazione;


 Manuali d’uso;


Saranno inoltre redatti manuali per l’utente, di documentazione per l’amministrazione e d’installazione del singolo applicativo e dell’ambiente di base e verticale.

Tutta l’attività inerente la manutenzione evolutiva deve essere eseguita dalla Ditta in proprie sedi ed utilizzando un proprio ambiente e le proprie procedure di gestione del ciclo di vita e la qualità del software, provvedendo ad aggiornare, in maniera sincrona, il sistema di gestione del ciclo di vita e della qualità installato ed in esercizio presso la Regione.

Le modalità di esecuzione del servizio sono le seguenti:


 Il servizio è erogato su richiesta necessariamente autorizzata dal Direttore dell'esecuzione. La richiesta esporrà l’esigenza generale da affrontare in un documento di visione redatto in conformità allo standard indicato dalla DA.

 A fronte della richiesta, la DA presenterà, entro un massimo di 20 giorni lavorativi, fatto salvo i casi di massima urgenza concordati con il Diretto del esecuzione o suo assistente, un

preventivo di spesa in cui saranno indicati i giorni/uomo di impegno ovvero il numero di casi d’uso da realizzare, ed il numero dei prototipi rilasciati prima della messa in esercizio del sistema oltre a tutta la documentazione di progetto. Il progetto includerà altresì la calendarizzazione dettagliata delle attività giornaliere e del personale impiegato per l’espletamento delle attività. Il costo delle singole attività risulterà dal prodotto dei giorni/uomo ovvero dei casi d’uso per le corrispondenti quotazioni di impegno calcolate. La calendarizzazione dovrà prevedere l’inizio delle attività entro un tempo massimo di 10 giorni lavorativi successivi alla accettazione del progetto da parte della SA e l’impegno continuativo delle risorse indicate. Le attività di installazione e redazione di documentazione non saranno oggetto di quotazione né genereranno oneri aggiuntivi. E' data facoltà alla SA di prevedere tempi di consegna del progetto superiore ai 30 giorni, tale indicazione deve essere contenuta nella richiesta di intervento della SA.

 In relazione alla manutenibilità/modificabilità e qualità del codice sviluppato, la DA, allo scopo di dimostrare la qualità delle realizzazioni, è obbligata a produrre dei report da allegare alla documentazione prodotta che misurino il livello di documentazione LOC (linee di codice), la complessità ciclomatica COC (così come definito dall’AGID) e il grado di copertura dei test progettati ed eseguiti COVERAGE. Il “livello di documentazione (LDO)”, misurato come rapporto tra il numero delle linee di commento (LC) ed il numero delle linee di codice (LOC), dovrà essere superiore al 25%, ovvero: 25% < LDO = LC/LOC. Tale indicatore sarà calcolato approssimandolo all’intero più vicino. Il superamento del valore di soglia (inteso come un valore inferiore al 25%) comporta l’applicazione di una penale come previsto al paragrafo “Penali”. La complessità ciclomatica COC è uguale all'intero più prossimo al valore E-N+p dove E sono il numero di archi del grafo operazionale del modulo, N il numero dei nodi del modulo e p è il numero di componenti software connessi al modulo. Il valore di COC, per ogni singolo modulo, componente il caso d'uso deve essere inferiore a 21. Il superamento del valore di soglia (inteso come un valore superiore a 21) comporta l’applicazione di una penale come previsto al paragrafo “Penali”. Per percentuale di COVERAGE dei cammini di testing si intende l'intero espresso in percentuale del rapporto fra linee totale di codice testato CT diviso le linee di codice prodotto CP escludendo dal calcolo le linee di dichiarazione e le linee di commento testate durante le operazioni di unit test, tale rapporto deve essere maggiore o uguale al 90% (CT/CP >=90%). Il superamento del valore di soglia (inteso come un valore inferiore al 90%) comporta

l’applicazione di una penale come previsto al paragrafo “Penali”. L'arrotondamento è calcolato per difetto se il simbolo precedente è <= 0,5 in eccesso se > 0,5. Gli strumenti per il calcolo degli indicatori sono ad onere totale della DA.

 Il Direttore dell'esecuzione o suo assistente, valutata, in particolare, la congruità tecnica e la completezza della documentazione del progetto, si riserva in ogni caso il diritto di richiederne o meno l’esecuzione. Ove sensato, lo svolgimento delle attività potrà essere richiesto anche per singole attività del preventivo. Per preventivi che richiedono un tempo di conclusione delle attività superiore a 40 giorni solari, il Direttore dell'esecuzione e della Ditta concorderanno modalità di monitoraggio, per fasi progettuali o periodi temporali.

 Al termine delle attività la DA installerà il prodotto, in ambiente di test, e consegnerà al Direttore dell'esecuzione o suo assistente la relativa documentazione nelle modalità indicate. Il Direttore dell'esecuzione, a collaudo positivamente effettuato e dopo la verifica della qualità del prodotto, autorizzerà la messa in esercizio del prodotto, che verrà, quindi, rilasciato a carico della DA in ambiente di produzione. In caso di inadempienza saranno applicate le penali di cui al paragrafo penali. Dopo il collaudo, il Direttore dell'esecuzione concorderà con la DA l’avvio della formazione, se prevista, secondo il piano di formazione ed il materiale didattico allegato al preventivo di spesa. La formazione è considerata erogata se si supera l’80% della soddisfazione utenti misurata con appositi questionari preventivamente concordati con Responsabile di contratto. In caso di mancato superamento, la DA è obbligata alla ripetizione a suo totale onere sino al superamento della soglia del 80%. Al termine della formazione, si applicano le procedure per la gestione del ciclo di vita del software di cui al presente capitolato, pertanto solo per applicativi di nuova realizzazione ed installazione verrà riconosciuto un canone annuo del 5% del costo di realizzazione per la MAC.

 La rendicontazione dei lavori effettivamente messi in esercizio deve essere fatta nel quadrimestre di riferimento. Si precisa che, per effettivamente messi in esercizio, si intendono i lavori per cui è stata erogata la formazione se prevista. Inoltre, si precisa, che il tracciamento del cambio di stato e chiusura del ticket inerente la richiesta deve essere gestito con notifica via PEC al Direttore del esecuzione della Regione e all’operatore richiedente, se applicabile, tracciando l'effettiva chiusura solo in caso di approvazione di entrambi sul sistema gestionale installato in Regione.


5.2 SERVIZI DI ASSISTENZA, SISTEMISTICA, OPERATIVA E FORMAZIONE A CONSUMO

Questa categoria di servizi riguarda tutte le attività diverse da quelle relative alla manutenzione correttiva, adeguativa ed evolutiva degli applicativi in dotazione al SSR della Regione Basilicata oggetto della presente procedura di affidamento, è un servizio che può essere richiesto dalle AA. SS. anche a più riprese per un ammontare massimo totale annuo.

Il costo giornaliero da considerare è quello indicato, in offerta economica per lo svolgimento della attività in oggetto e se richiesta. Le quantità di servizi che ciascuna delle AA. SS. può richiedere e fissata dal Direttore dell'esecuzione.

Le modalità di svolgimento della attività sono le seguenti:


 Il servizio è autorizzato dal Direttore dell'esecuzione regionale che si può avvalere di Assistenti nominati dalla SA, in applicazione di quanto previsto dall’ art. 300 del d.P.R 5 ottobre 2010, n. 207 (collaboratori, assistenti delle AA. SS ecc.). La richiesta esporrà l’esigenza generale da affrontare in un documento di visione redatto in conformità allo standard indicato dalla DA in sede di offerta progettuale, può essere commissionato da un assistente della AA. SS. individuato con atto formale della SA.

 A fronte della richiesta, la DA presenterà un progetto, entro 20 giorni solari alla AA. SS. che fa richiesta, di attività ricadente nella tipologia di servizio, fatto salvo per i casi di urgenza, successivi alla richiesta, in cui saranno indicati i giorni/uomo di utilizzo con dettaglio delle attività da realizzare e/o dei test da effettuare per il collaudo dell'attività. Il preventivo includerà altresì la calendarizzazione dettagliata delle attività giornaliere e del personale impiegato per l’espletamento. Il costo delle singole attività risulterà dal prodotto dei giorni/uomo a prezzo fisso onnicomprensivo. La calendarizzazione dovrà prevedere l’inizio delle attività entro un tempo massimo di 10 giorni lavorativi successivi alla accettazione del progetto e l’impegno continuativo delle risorse indicate. Le attività di redazione di documentazione descrivente le azioni svolte non saranno oggetto di quotazione né genereranno oneri aggiuntivi.

 Il Direttore dell'esecuzione, valutata in particolare la congruità del progetto presentato e che esso rientri nei limiti di budget annuale assegnato per ciascuna AA. SS, si riserva in ogni caso il diritto di approvare l'attività richiesta dalla AA. SS. Ove sensato, lo svolgimento delle attività potrà essere richiesto anche per singole sotto-attività del preventivo. Per preventivi che

richiedono un tempo di conclusione delle attività superiore a 40 giorni solari, il Direttore dell'esecuzione e della Ditta concorderanno modalità di monitoraggio, per fasi di attività o periodi temporali.

 Al termine delle attività la DA provvede a redigere apposito schema standard descrivente il dettaglio delle attività formativa e/o sistemistica svolta, dei test effettuati e di eventuali collaudi sostenuti, redige un verbale di conclusione di attività in contraddittorio con l’assistente della AA. SS. richiedente e trasmette per conoscenza al Direttore dell'esecuzione regionale la relativa documentazione nelle modalità indicate storicizzando le singole fasi dell’attività sul sistema di gestione regionale. Il Direttore dell'esecuzione, verificato il verbale, autorizza la rendicontazione. La fatturazione delle attività autorizzate e concluse, nelle modalità e tempi previsti dal contratto, saranno emesse a carico delle AA. SS. richiedenti la/le attività. In caso di inadempienza saranno applicate le penali di cui al paragrafo “penali”.

La fatturazione delle attività avviene nelle modalità indicate in precedenza e direttamente alle AA. SS., inoltre, il Direttore dell'esecuzione regionale, in accordo con tutti i singoli assistenti delle AA. SS., nominati con atti formali dalla SA, ha facoltà di rimodulare il singolo budget annuale per AA. SS. senza superare il budget totale annuale o di contratto previsto per tutte le Aziende, ovvero, il budget per singola Azienda può subire variazioni mentre il budget totale annuale e/o di contratto previsto per tutte le AA. SS. rimane invariato.


6 PENALI

Le penali sono applicabili per mancato rispetto delle condizioni di erogazione dei servizi e fornitura di beni previste nel presente capitolato fatto salvo la richiesta da parte della SA di maggiori danni.

Per gli applicativi oggetto dell’affidamento, è fatto divieto tassativo alla ditta aggiudicataria di procedere ad accordi e/o stipulare contratti individuali con le singole aziende del Sistema Sanitario Regionale pena la rescissione del contratto e incameramento della garanzia definitiva.

Le citate condizioni possono riferirsi a ritardo nello svolgimento delle attività e/o al mancato raggiungimento degli obiettivi di qualità e/o documentazione e/o procedure attuative. Per mancato rispetto delle condizioni s’intende quello non giustificato e non sanato con sospensioni o proroghe accordate dall’Amministrazione ed esclusivamente imputabile a cause dovute al soggetto appaltatore o da esso provocate. Le penali applicate saranno scalabili dalle fatture emesse e/o saranno incamerate dal deposito cauzionale definitivo prestato dalla ditta. In tale ultimo caso,

l’applicazione della penale darà luogo all’incameramento della corrispondente quota dalla cauzione, con obbligo della ditta di provvedere alla sua reintegrazione entro 10 giorni.

Si elencano le penali previste per i servizi di assistenza:


 Mancata realizzazione presso la regione del sistema di gestione del ciclo di vita del software e gestione rilasci: 0,03% dell'ammontare netto contrattuale per ogni giorno solare o frazione di ritardo o giorno solare di mancato utilizzo o giorno solare di mancato allineamento;

 Mancata presa in carico dei sorgenti: 0,03% dell'ammontare netto contrattuale per ogni giorno solare o frazione di ritardo;

 Mancata presa in carico e risoluzione degli errori bloccanti o Rispetto degli S.L.A minimi/offerti: 0,03% dell'ammontare netto contrattuale per giorno solare o frazione di ritardo;

 Mancata presa in carico e risoluzione degli errori non bloccanti entro i tempi stabiliti e/o mancata produzione della relativa documentazione e/o mancato adeguamento dei sorgenti e degli oggetti eseguibili alle sopravvenute nuove normative entro i tempi stabiliti o richiesti dalla stessa norma: 0,01% dell'ammontare netto contrattuale per giorno solare di ritardo;

 Difformità dei documenti e delle procedure di esercizio del contratto: 0,02% dell'ammontare netto contrattuale per difformità accertata;

 Mancato utilizzo del sistema di gestione ticket realizzato e gestito presso la regionale: 0,01% dell'ammontare netto contrattuale per giorno solare di ritardo d'installazione e/o non utilizzo;

 Mancato rispetto di uno dei criteri di misura della qualità del codice: 0,02% dell'ammontare netto contrattuale per ogni difformità accertata;

 Ritardo e/o mancato rispetto dei tempi di consegna del progetto definitivo, entro i tempi indicati in sede di offerta, relativo ai “PROGETTI” richiesti o ad uno di essi: 0,03% dell'ammontare netto contrattuale relativo a tutti i progetti per giorno solare di ritardo;

 Ritardo e/o mancato rispetto dei tempi di consegna del progetto derivante da una richiesta di intervento MEV o di servizi di assistenza, sistemistica, operativa e formazione a consumo: 0,01% dell'ammontare netto contrattuale del servizio erogato alla data (somma di tutta la MEV e/o assistenza erogata alla data di esecuzione) per giorno solare di ritardo;

 Ritardo nelle consegne di adeguamenti dei sistemi informatici (MEV) o di esecuzione dei servizi di assistenza, sistemistica, operativa e formazione a consumo: 0,01% dell'ammontare netto contrattuale del servizio erogato alla data (somma di tutta la MEV e/o assistenza erogata alla data di esecuzione) per giorno solare di ritardo

 Xxxxxxx nelle consegne di tutti i “PROGETTI” richiesti entro i tempi indicati nel crono programma definitivo: 0,03% dell'ammontare netto contrattuale per giorno solare di ritardo. Si precisa che per consegna si intende, l'installazione, il collaudo e messa in esercizio di tutti i progetti richiesti alla voce “PROGETTI” su tutti i sistemi delle AA. SS. regionali.;

 Xxxxxxx nelle consegne di ogni singolo Progetto relativo ai “PROGETTI” richiesti entro i tempi indicati nel crono programma definitivo per ogni singolo progetto: 0,03% dell'ammontare netto contrattuale per giorno solare di ritardo relativo al valore del singolo progetto. Si precisa che per consegna si intende, l'installazione, il collaudo e messa in esercizio su tutti i sistemi delle AA. SS. regionali. Se non specificato il valore del singolo progetto, si applica il valore contrattuale specifico per la voce progetti;

 Mancato superamento del grado di soddisfacimento minimo del 80% del personale della SA oggetto di formazione: penale del 0.01% dell'ammontare netto contrattuale. E' fatto obbligo di ripetizione del servizio di formazione erogato e raggiungimento della soglia di soddisfacimento minima indicata nel presente punto;

 Mancata indicazione dei recapiti aziendali della DA e/o mancata indicazione delle variazione avvenute durante l'attuazione del progetto e mancato utilizzo della posta PEC per le comunicazioni ufficiali: penale di 0,01% dell'ammontare netto contrattuale per ciascuna inadempienza;

 Mancato rispetto delle clausole di garanzia: incasso della cauzione definitiva;


 Mancato rilascio finale di tutti i sorgenti in manutenzione con la relativa documentazione nelle modalità e formati previsti: incasso della cauzione definitiva;

 Sostituzione di una delle figure professionali indicate in sede di presentazione dell’offerta non approvata dal Direttore dell'esecuzione: 0,01% dell'ammontare netto contrattuale.

 Trattative con altri soggetti delle Aziende Regionali inerenti i sistemi oggetto del contratto e/o mancata notifica al Direttore dell'esecuzione della trattativa: rescissione del contratto in danno alla DA ed incasso della cauzione definitiva.

 Mancato rispetto degli S.L.A indicati nel progetto e/o degli S.L.A minimi richiesti nel presente allegato tecnico: 0,01% dell'ammontare netto contrattuale.

Si evidenzia che il superamento della soglia cumulata, per le penalità irrogate, nel periodo di intera vigenza contrattuale del 10% dell'importo netto contrattuale è causa di rescissione del contratto stesso ed incasso della cauzione definitiva.

Si precisa che per importo contrattuale si intende il valore delle prestazioni aggiudicate per i servizi di MAC e per la realizzazione dei progetti per la durata dell'intero contratto, per quantità di MEV richiesta e quantità di servizi di assistenza sistemistica/formativa richiesta totale durate l'esecuzione del contratto. Per il calcolo della soglia cumulata del 10% si considerano tutte le sanzioni irrogate senza differenza di tipologia di servizio fornito/richiesto.

Document Metadata

Filed: June 9th, 2015