Capitolato Tecnico

Il presente documento ha lo scopo di presentare al Proponente l’oggetto e l’articolazione della fornitura richiesta nonché gli elementi per articolare la migliore offerta tecnica allo scopo di soddisfare le necessità del Proponente.

Il documento fa riferimento all’Accordo Quadro CONSIP “Servizi Applicativi in ambito “SANITÀ DIGITALE - Sistemi Informativi Clinico-Assistenziali” per Le Pubbliche Amministrazioni del SSN” su cui è previsto un rilancio competitivo sul Lotto applicativo n.2 “Cartella Clinica Elettronica ed Enterprise Imaging – centro-sud”.

Il documento è articolato in 11 capitoli nei quali vengono in primo luogo presentati gli elementi generali dell’iniziativa (cap. 2) nonché l’oggetto della richiesta di fornitura (cap.3).

Successivamente, vengono specificati i requisiti funzionali, e non, della soluzione attesa (cap. 4 e 5), e ne vengono descritti i requisiti tecnologici (cap. 7).

Una volta fornita, l’utilizzo della soluzione prevede il trattamento di dati sensibili di pazienti ed operatori sanitari. Per tale ragione, l’offerta dovrà rispondere a specifici requisiti relativi al trattamento di dati personali (cap. 8).

Sono indicate le specifiche di avviamento, gestione, assistenza, manutenzione e delivery (cap. 9) in termini di: organizzazione complessiva, tempistiche di massima attese, strumenti di coordinamento tra i referenti degli Enti Sanitari (ES) e le risorse del Fornitore, altri servizi specialistici richiesti. Vengono forniti i livelli di servizio atteso (cap. 10), che riguardano sia gli aspetti gestionali sia gli aspetti tecnici dell’erogazione dei servizi descritti nelle precedenti sezioni del presente Capitolato Tecnico. Rispetto a questi si articolerà lo schema delle penali contrattuali che potranno essere applicate dagli ES al Fornitore in caso di inadempienza.

Infine, sono indicati gli elementi dimensionali di riferimento del servizio (cap. 11).

1.2. Glossario

Definizione	Significato	Descrizione
ADT	Accettazione, Dimissione, Trasferimento	Parte del Sistema Informativo che gestisce i processi (con relativa comunicazione) di accesso al ricovero, la movimentazione del paziente, la registrazione dell’esito del ricovero e la rendicontazione dei ricoveri.
CUP	Centro Unico di Prenotazione	Sistema informativo dedicato al supporto dei processi di prenotazione ed erogazione nelle strutture dedicate alla gestione della domanda e dell’offerta di prestazioni specialistiche e di diagnostica.
DICOM	Digital Imaging and Communications in Medicine	Standard sviluppato dall’American College of Radiology e dal National Equipment Manufacturers Association per definire i protocolli di connessione e comunicazione per lo scambio di immagini mediche digitalizzate.
EWS	Early Warning Score	Tipologia di strumenti di controllo delle funzioni vitali basate sulla raccolta di parametri vitali in una scala a punteggi che fornisca un indice chiaro, standard e di immediata comprensione al fine di mettere in atto una risposta clinica prestabilita e uniformata.

Definizione	Significato	Descrizione
FHIR	Fast Healthcare Interoperability Resources	È uno standard che descrive i formati e gli elementi dei dati, nonché un'interfaccia di programmazione dell'applicazione (API) per lo scambio di informazioni mediche. Lo standard è stato sviluppato da Health Level Seven International (HL7), un'organizzazione senza scopo di lucro dedicata allo sviluppo dell'interoperabilità dei dati sanitari e alla standardizzazione del protocollo di scambio medico.
Firma digitale		É un particolare tipo di firma elettronica qualificata basata su un sistema di chiavi asimmetriche a coppia, una pubblica e una privata, che consente al titolare tramite la chiave privata e al destinatario tramite la chiave pubblica, rispettivamente, di rendere manifesta e di verificare la provenienza e l’integrità di un documento informatico o di un insieme di documenti informatici.
FSE	Fascicolo Sanitario Elettronico	Si riferisce al Fascicolo Sanitario Elettronico regionale. É l’integrazione a livello regionale dei dati clinici generati dai singoli Enti Sanitari e registrati nei loro sistemi (repository dati clinici aziendali).
HL7	Health Level Seven	Standard XML per lo scambio di informazioni cliniche e amministrative.
LIS	Laboratory Information System	Sistema informativo per la gestione della diagnostica del Laboratorio di Analisi Chimico- Cliniche e Microbiologiche e dei relativi dati clinici.

Definizione	Significato	Descrizione
SI	Sistema Informativo ASL/AO/IRCCS	Il complesso dell’architettura hardware e software di supporto ai processi clinico- scientifici ed amministrativi all’interno dell’ASL/AO/IRCCS.
SLA (LdS)	Service Level Agreement (Livelli di Servizio)	Sono strumenti contrattuali attraverso i quali si definiscono le metriche di servizio (es. qualità di servizio) che devono essere rispettate da un fornitore di servizi (provider) nei confronti dei propri clienti/utenti. Di fatto, una volta stipulato il contratto, assumono il significato di obblighi contrattuali.
W3C	World Wide Web Consortium	Associazione con lo scopo di migliorare gli esistenti protocolli e linguaggi per il Web e di favorire lo sviluppo delle sue potenzialità.
DPD	Documento Progettuale di Dettaglio	Documento che il Fornitore è chiamato a redigere in fase esecutiva del presente Capitolato, in modo tale da descrivere in dettaglio la soluzione proposta nonché le tempistiche per la relativa implementazione.

2. ELEMENTI GENERALI DELL’INIZIATIVA

2.1. Contesto di riferimento

La presente iniziativa si pone nel contesto di attuazione del Piano Nazionale di Ripresa e Resilienza, nello specifico nelle progettualità afferenti ai piani M6 C1 – Reti di prossimità, strutture e telemedicina per l’assistenza territoriale e M6 C2 – Innovazione, ricerca, digitalizzazione del servizio sanitario nazionale.

L’attuazione della missione M6C1 intende perseguire una nuova strategia sanitaria che consenta al Paese di conseguire standard qualitativi di cura adeguati, in linea con i migliori paesi europei e che consideri, sempre più, il SSN come parte di un più ampio sistema di welfare comunitario. Essa prevede due attività principali:

• La definizione di standard strutturali, organizzativi e tecnologici omogenei per l’assistenza territoriale e l’identificazione delle strutture a essa deputate;

• La definizione di un nuovo assetto istituzionale per la prevenzione in ambito sanitario, ambientale e climatico, in linea con l’approccio “One-Health”.

L’introduzione e l’evoluzione della Cartella Clinica Elettronica Regionale (CCER) negli Enti sanitari (ES), oggetto della presente iniziativa, riveste una particolare rilevanza nell’ambito dell’Investimento

1.1 della missione M6C2, dedicato all’ammodernamento delle infrastrutture tecnologiche e digitali ospedaliere. Infatti, l’introduzione della CCER consente di avviare un percorso di completa digitalizzazione del percorso di ricovero e ambulatoriale del paziente, garantendo il superamento degli attuali vincoli tecnologici e permettendo di accrescere il patrimonio informativo a disposizione degli utenti clinici.

In questo senso, la CCER abilita anche l’avvio di iniziative per la maggiore e più semplice diffusione dei dati clinici sia all’interno dell’ente che a livello di FSE del cittadino. Inoltre, l’evoluzione della CCER è sinergica e strettamente connessa ad altre aree di finanziamento del PNRR che coinvolgeranno il settore sanitario, quali ad esempio i fondi per potenziare la rete a Banda Ultra Larga e le connessioni Wi-Fi (interventi abilitanti) e, i già citati, servizi di Telemedicina e territorio digitale.

In quest’ottica, l’esigenza di introduzione di Sistemi di Cartella Clinica Elettronica è stata manifestata dagli Enti Sanitari, nell’ambito dei progetti per i finanziamenti richiesti per l’attuazione del Piano Nazionale di Ripresa e Resilienza (PNRR).

Questa iniziativa si inserisce anche nel contesto del Piano triennale di Sanità Digitale della Regione Abruzzo 2021-2023 (PSD), recepito con determina direttoriale DPF/24 del 10 novembre 2020 avente

ad oggetto “Criteri generali per la redazione del Piano Strategico della Sanità della Regione Abruzzo 2021-2023”, disciplinante le linee di sviluppo ed evoluzione dei sistemi sanitari regionali e contenente i principi e gli obiettivi da sviluppare. Su questo piano si è cercato di porre le basi per lo sviluppo del sistema informativo sanitario, in costante evoluzione, al cui interno andrà a porsi la soluzione di CCER. Al fine di poter garantire l’adattabilità al contesto evolutivo del sistema informativo dettato dal Piano di Sanità Digitale (PSD), la CCER dovrà tener in considerazione gli eventuali adeguamenti ed integrazioni che dovessero risultare necessari nel corso degli anni del contratto esecutivo. Il dettaglio degli stessi verrà riportato nei capitoli successivi.

2.2. Obiettivi e contenuti dell’iniziativa

La presente iniziativa ha l’obiettivo di dotare gli Enti Sanitari abruzzesi di un servizio regionale per l’introduzione ed evoluzione di una soluzione di Cartella Clinica Elettronica Regionale (CCER) a supporto delle attività assistenziali nei reparti di cura e nelle aree ambulatoriali di ambito ospedaliero.

L’iniziativa si pone l’obiettivo di accelerare il processo di trasformazione digitale in ambito ospedaliero, favorire l’innalzamento della qualità dei servizi e ottimizzare i principali processi clinici. Gli obiettivi principali dell’iniziativa sono i seguenti:

• Implementare gradualmente una nuova architettura dei sistemi informativi regionali che superino l’attuale eccessivo frazionamento e disomogeneità dei sistemi di livello locale e favoriscano l’interoperabilità e la valorizzazione dei dati in tutta la Regione;

• Promuovere la completa e nativa digitalizzazione dei processi ospedalieri con eliminazione del supporto cartaceo e produzione di dati e documenti digitali originali a pieno valore legale;

• Favorire l’ottimizzazione dei processi ospedalieri e abilitare una maggiore integrazione dei percorsi di cura e assistenza tra l’ambito ospedaliero e quello territoriale;

• Supportare la progressiva standardizzazione dei processi ospedalieri a livello interaziendale e favorire l’adozione e l’ampia diffusione delle best practice;

• Incrementare il livello di sicurezza dei processi ospedalieri e ridurre il più possibile il rischio per i pazienti in ambito ospedaliero;

• Assicurare la completa tracciabilità delle operazioni compiute in ottica di massima trasparenza e tutela per la sicurezza e la salute dei pazienti;

• Abilitare lo scambio strutturato di dati tra le diverse organizzazioni in diversi contesti (es. cambi di regime, informazioni relative ai percorsi ambulatoriali);

• Abilitare e promuovere l’analisi strutturata dei dati raccolti durante i percorsi di cura dei pazienti ospedalieri con utilizzo delle informazioni a livello locale e regionale;

• Condividere i dati di interesse regionale e nazionale in modo nativo e semplificato.

Considerando gli applicativi già esistenti e le diverse necessità che gli ES potrebbero avere, la soluzione di Cartella Clinica Elettronica deve essere presentata, in fase di offerta tecnica, con due approcci differenti in grado di:

• Poter coprire le necessità delle singole Unità Operative (UO) specifiche (per esempio, cartella clinica diabetologica, anestesiologica, infermieristica, etc.). Rimane necessaria la rispondenza alle richieste funzionali e non funzionali esplicitate nei paragrafi 4 e 5.

• Poter coprire le necessità di più UO, proponendo moduli ed insiemi differenti di funzionalità soddisfatte, secondo le richieste e le modularità esplicitate al capitolo 4 dei requisiti funzionali e 5 dei requisiti non funzionali.

2.3. Estensione complessiva e orizzonte temporale dell’iniziativa

Il progetto è rivolto, con le modalità descritte nei capitoli successivi, prioritariamente agli Enti Sanitari che non dispongono di una CCER all’interno della propria organizzazione e agli Enti che hanno implementato progetti circostanziati o dispongono di un sistema di CCE basato su tecnologie non più adeguate, affinché venga uniformata la disponibilità della CCER all’interno deli ES con strumenti avanzati e adeguati alle necessità di ciascun ES e di Regione.

Di seguito sono descritte le attività, estese su di un arco temporale di 48 mesi, che il Fornitore sarà tenuto a svolgere per ogni ES in cui inserirà la nuova soluzione CCER:

1. Assessment, parametrizzazione, redazione e approvazione di un Documento Progettuale di Dettaglio (DPD), configurazione della soluzione CCER, nonché i relativi test e collaudi.

Si avvia la diffusione della soluzione presso due prime ASL e si avvia il processo di formazione al personale.

2. Formazione, avviamento e completamento della diffusione della soluzione presso le due ultime ASL;

3. Gestione a regime della soluzione.

Durante le attività previste nelle diverse fasi sarà fondamentale il continuo confronto con i referenti dell’ES, al fine di mantenere costantemente allineati gli obiettivi dell’intervento con le esigenze raccolte.

La Tabella seguente riassume le tempistiche previste per la realizzazione di tali attività, che sono approfondite nel capitolo 10.


Tempistiche previste per la realizzazione delle attività
Elapsed dall’avvio del progetto	Fase progettuale
Entro il mese 6	Assessment, Parametrizzazione, Stesura del Documento Progettuale di Dettaglio (DPD), Configurazione, Test e Collaudo, Avviamento alla diffusione e del processo di formazione
	Test e collaudo dell’installazione
	Formazione, avviamento della diffusione nelle prime due ASL aziendali.
Entro il mese 24	Formazione, avviamento e completamento della diffusione della soluzione nelle restanti ASL.
Fino al termine della fornitura	Gestione a regime della soluzione

Tabella 1: Tempistiche previste per la realizzazione delle attività

2.4. Strategia di sourcing ed ES interessati

Di seguito è riportato l’elenco degli ES interessati e l’impianto contrattuale su cui si articola la Fornitura all’interno del lotto unico.

Lotto unico

Enti Sanitari interessati dall’iniziativa
#	ENTE SANITARIO
1	Regione Abruzzo
2	ASL Avezzano-Sulmona-L’Aquila
3	ASL Lanciano-Vasto-Chieti
4	ASL Pescara
5	ASL Teramo

Tabella 2: Enti sanitari Interessati dall'iniziativa

L'impianto contrattuale con il Fornitore individuato sarà organizzato mediante un contratto esecutivo aziendale diretto, dove ogni ASL stipulerà in autonomia il contratto col il fornitore aggiudicatario. 1

1 trattandosi di accordo quadro si precisa che saranno le singole ASL a sottoscrivere i rispettivi contratti esecutivi per i servizi base previsti nell’appalto. Il lotto è unico in quanto per le specifiche della soluzione richiesta non può non aversi un unico interlocutore per le 4 aassll regionali.

3. OGGETTO DELLA FORNITURA

3.1. Descrizione della soluzione

La Fornitura comprende quanto necessario per diffondere, gestire e mantenere la soluzione applicativa della CCER prescelta basata su un’unica tecnologia che verrà integrata con il SI ospedaliero dei vari ES.

Il modello della soluzione proposta prevede l’introduzione di soluzioni applicative, modulari e personalizzabili in modo da garantire la loro reciproca interoperabilità, nonché la loro integrazione con altri sistemi informativi ospedalieri già in essere nei singoli ES. Tali soluzioni dovrebbero garantire un supporto funzionale ai percorsi di ricovero e ambulatoriali già definiti all’interno delle singole strutture ospedaliere e al contempo esplicare funzionalità specifiche, e sempre personalizzabili, in modo tale da poter fornire supporto specialistico nelle diverse unità operative.

Per soddisfare tali requisiti, la soluzione richiesta dovrà:

1. Configurarsi come una cartella clinica trasversale, che garantisca i livelli di servizio comuni ad ogni unità operativa, attraverso funzionalità che permettano la raccolta e la gestione di informazioni cliniche del paziente e dei principali processi sanitari (ambulatoriali e di ricovero).

2. Presentarsi come una soluzione modulare altamente personalizzabile, in modo tale da poter essere integrata nelle unità ospedaliere ed essere personalizzata sulla base delle specifiche esigenze cliniche.

3. Garantire la possibilità di inserimento di moduli funzionali atti a portare allo stesso livello di interoperabilità le diverse unità ospedaliere degli ES, laddove esistano soluzioni di CCER già adottate, nell’ottica di promuovere l’interoperabilità delle strutture sanitarie all’interno della regione Abruzzo.

Sulla base dei punti sopra evidenziati, sono state individuate le seguenti configurazioni base della CCER:

• CCER di ricovero e ambulatoriale

• Order Entry

• Farmacoterapia

• Blocco Operatorio

Inoltre, la Fornitura dovrà altresì prevedere l’erogazione, quale componente opzionale, del modulo di gestione territoriale attivabile dall’ES in sede di esecuzione contrattuale.

La Fornitura, in base alla configurazione di servizio scelta dall’ES, dovrà svolgere le seguenti attività:

• Assessment, parametrizzazione, configurazione, collaudo e test della CCER;

• Diffusione della soluzione CCER;

• Gestione a regime della CCER.

La Fornitura dovrà altresì prevedere l’erogazione di eventuali servizi applicativi a richiesta, attivabili dall’ES in sede di esecuzione contrattuale che include per esempio la manutenzione evolutiva aggiuntiva rispetto alle giornate definite per la piccola MEV. Le caratteristiche degli elementi di Fornitura sono dettagliatamente descritte nei Capitoli successivi.

Infine, ciascun ES potrà valutare l’estensione della soluzione su ulteriori discipline sulla base della loro specifica realtà clinica. Il Fornitore dovrà quindi, al termine della presente gara, stabilire con ciascun ES gli aspetti tecnici, economici e contrattuali legati alla possibilità di verticalizzazione della soluzione.

3.2. Introduzione della soluzione

Al fine di favorire una introduzione graduale e flessibile, la CCER deve disporre di un nucleo applicativo e funzionale comune a tutte le aree dell’organizzazione e di sezioni adattabili alle esigenze specifiche delle singole discipline specialistiche, coerenti con logica complessiva del sistema. L’introduzione di una soluzione di CCER potrà avvenire mediante due possibili approcci, la cui scelta è a carico del fornitore, da definire sulle base dei driver indicati successivamente.

1. Approccio orizzontale (Figura 1): ciascun modulo funzionale viene rilasciato trasversalmente all’intera organizzazione e, dopo averne testato e rifinito il funzionamento, si procede all’introduzione del successivo. È auspicabile in tal caso creare una base di funzionalità di partenza che rendano lo strumento il più semplice e flessibile possibile. In particolare, il primo rilascio deve presentare tutte le caratteristiche di base pur restando aperto all’introduzione di funzionalità evolute.

Figura 1: Introduzione CCER - Approccio orizzonta

2. Approccio verticale (Figura 2): all’interno di una o più unità operative si implementa un pilota completo della CCER che, in seguito all’analisi dei feedback, viene raffinato e successivamente esteso all’intera organizzazione. Il pilota non deve restare un esperimento isolato e specialistico, ma deve essere collocato in una strategia complessiva e coinvolgere l’intera organizzazione.

Figura 2: Introduzione CCER- Approccio verticale

Si specifica che non è identificabile un approccio migliore a priori, la scelta dell’approccio è guidata dai seguenti driver:

• Caratteristiche generali dell’organizzazione;

• Criticità e bisogni percepiti come prioritari;

• Obiettivi e ampiezza dell’intervento che si prevede di attuare e risorse disponibili;

• Struttura dell’architettura esistente e degli applicativi già presenti in azienda.

Nel seguito si evidenziano alcuni punti di attenzione che è necessario considerare nell’introduzione e diffusione di una soluzione CCER:

• Analisi dei processi assistenziali dell’organizzazione, con particolare focus alla comprensione delle dinamiche tra le varie figure professionali coinvolte ed ai relativi ambiti di competenza;

• Analisi della documentazione clinica attuale, dei dataset clinici, dei fabbisogni informativi insoddisfatti. Verifica dell’esistenza di un modello aziendale che, fatte salve singole personalizzazioni, faccia riferimento a modelli concettuali consolidati;

• Individuazione e comprensione delle dinamiche con cui le informazioni cliniche vengono prodotte, elaborate, scambiate e quindi acquisite in Cartella Clinica. Questo è fondamentale nell’ottica di predisporre l’integrazione efficace ed efficiente del nuovo strumento aziendale nel complesso del Sistema Informativo. Allo stesso modo, gli applicativi verticali preesistenti vanno censiti in termini di varietà e funzionalità offerte, al fine di poter anticipare quanto più possibile istanze di modifica o integrazione nella piattaforma di Cartella Clinica Elettronica aziendale.

4. REQUISITI FUNZIONALI

Il presente capitolato trae, come base di partenza e include quanto definito all’interno dei requisiti minimi funzionali dell’allegato 2° Capitolato Tecnico Speciale Lotti Applicativi per le aree tematiche trattate dal lotto 2 Cartella Clinica ed Enterprise Imaging CENTRO – SUD. Le funzionalità documentali lì citate vengono ampliate nel capitolo 4.1 del presente capitolato. In aggiunta, vengono specificate nel capitolo 4.2 le caratteristiche delle funzionalità di supporto all’attività clinica e assistenziale.

Vengono inoltre esplicitati i requisiti minimi che la soluzione applicativa proposta dovrà soddisfare, al netto dei requisiti espressi nel Capitolato Tecnico Speciale dell’Accordo Quadro CONSIP “Servizi Applicativi in ambito “SANITA’ DIGITALE - Sistemi Informativi Clinico-Assistenziali” Per Le Pubbliche Amministrazioni del SSN” ed eventuali proposte migliorative e ampliative che dovessero essere presentate dai fornitori. Eventuali proposte migliorative ed ampliative saranno considerate come opzionali e, come tali, sarà facoltà di ciascun ES valutarne l’adozione. Nel contesto evolutivo della sanità abruzzese in cui si pongono gli ES e come definito all’interno del “Piano Sanità Digitale” di Regione Abruzzo per il triennio 2021-2023, non sono presenti linee guida in tema CCER comuni a tutti gli enti sanitari regionali, ma è presente una pluralità disomogenea di soluzioni CCE verticali alla singola disciplina e Unità Organizzativa.

Pertanto, nel tentativo di uniformare il parco applicativo a disposizione degli enti sanitari e garantire una soluzione applicativa che possa ottimizzare la convergenza e l’integrazione di tutti i dati clinici dei pazienti e garantire la copertura di tutti i reparti, è richiesta in fase di rilancio competitivo la presentazione di un’architettura di funzionalità applicative CCER in grado di colmare le differenze e contemporaneamente rispondere alle diverse esigenze di ciascun ES. Ciò premesso, occorre sottolineare che la soluzione proposta dovrà essere rispondente alle specifiche architetturali e applicative identificate dal SSR abruzzese e definite nell’allegato B “Strategia digitale della Sanità della regione Abruzzo”. La soluzione CCER deve quindi potersi adattare al contesto evolutivo di riferimento della SSR.

Dal punto di vista funzionale, la CCER dovrà configurarsi come una soluzione trasversale (rappresentata verticalmente in figura) che garantisca funzionalità di carattere generali grazie a cui sia possibile la raccolta di informazione e la gestione dei percorsi clinici-terapeutici del paziente.

Accanto a tali funzionalità di base, occorre garantire la possibilità di inserire dei moduli verticali (rappresentati orizzontalmente in figura) dedicati alle unità operative specialistiche. Tali funzionalità dovranno essere in linea generale sempre adattabili e personalizzabili a seconda delle specifiche esigenze dell’unità operativa dei singoli ES.

Infine, la CCER dovrà integrarsi con i sistemi informativi in essere, tra cui, da un lato, i sistemi dedicati alla gestione dei percorsi clinici terapeutici del paziente (ADT, OE, percorsi terapeutici, etc.) dall’altro, con i sistemi di cartelle cliniche elettroniche laddove siano già presenti.

Funzionalità Generali (ambulatoriali e ricovero)

CUP

Lo schema seguente mostra un esempio del modello della cartella clinica elettronica richiesta:

Opzionale, attivabile su richiesta dei singoli ES

CCER

Gestione Territoriale

ADT

Gestione della farmacoterapia

Gestione del blocco operatorio

Order Entry

Cartella clinica endoscopica

Cartella clinica diabetologica

Cartella clinica nefrologica

Cartella clinica cardiologica

Out of scope

Mandatorio

….

Repository Documentale

Firma Digitale

Figura 3: Modello CCER

4.1. Funzionalità di carattere generale

Nel presente paragrafo vengono specificate le funzioni di carattere generale che la CCER dovrà presentare, intese quindi come moduli applicativi base comuni a tutte le unità operative, che garantiscono la corretta erogazione delle cure terapeutiche-assistenziali.

4.1.1. Visualizzazione delle informazioni del paziente

La soluzione proposta deve poter garantire la visualizzazione di tutte le informazioni utili alla gestione del processo diagnostico-terapeutico-assistenziale.

La soluzione deve prevedere la possibilità di gestione dei pazienti in modalità anonima, quindi deve essere in grado di:

• Recepire da ADT o CUP l’informazione di accettazione con indicazione di gestire il paziente in formato anonimo e l’identificativo indicato dal cittadino/paziente da presentare al personale di reparto;

• Evidenziare nel sistema e in tutta la documentazione prodotta (ad es. lettera di dimissione) il fatto che il paziente è anonimizzato;

• Permettere la riconciliazione con i dati anagrafici nel caso in cui il paziente decida successivamente di rivelare la propria identità;

4.1.2. Accesso alla documentazione clinica

La CCER deve consentire, nel rispetto dei vincoli della Privacy, la consultazione unitaria delle informazioni contenute nel repository interno dell’ES, laddove presente, e ad altri sistemi attualmente collegati, come ad esempio il FSE, fornendo così una visione sullo storico delle problematiche del paziente. Al fine di garantire la facilità d’uso di tale sistema da parte del sanitario, dovrà essere integrata un’opportuna funzionalità di navigazione e ricerca.

4.1.3. Order Entry

Il modulo di Order Entry permette, direttamente dalle interfacce della CCER, di inserire richieste di prestazione (ordini) verso i dipartimentali (RIS, LIS,…) e tracciarne l’evoluzione fino all’esito, permettendo di visualizzare l’esito documentale e/o strutturato, all’interno della CCER.

La CCER deve garantire la possibilità di integrazione con moduli di order entry presenti nelle aziende o di futura adozione, tramite integrazioni standard (WS, API, HL7, FHIR ...) e l’utilizzo di nomenclatori aziendali/regionali specifici. Oltre a tale possibilità, deve mettere a disposizione, delle Aziende che ne facciano richiesta, uno specifico modulo di order entry, pienamente integrato alla CCER. Tale modulo dovrà permettere l’adozione delle codifiche aziendali e regionali oltre all’integrazione con i dipartimentali aziendali per la gestione degli ordini.

Le funzionalità minime richieste includono la possibilità, all’interno della CCER di creare ordini, appuntamenti e visualizzarne.

4.1.4. Sistema di refertazione vocale

Tra le funzionalità trasversali del CCER, rientrano quelle relative ai sistemi di refertazione vocale. 2

Si richiede un sistema di riconoscimento vocale per lo sviluppo della refertazione clinica che presenti le seguenti caratteristiche:

• Multicanale, ossia il riconoscimento vocale potrà essere utilizzato da qualsiasi dispositivo, mobile o fisso, e dovrà essere compatibile con qualsiasi sistema operativo.

• Multimodale: ossia l’acquisizione della voce potrà avvenire attraverso qualsiasi tipologia di microfono, anche wireless.

• Multidisciplinare: il sistema dovrà essere integrato ad un vocabolario multidisciplinare completo, personalizzabile, per l'utilizzo in qualsiasi reparto o dipartimento, attraverso cui riconoscere e individuare i vocaboli clinici specialistici.

Il fornitore dovrà mettere a disposizione una gamma di vocabolari medici in modo gratuito a tutte le unità specialistiche in cui la CCER verrà installata, fermo restando che ogni unità potrà richiedere l’aggiunta di uno o più vocabolari.

2 L’automatismo citato non si intende come sostitutivo della verifica del documento da parte dell’utilizzatore. Si riportano a titolo esemplificativo alcuni possibili utilizzi del sistema:

(1) Verifica sintattica;

(2) Evidenziazione di codifiche utilizzate.

• Verifica del referto: il sistema dovrà inoltre garantire la produzione dei referti secondo modelli personalizzabili, sia in maniera differita che diretta. Dovrà essere garantita la possibilità di revisione del referto, automatica che non.

4.1.5. Gestione ricoveri

La CCER deve consentire la gestione completa di tutte le fasi previste dal processo di ricovero - ospedaliero, a partire dal momento di accettazione fino alla fine di dimissione del paziente (compresi eventuali trasferimenti interni).

In particolare, la CEE dovrà permettere la gestione di almeno:

1. Dismissioni del paziente:

Al momento delle dimissioni, dovrà essere rilasciato al paziente un documento elettronico legalmente sostitutivo della Cartella Clinica di Ricovero, ai fini sia della conservazione a norma di legge della stessa sia come documento con valore probatorio, sostitutivo, quindi, a tutti gli effetti della cartella clinica cartacea.

Laddove non sia possibile il rilascio della Cartella Clinica di ricovero, al momento della dimissione, ad esempio nel caso in cui alcuni esami diagnostici non fossero completi, il sistema dovrà permettere l’emissione di una Lettera di Dimissione o equivalente che faccia riferimento ad un eventuale documento successivo da recapitare al curante e al paziente. La chiusura formale potrà quindi avvenire anche dopo l’uscita del paziente dal luogo di cura.

Al fine della compilazione della Scheda Dimissione Ospedaliera (SDO), la cartella clinica dovrà inviare le opportune informazioni al sistema Accettazione Dimissione Trasferimento (ADT), secondo quanto richiesto più specificatamente nell’ ALLEGATO 2A - CAPITOLATO TECNICO SPECIALE - LOTTI APPLICATIVI 1-2-3-4.

Dal punto di vista clinico, il sistema dovrà prevedere la possibilità di raggruppare le funzionalità della Cartella Clinica Elettronica relative alla fase principale dell’assistenza di ricovero, compresa la gestione delle attività di pre-ricovero. Tutte le informazioni relative a un paziente dovranno essere inoltre presentate all’utente in maniera cronologica, chiara e unitaria, con possibilità di collegamento ad altri moduli della CCER ove necessario.

In particolare, la CEER dovrà permettere la gestione di almeno:

1. Valutazione infermieristica paziente all’ingresso, ossia:

• La valutazione clinica generale, con il supporto di opportune scale di valutazione configurabili dall’utente

(ad es. scale basate su EWS, screening nutrizionale, scale specifiche per specialità, autonomia paziente, rischi di caduta, valutazione del dolore, etc.)

• La valutazione dei bisogni assistenziali del paziente

(ad es. necessità di respirazione), nonché dei bisogni indotti dal processo diagnostico terapeutico (ad es. esecuzione prescrizioni diagnostiche);

• La determinazione di un piano assistenziale

2. Inquadramento clinico, ossia:

• Raccolta delle ipotesi diagnostiche e dei problemi terapeutici-assistenziali

• Raccolta dell’anamnesi del paziente

• Consentire la strutturazione ed il livello di dettaglio dell’anamnesi a seconda della

specialità/patologia e dalla peculiarità del caso, nonché l’aggiornamento della stessa per campi diversi, ogni qualvolta le variate condizioni cliniche dell’assistito lo richiedano;

• Raccolta delle evidenze a seguito dell’esame obiettivo

• Definizione piano terapeutico-assistenziale

• Consentire l’inserimento di blocchi di testo libero e formattabile, relativi alle corrispondenti sezioni della modulistica, con possibilità di revisione dei campi di testo libero, in cui il clinico può associare diagnosi codificate tramite codici specialistici o ICD 9-CM/ICD 10;

In tale contesto può essere definita utile al clinico la consultazione del Patient Summary, Parte del FSE.

3. Consulenza interna, ossia:

• Consentire la creazione e indirizzamento di richieste di consulenza verso i soggetti interessati,

• Governare la pianificazione di esecuzione, tracciare lo stato di avanzamento delle richieste, avvisare/sollecitare i soggetti interessati

• Possibilità di visualizzare immagini clinici e visualizzare la refertazione medica

• Registrare la conclusione e gestirne l’esito.

Il sistema di consulenza interna dovrà inoltre essere integrato con il sistema di Oder Management, secondo quanto richiesto più specificatamente nell’ ALLEGATO 2A - CAPITOLATO TECNICO SPECIALE

- LOTTI APPLICATIVI 1-2-3-4.

Inoltre, da tutte le aree della Gestione Clinica dovrà essere possibile l’attivazione delle funzionalità di consultazione del FSE.

4. Diari clinici, ossia:

• Dettaglio delle terapie erogate

• Andamento temporale dei sintomi del paziente, eventuali complicanze, modifiche al comportamento del paziente

• Ripianificazione e aggiornamento piano terapeutico

5. Parametri vitali e fogli rilevazioni cliniche

• La registrazione e la gestione delle prescrizioni (generalmente medica) di rilevazioni periodiche dei dati a carico degli infermieri;

• La visualizzazione della sintesi dell’andamento dei parametri nel tempo e di altri dati importati, rappresentandoli in modo standardizzato così da mantenere una omogeneità di lettura a tutta la struttura sanitaria (quadro sinottico);

6. Produzione di documentazione relativa al parto e CEDAP

La CCER dovrà permettere la produzione di documentazione relativa al parto per le unità di ginecologia-ostetricia. In particolare, le funzionalità che la soluzione dovrà integrare sono:

• Acquisizione e gestione dei dati personali, anagrafici e amministrativi relativi alla madre/figlio;

• Produzione del certificato CEDAP;

• Produzione secondo template predefinito della dichiarazione di nascita;

• Storicizzazione e composizione di elenchi dei parti effettuati. Tali elenchi dovranno essere esportabili in formato pdf e stampabili;

• Produzione dei dati relativi al prelievo di sangue del cordone ombelicale;

• Produzione dei dati relativi alle IVG (Interruzione Volontaria di Gravidanza);

• Produzione della documentazione ostetrica (percorso travaglio, partogramma etc.).

In merito alle funzionalità sopracitate, saranno premiate le soluzioni che permettano l’acquisizione one-time dei dati necessari alla composizione della documentazione sopra citata e che generino la stessa in modo automatico.

4.1.6. Cartella ambulatoriale

Per quanto riguarda i requisiti della gestione ambulatoriale, è previsto che la soluzione moduli il proprio supporto non solo sulla base della complessità clinico-assistenziale dell’unità operativa, ma

anche in relazione a quelle che sono le scelte specifiche operate dall’Ente Erogatore. Sono distinte unità operative che necessitano di supporto semplice da unità operative che necessitano di supporto strutturato, come configurazioni di massima, prevedendo la personalizzazione del supporto funzionale all’interno di ogni specifica unità operativa, attraverso la predisposizione di scenari intermedi.

Tuttavia, la cartella clinica ambulatoria dovrà permette la raccolta di almeno:

1. Inquadramento clinico del paziente, tra cui principalmente:

• Motivo della visita,

• Sintesi anamnestica;

• Elenco dei problemi clinici del paziente;

• Terapie in corso.

2. Rilevazioni cliniche-infermieristiche, tra cui:

• Esiti di esami obiettivi, parametri vitali di base (pressione, temperatura corporea, etc.);

• Esiti di esami specialistici, variabili di caso in caso secondo l’unità operativa di riferimento.

3. Documentazione a supporto della chirurgia ambulatoria e anestesiologica:

• La CEE dovrà permettere la stesura e la raccolta di una relazione, da consegnare al paziente al termine della prestazione, in cui sono specificate le attività effettuate;

• La soluzione di CCER ambulatoriale dovrà consentire la valutazione preoperatoria. Tali informazioni sono relative a valutazioni preoperatorie (effettuate durante la prima visita nell’ambulatorio), alla preanestesia, alla conduzione anestesiologica e alla valutazione postoperatoria.

Per garantire le ultime due funzionalità, la CEER dovrà permettere l’accesso al verbale operatorio attraverso un’integrazione agli specifici sistemi aziendali (es. ERP) laddove esistenti.

La gestione ambulatoriale del paziente permette l’erogazione di ‘trattamenti ambulatoriali’ specialistici e no, per cui le funzionalità sotto descritte si intendono minime e generali, da dover successivamente declinare in base alla natura e alla complessità dell’unità operativa nella quale la CEE sarà implementata.

In particolare, la CEE dovrà permettere almeno la gestione di:

1. Liste di Prenotazioni e presa appuntamento:

• La CEE dovrà a riguardo integrarsi con il sistema CUP per la gestione dei pazienti e per le prese appuntamento.

2. Agende ambulatoriali, tra cui:

• Agende di carattere generale, per la pianificazione di visite nelle unità non specialistiche e per uso interno

• Agende di carattere specialistico, tra cui ad esempio: agende di palestre per riabilitazione, agende di sala infusione per uso interno.

3. Gestione dei presidi medico-chirurgici, cioè:

• Possibilità di effettuare ricerche configurabili (ad es. periodo temporale, stato CCER, ecc.) sull’intero insieme di CCER inerenti all’utilizzo di dispositivi e/o endoprotesi sia a livello di singolo dispositivo che di categoria o lotto per finalità di controlli e tracciabilità;

• Fornire una visione complessiva sullo stato generale dei dispositivi utilizzati;

• Consentire la gestione della modulistica aziendale per la segnalazione di evento avverso da dispositivo (indicazione automatica delle informazioni anagrafiche).

4. Produzione del Referto Ambulatoriale

• Possibilità di produrre referti strutturati e no; ai quali, in ogni caso, dovrà essere possibile l’applicazione della firma digitale.

• Riguardo la produzione dei referti non strutturati, essa dovrà essere possibile attraverso l’adozione di un modello prestabilito scelto o modificabile da parte del clinico;

• Riguardo la produzione dei referti strutturati la soluzione dovrà:

▪ Garantire la strutturazione dei dati e delle informazioni secondo lo standard HL7- CDA2.

▪ Permettere la raccolta e l’inserimento delle informazioni costituiti da una serie ordinata di campi, ciascuno contenente tipi predefiniti di informazioni, quali in particolare: metadati, valori numeri, booleani, alfabetici.

▪ La compilazione dei campi dovrà avvenire sia manualmente e sia, laddove possibile, attraverso l’acquisizione automatica di altri dati raccolti attraverso la stessa CCER o atri SI aziendali; dovrà inoltre essere possibile l’inserimento testuale di informazioni.

▪ Il contenuto informativo dei referti strutturati dovrà essere definito secondo le specifiche rilasciate dal Ministero della Salute: xxxxx://xxx.xxxxxxxxxxxxxxxxxx.xxx.xx/Xxxxxxxx-xxxxxxxxxxx

▪ Il sistema dovrà garantire l’integrazione con librerie di dizionari di riferimento per i campi codificati nel referto; i dizionari dovranno essere strutturati per disciplina. I dizionari dovranno supportare la codifica delle informazioni secondo lo standard ICD9-CM.

▪ Il referto clinico dovrà quindi essere prodotto nei seguenti formati:

• PDF

• PDF/A con CDA2 iniettato.

5. Gestione di colonizzazioni, infezioni e terapie antiinfettive

• La soluzione dovrà consentire l’inserimento di informazioni e la visualizzazione di tutte le informazioni in merito alle colonizzazioni, infezioni (accertate e sospette), terapie antibiotiche e antiinfettive, nonché permettere agli operatori la registrazione di ulteriori informazioni (come ad es. la necessità di isolamento, la correlazione del microrganismo con l’infezione) al fine di una miglior gestione degli eventi infettivi del paziente nonché delle attività di prevenzione e controllo delle infezioni correlate all’assistenza;

• L’importazione dei referti degli esami di microbiologia ed ematochimici;

• La correlazione (da parte del medico) dell’isolamento microbiologico a un’ipotesi diagnostica (ad es. sospetta contaminazione/colonizzazione/infezione; comunitaria/infezione correlata all’assistenza/pregressa infezione/altro ecc.)

• L’elenco delle terapie antinfettive effettuate e in corso;

• La possibilità di inserimento dell’eventuale isolamento necessario

4.2. Funzionalità di supporto all’attività clinica

4.2.1. Gestione della farmacoterapia

La soluzione proposta dovrà mettere a disposizione un apposito modulo in grado di supportare l’intero ciclo del farmaco, eventualmente integrandosi a sistemi esterni già presenti nell’ES per specifiche funzionalità (es. gestione delle trasfusioni).

Tale modulo dovrà essere parte integrante del sistema generale della CCER, sia quindi per le unità ambulatoriali che di ricovero.

In particolare, esso dovrà garantire:

1. Ricognizione farmaceutica:

• Denominazione dei farmaci e di eventuali altri prodotti prescritti o liberamente assunti, con indicazione, se nota, di eventuali terapie sperimentali, off label, etc.;

• Modalità di assunzione dei farmaci (dosaggio, frequenza, durata e via di somministrazione, etc.)

• Dati paziente (peso, stile di vita, terapie in corso) e raccolta informazioni relative ed eventuali allergie o intolleranze.

2. Riconciliazione farmaceutica:

• Sospensione delle terapie di somministrazione in corso qualora non si ritengano più idonee per il paziente

• Prescrizione di nuovi farmaci, con conferma o modifica (aggiunta, sostituzione o interruzione) di prodotti già in corso di assunzione.

3. Prescrizione farmaceutica:

• Visualizzazione del prontuario ospedaliero per indicazioni farmacologiche e monografie del farmaco;

• Prescrizione secondo il prontuario terapeutico ospedaliero, aggiornato automaticamente con quello messo a disposizione dell’ES;

• Gestione della prescrizione di farmaci che non sono inclusi nel catalogo di reparto (farmaci off-Label);

• Prescrizione in dimissione secondo il prontuario del SSN (ricette dematerializzate);

• Emissione, visualizzazione, stampa e storicizzazione delle ricette;

• Sistemi di alert in fase di prescrizione, per eventuali allergie del paziente, doppie prescrizioni per il medesimo paziente, dosaggi impropri, interazione tra farmaci prescritti, vie di somministrazione improprie per farmaco prescritto;

• Sistemi configurabili per il calcolo automatico della posologia del farmaco.

• Consentire di impostare sulla prescrizione, per ogni singolo farmaco, le seguenti caratteristiche:

o Modalità di somministrazione;

o Farmaco e principio attivo (prodotto generico relativo), in conformità con le indicazioni aziendali circa la selezione del brand/commerciale o del principio attivo;

o Forma farmaceutica (ricavata da prodotto generico relativo);

o Composizione con più farmaci in infusione;

o Dosaggio;

o Numero delle somministrazioni al giorno o per intervallo di giorni (con giorni di somministrazione e con orari di somministrazione proposti automaticamente se

impostato un piano orario di somministrazione standard da parte del personale infermieristico);

o Durata dell'infusione per farmaci iniettabili (ora inizio e ora fine);

o Durata (data inizio e data fine) della terapia;

o Campo note per il prescrittore (ad es. subordinazione della somministrazione a determinati eventi/sintomi/parametri).

• Dare la possibilità, nel caso di un trasferimento del paziente tra due reparti, di chiudere o tenere attive le prescrizioni in corso, che dovranno essere riconfermate dal medico accettante nel reparto di destinazione. Allo stesso modo, al momento di una dimissione, il sistema dovrà permettere la chiusura delle terapie in corso.

• Permettere l’importazione di contenuto circa le terapie in corso presente nei referti precedenti richiedendo una esplicita conferma degli stessi al clinico. Questo vale per ogni genere di referto ambulatoriale, foglio di trasferimento, lettera di dimissione prodotti dalla soluzione CCER o da soluzioni verticali dell’ES.

4. Somministrazione farmaceutica:

• Tracciamento (data, orario, autore) dell’avvenuta somministrazione imposta dall’infermiere;

• Tracciamento degli orari effettivi della “spunta informatizzata” della somministrazione, ossia la registrazione sulla Cartella dell’inizio o della fine delle attività di somministrazione.

Per le somministrazioni infusionali la spunta dovrà avvenire sull'orario di inizio somministrazione e sull'orario di fine somministrazione.

Per le somministrazioni complesse (ad es. cicli chemioterapici e terapie protocollate), il sistema dovrà supportare la verifica della sequenza e dei tempi di somministrazione, anche integrando sistemi di gestione delle pompe per infusione;

• Sistemi di alert in caso di somministrazioni non effettuate (ad es. in ritardo, non evase nel turno precedente) o dosaggio differente rispetto a quanto prescritto, indicando obbligatoriamente la motivazione di questa scelta.

• Di gestire della modulistica aziendale per la segnalazione di effetto indesiderato da farmaco accessibile dalla funzionalità di somministrazione e compilabile in maniera automatica con i dati di paziente e farmaco (indicazione automatica delle informazioni anagrafiche, con compilazione elettronica dei campi rimanenti e consentendo la firma digitale del documento ove previsto dalla normativa);

• Di gestire le variazioni in fase di somministrazione della terapia prescritta con richiesta di ratifica al prescrittore.

• Note automatiche per verificare che le somministrazioni terapeutiche siano tracciate all’interno del diario clinico

4.2.2. Gestione del blocco operatorio

La soluzione proposta dovrà mettere a disposizione un apposito modulo in grado di supportare l’intero ciclo operatorio, e dovrà in generale presentare le seguenti funzionalità:

1. Gestione Liste di attesa chirurgiche, ossia:

• Prevedere una funzionalità di gestione delle liste d’attesa chirurgiche specifica che, parallelamente, vada ad alimentare le liste d’attesa dei ricoveri, permettendo all’operatore la possibilità di gestire informazioni proprie del percorso chirurgico;

• Consentire di ottenere strumenti di visualizzazione di liste organizzate per periodo, patologia, tipologia di intervento, classi di priorità;

• verificare la disponibilità dei posti letto, tutto ciò per una più armonica gestione del percorso chirurgico pre-operatorio.

• visualizzazione, ordinamento e stampa di liste organizzate almeno secondo i seguenti criteri: specialità chirurgica, regime di ricovero, periodo, tipologia di intervento, classi di priorità, stato del percorso, blocco e specifica sala operatoria;

2. Programmazione e Gestione Sale Operatorie, ossia:

• registrare ed ordinare le richieste di intervento chirurgico secondo la disponibilità delle sale operatorie;

• gestire e visualizzare la priorità e il tipo di intervento;

• assegnare all’intervento la durata stimata per operatori, per tipologia ed altri parametri individuabili in sede di prenotazione.

• attribuire diverse proprietà a ciascun tipo di intervento quali checklist specifiche per paziente, il tempo medio di occupazione sala, consumi standard previsti, se è previsto l’uso di apparecchiature specifiche, kit di sterilizzazione e tutti quegli elementi che contribuiscono ad una corretta programmazione delle sedute operatorie;

• possibilità di definire per ogni sala operatoria gli orari di inizio e fine attività e di personalizzare l’attività chirurgica svolta per disciplina;

• sistema di supporto all'attività di programmazione del blocco operatorio attraverso strumenti che consentono di razionalizzare ed organizzare le richieste misurando il livello di occupazione delle sale;

• gestione del versioning ovvero ogni step del processo in particolare proposte, richieste e interventi devono poter essere riversionati mantenendo lo storico nelle versioni precedenti.

• Integrazione con i sistemi di approvvigionamento del materiale operatorio;

• Integrazione con sistemi di controllo e tracciamento del consumabile operatorio.

3. Produzione della Documentazione operatoria

Il verbale di ogni intervento costituisce parte integrante e rilevante della Cartella Clinica, nella quale dovrà sempre essere compresa una copia di tale verbale qualunque siano le modalità della sua tenuta. Il verbale operatorio dovrà essere informatizzato attraverso un apposito applicativo di gestione delle sale operatorie e di acquisito/reso integrato con l’applicativo di CCER.

Nella CCER è quindi necessaria l’attivazione di procedure a salvaguardia della sicurezza del paziente in sala operatoria rispetto alle quali si dovrà dare evidenza nel verbale operatorio e/o nella Cartella anestesiologica delle attività compiute prevedendo alert e stop in caso di comportamenti non sicuri.

Il sistema dovrà dunque garantire:

• Un’integrazione con l’EPR aziendale per poter accedere al verbale tramite applicativo di CCER;

• Compilazione supportata del verbale con l’indicazione automatica delle informazioni anagrafiche, importando in un unico campo di testo libero, pre-strutturato in sezioni e con possibilità di formattazione, informazioni cliniche essenziali e la descrizione completa dell’intervento, e fornendo al medico la possibilità di modificare o integrare quanto importato (nel caso in cui la compilazione del verbale sia demandata all’applicativo di CCER);

• L’interazione con il sistema di gestione del consenso informato per la visualizzazione dell’avvenuta espressione del consenso informato del paziente/autorizzazione a procedure rischiose, anche attraverso avviso;

• La registrazione dell’orario di uscita dal reparto e l’orario di rientro dal Blocco Operatorio dopo l’intervento;

• Il rispetto del format standard aziendale e la firma digitale del documento;

• La possibilità di stampa dell’ultima versione valida della documentazione anestesiologica per il paziente, con le diciture legali di rito;

• Funzionalità di importazione e storicizzazione dell’ultima versione del documento in CCER, in forma strutturata per campi con possibilità di trasferire le informazioni contenute ad altri fogli clinici;

• La presenza di un modulo di gestione checklist chirurgiche.

4. Documentazione anestesiologica

La CCER dovrà fornire funzioni per registrare le informazioni relative alla scheda anestesiologica preoperatoria o comunque per acquisirle tramite integrazione con un altro applicativo che le gestisca. La documentazione anestesiologica racchiude complessivamente le informazioni relative alla valutazione preoperatoria, alla preanestesia, alla conduzione anestesiologica e alla valutazione postoperatoria.

La valutazione preoperatoria dovrà considerare i problemi ragionevolmente prevedibili a carico del paziente, con assegnazione dello stesso a una classe di rischio, e individuare la tecnica anestesiologica più appropriata. Quanto occorso durante l’anestesia dovrebbe tradursi in un’apposita registrazione, cronologicamente definita, comprendente, oltre agli estremi identificativi del paziente e del ricovero, anche:

• Dati sull’intervento e sull’equipe chirurgica;

• Tipo di anestesia utilizzato ed eventuali modifiche resesi necessarie;

• Tipo di supporto respiratorio;

• Procedure invasive poste in essere;

• Parametri vitali monitorati (monitoraggio intraoperatorio compreso);

• Indicazione di nome, dose, vie e ora di somministrazione dei farmaci utilizzati;

• Segnalazione di eventuali complicanze.

La valutazione postoperatoria dovrà indicare:

• Le condizioni (respiratorie, cardiocircolatorie, neurologiche) del paziente;

• Il tipo di sorveglianza necessaria nel post-operatorio;

• La segnalazione degli accessi vascolari e di altri mezzi invasivi presenti e il loro stato;

• Le terapie in corso e quelle consigliate nel post-operatorio;

• Gli esami di controllo necessari ed i parametri da monitorare;

• Ora/minuti della dimissione dal blocco operatorio, o da diverso ambiente di intervento, e trasferimento al reparto di degenza.

Il sistema dovrà fornire le seguenti funzioni:

• Possibilità di registrare le informazioni relative alla scheda anestesiologica preoperatoria (incluse le intra- e post-operatorie) o comunque per acquisirle tramite integrazione con un altro applicativo che le gestisca (ad esempio il sistema gestionale delle Sale Operatorie o

altro). In quest’ultimo caso, la scheda anestesiologica preoperatoria va comunque resa accessibile dall’applicativo di CCER attraverso una integrazione all’EPR aziendale. Nel primo caso, invece, il livello minimo di gestione informatizzata è costituito dalla importazione automatica delle informazioni anagrafiche e dalla registrazione delle informazioni anestesiologiche;

• Possibilità di espressione del consenso informato del paziente/autorizzazione a procedure rischiose e di verifica automatica della registrazione dell’espressione di consenso da parte del paziente;

• Rispetto del format standard aziendale e la firma digitale del documento;

• Possibilità di stampa dell’ultima versione valida della documentazione anestesiologica per il paziente, con le diciture legali di rito;

• Strutturazione dei singoli inserimenti in più campi tematici di testo libero con opportunità di revisione, distinguendo tra i temi delle note;

• Gestione di frasi standard per il supporto alla compilazione;

• Garantire l’importazione dei contenuti da altri fogli clinici in campi tematici di testo libero con opportunità di revisione, distinguendo tra i temi delle note;

• Possibilità di importazione e storicizzazione dell’ultima versione del documento, in forma strutturata per campi con la possibilità di trasferire le informazioni contenute ad altri fogli clinici;

• Gestione evoluta della compilazione area per area con maschere dedicate di compilazione strutturata, precompilate sulla base delle informazioni disponibili nei fogli clinici di riferimento;

• Presenza di un modulo di gestione checklist anestesiologiche.

4.2.3. ADT (Accettazione Dimissione Trasferimento)

Il modulo ADT, integrato nella soluzione di CCER, ha la responsabilità di gestire i processi di accesso al ricovero (liste di attesa), la movimentazione del paziente ricoverato (accettazione, dimissione, trasferimento), la comunicazione ai reparti dell’avvenuta accettazione, la registrazione dell’esito del ricovero ricevuta dai reparti e la rendicontazione dei ricoveri.

Il sistema di ADT si integra con eventuali moduli già presenti nelle Aziende a servizio delle unità eroganti dell’Azienda (Ambulatori, Laboratorio, etc.) e i reparti di ricovero tramite l’utilizzo di flussi e linguaggi standardizzati.

In particolare, l’applicativo dovrà garantire le seguenti funzionalità:

• Acquisizione dei dati pazienti al fine di garantire l’apertura della scheda SDO e visualizzazione della storia clinica dello stesso, intesa come visualizzazione dei precedenti episodi di ricovero;

• Stampa di quanto necessario al termine dell’inserimento del ricovero (es. braccialetto o altro mezzo identificativo, etichette con barcode, report di accettazione, frontespizio per, eventualmente, la composizione della cartella clinica cartacea, ecc.);

• Somministrazione e acquisizione di consensi informati al paziente;

• Gestione dei ricoveri programmati, in elezione e in modalità di urgenza;

• Generazione e gestione di liste d’attese per il ricovero, aggiornabili in tempo reale da più utenti e possibilità di classificare i ricoveri secondo gradi di urgenza configurabili;

• Possibilità di organizzare le liste di attesa per periodi, patologie, classi di priorità;

• Calcolo e visualizzazione della disponibilità di ricoveri;

• Calcolo dei tempi di attesa dei ricoveri

• Ricerca dei ricoveri in atto nonché di quelli precedentemente effettuati; i risultati di tale ricerca dovranno poter essere visualizzati in maniera chiara, sintetica attraverso la generazione di grafici riassuntivi;

• Gestione dei posti letti, sia ordinari che “in barella” o “in appoggio”;

• Gestione dei trasferimenti tra reparti, con possibilità di tracciare gli spostamenti del paziente;

• Registrazione della dimissione o del decesso del paziente;

• Calcolo automatico / assistito del DRG e dell’importo del ricovero;

• Compilazione e validazione della SDO e invio dei dati verso i sistemi informativi a valle secondo i processi già in essere nelle singole strutture sanitarie;

• Analisi statistiche e presentazione dei risultati (in report esportabili e stampabili) su accessi, ricoveri, dimissioni, ecc., tramite selezione di parametri temporali, di reparto/struttura o altre variabili (es. casistica, criteri economici, ecc.) tali statiche dovranno garantire la defezione di indicatori di prestazione tra cui, ad esempio, il piano nazionale esiti. I risultati e le analisi statiche dovranno essere inviati automaticamente ai sistemi informativi a valle;

• Estrazione dagli archivi campioni di SDO ed analisi delle SDO per evidenziare errori o SDO a rischio di inappropriatezza (LEA) o di sospetta incongruità con la cartella clinica, tramite analisi della codifica ICD9-CM, di DRG, MDC, del regime e tipo di ricovero, ecc.

5. REQUISITI NON FUNZIONALI

Nel presente Capitolo si descrivono le caratteristiche non funzionale che la soluzione CCER dovrà soddisfare.

5.1. Aderenza a standard

Dal punto di vista di standard dati riveste, come meglio descritto nel paragrafo successivo, una particolare rilevanza lo standard FHIR per la strutturazione delle informazioni cliniche. Tale standard dovrà essere il riferimento per garantire l’interoperabilità e lo scambio delle informazioni cliniche.

Per quanto riguarda gli standard funzionali, l’Electronic Health Record System (rif. HL7 EHR TC) dovrà essere il punto di riferimento per la definizione delle funzionalità che devono essere presenti nella Cartella Clinica Elettronica.

In termini di codifiche, la soluzione dovrà supportare i seguenti standard semantici:

▪ ICD-9-CM – International Classification of Diseases – Classificazione Internazionale che organizza le malattie e i problemi correlati

▪ LOINC – Logical Observation Identifiers Names and Codes - Classificazione univoca di osservazioni cliniche e di laboratorio

▪ AIC – Autorizzazione all’immissione in commercio - Indice univoco di prodotti farmaceutici autorizzati dall’AIFA o da CE

▪ ATC – Anatomica Terapeutica Chimica - Classificazione anatomico terapeutica e chimica dei famaci

▪ SNOMED CT ed OMOP.

Per gli standard sintattici, oltre alle differenti componenti di HL7 che supportano la messaggistica tra applicazioni sanitarie presenti in azienda, dovrà essere soddisfatto lo standard DICOM (Digital Imaging and COmmunications in Medicine) per i criteri per la comunicazione, la visualizzazione, l'archiviazione e la stampa di informazioni ed immagini di tipo biomedico.

5.2. Certificazione come dispositivo medico (MDR)

Il Sistema CCER deve essere predisposto per essere sottoposto ai percorsi previsti dalla normativa vigente per acquisire la certificazione come dispositivo medico (certificazione MDR). Il nuovo Regolamento Dispositivi Medici MDR 2017/745 è entrato in vigore il 26 maggio 2021 abrogando la Direttiva 90/385/CEE (AIMDD) e la Direttiva 93/42/CEE (MDD).

Il software di CCER oggetto di fornitura rientrante, secondo la normativa vigente, nella categoria di Software as a Medical Device (SaMD) dovrà essere già certificato MDR nella classe opportuna al

momento del collaudo del pilota. La mancata certificazione nella fase di collaudo sarà ritenuta grave adempienza contrattuale e comporterà la risoluzione del contratto.

Il Fornitore deve garantire la validità della certificazione per tutta la durata contrattuale, pena la risoluzione del contratto. In caso di MEV il Fornitore si impegna a garantire le attività atte al conseguente aggiornamento della certificazione MDR.

5.3. Interoperabilità

Rispetto ai Sistemi Informativi dei singoli ES, la CCER si dovrà integrare con i sistemi dipartimentali erogatori interni all’ES per quanto concerne la comunicazione delle liste di lavoro, liste degli interventi, l’aggiornamento delle agende, la rendicontazione delle prestazioni effettuate e l’eventuale comunicazione della richiesta di oscuramento volontario da parte dell’assistito e l’invio dei dati disponibili alla CCER per la registrazione delle attività effettuate durante gli accessi di pre‐ ricovero, ricovero e ambulatoriale. Durante la fase d’integrazione si dovrà avere massima attenzione sul concetto di “riuso dei software” ove possibile. Di seguito sono riportate le principali applicazioni deputate all’integrazione con la soluzione CCER:

• Anagrafica centrale e basi dati aziendale;

• Il sistema aziendale di profilazione ed autenticazione;

• Repository documentale aziendale;

• CUP;

• Order Management;

• Gestione della diagnostica multimediale (RIS/PACS);

• LIS;

• Anatomia patologica;

• Trasfusionale;

• Logistica del farmaco;

• Il sistema preposto per il calcolo del DRG;

Inoltre, la soluzione dovrà essere predisposta per essere interoperabile con il Fascicolo Sanitario Elettronico nazionale 3 ed il Sistema TS che ogni ASL potrà integrare con la nuova soluzione o utilizzare i moduli di quest’ultima (es. Blocco operatorio).

La soluzione dovrà inoltre essere completamente interoperabile con il FSE 2.0, per cui dovrà essere possibile la produzione di dati e di documenti anche secondo i requisiti dettati dalle linee guida di

3 xxxxx://xxx.xxxxxxxxxxxxxxxxxx.xxx.xx/xxxxxxxxxx-xxxxxxxxxxxxxx-xxxxxxx-xxxxxxxxxxxxxxxx-xxx

riferimento 4. Ossia, la CCER dovrà:

▪ Garantire la produzione ed elaborare dati in formato FHIR;

▪ Garantire la produzione e l’elaborazione dei documenti in formato PDF/A HL7 CDA2 iniettato, con la possibilità di applicare la firma digitale in formato PADES.

Inoltre, la soluzione dovrà integrarsi con tutti gli ulteriori applicativi individuati dagli ES.

Infine, particolare rilevanza riveste la gestione delle integrazioni della soluzione con le CCE verticali laddove già presenti. A tal proposito, dovranno essere garantiti i seguenti scenari:

• L’integrazione tra la soluzione CCER e CCE verticale tramite passaggio di contesto. In questo scenario, la CCE verticale rimane l’unico ambiente di riferimento per il clinico di una certa specialità e si sostituisce completamente alla soluzione CCER gestendo, oltre alle funzionalità specifiche del reparto/ambulatorio, anche le informazioni comuni a livello aziendale;

• L’integrazione tra la soluzione CCER e la CCE verticale che presenta solo funzionalità specialistiche. In questo secondo scenario, quindi, le aree funzionali di carattere generale rimangono trasversali alla soluzione CCER e sono fruite dall’interfaccia della cartella clinica verticale.

5.4. Accessibilità e usabilità

Il sistema dovrà garantire:

• Rapidità di accesso alle funzioni chiave del sistema (ad es. presenza di menù generale con le aree applicative principali);

• Presenza in ogni schermata delle informazioni critiche sul paziente configurabili (ad es. anagrafica, avvisi su intolleranze/allergie, cadute accidentali, stati di iperpiressia, lesioni da decubito, contenzioni, ecc.);

• La visualizzazione dell’intero percorso clinico del paziente in forma cronologica e sintetica, dando inoltre la possibilità di accedere al dettaglio di ciascun evento clinico occorso;

• Agli operatori di mettere in risalto le informazioni ritenute più rilevanti, quali: eventi critici occorsi, notevoli cambiamenti nelle condizioni del paziente, prossimi esami/accertamenti (tali informazioni dovranno essere organizzate in modo omogeneo e con una nomenclatura chiara e pertinente);

4 xxxxx://xxx.xxxxxxxxxxxxxxxxx.xx/xx/xxxx/xxxxx_xxxxxxxx/xxxxxxXxx?xxxxxx00X00000000000000 10001&dgu=2022-07-11&art.dataPubblicazioneGazzetta=2022-07- 11&art.codiceRedazionale=22A03961&art.num=1&art.tiposerie=SG)

• La visualizzazione delle informazioni circoscritte all’ambito operativo dell’utente (reparto, ambulatorio, amministrazione, ecc.) e quindi di limitare i dati modificabili/inseribili a seconda dei diritti dell’operatore che si autentica al sistema, facilitando allo stesso tempo la compilazione attraverso l’introduzione di frasi standardizzate nei campi di testo libero (il sistema dovrà dunque essere adattativo);

• Accesso mediante un unico insieme di credenziali definito dal singolo ES e trasparenza del cambio di contesto tra moduli o applicazioni differenti, senza quindi soluzione di discontinuità alcuna;

• Meccanismi per il log-out dell’operatore nel caso in cui non effettui transazioni, di tipologie definite, per un tempo stabilito. Questi meccanismi dovranno essere configurabili per la definizione del tempo di inattività e per la definizione delle tipologie di transazioni che, se eseguite, azzerano il tempo di inattività;

• La gestione dettagliata e flessibile della profilazione degli utenti. Per ogni modulo o ambito di utilizzo della CCER dovrà essere possibile definire gli operatori abilitati a svolgere le diverse operazioni previste (ad es. creazione, modifica, visualizzazione, ecc.). I profili individuati dovranno poter essere applicabili a livello di operatori, gruppo di operatori, reparto, ecc.

• L’integrazione con dispositivi basati su tecnologie a codice a barre e RFId, come i braccialetti o badge, per l’identificazione dei pazienti;

• Una grafica semplice e con combinazioni di colori “comode” per la vista. Attraverso un’unica interfaccia, l’utente dovrà poter avere tutto il processo sotto controllo, in modo tale da reperire le informazioni in maniera più agevole e minimizzare l’apertura di ulteriori videate/popup durante la sessione di lavoro;

• Un’organizzazione dei singoli inserimenti in più campi, suddivisi in base alla sezione del documento, strutturati ad es. tramite checkbox, menu a tendina, ecc. per facilitare la manipolazione ed il riuso successivo delle informazioni;

• Interfaccia di tipo responsive per la fruizione efficace ed efficiente della soluzione anche in mobilità tramite tablet;

• Funzionalità di dettatura vocale con dizionario medico;

• Il supporto delle funzionalità di appunti del sistema operativo (“copia e incolla”);

• La firma digitale multidocumento. L’operatore sanitario potrà firmare i documenti clinici redatti in cartella clinica mediante smart card e/o mediante firma digitale remota con token OTP (One Time Password). Deve essere possibile firmare i documenti generati, sia in formato

PDF che PDF/A con HL7 CDA2 iniettato (quest’ultimo almeno per i documenti che linee guida tecniche di riferimento in ambito nazionale per lo sviluppo e l'implementazione dei documenti sanitari), nei formati CADES, PADES e XADES;

• Ai fini della gestione del versioning dei documenti, la visualizzazione delle differenze nel testo tra la versione oggetto di firma e la sua eventuale versione precedente;

• Gestione di frasi standard per utente e/o specialità come supporto alla compilazione;

• L’accesso tramite standard W3C.

5.5. Efficienza ed Efficacia

La ridondanza del dato dovrà essere minimizzata al fine di ottenere maggior correttezza e puntuale aggiornamento.

Il requisito fondamentale di modularità della CCER dovrà permettere di scindere le funzionalità specifiche dei differenti ambiti operativi (specialità mediche, unità organizzative o gruppi clinici) da quelle comuni e quindi configurare i dati da presentare a seconda dell’ambito di afferenza dell’utente.

È necessario che l’applicativo di CCER sia in grado di fornire una reportistica su temi quali: indicatori chiave di processo, gestione del rischio clinico, inconsistenze nei dati inseriti, statistiche a vari livelli sui casi clinici trattati (patologie manifestate, procedure/azioni terapeutiche attuate a livello medico ed infermieristico, prescrizioni e somministrazioni adottate, utilizzo di dispositivi, ecc.), statistiche di utilizzo dell’applicativo, e così via.

L’applicativo CCER dovrà prevedere sistemi di alert clinici significativi, automatici, oltre che di proposta di compilazione automatica di campi sulla base di altri elementi. Riguardo agli alert clinici significativi, questi dovrebbero avere le seguenti caratteristiche:

• Essere coerenti rispetto alla fase del percorso di cura;

• Essere il più possibile strutturati nei contenuti, limitando i campi testo di tipo aperto;

• Esprimere un’informazione essenziale che impatti sul rischio di vita della persona assistita (ad es. allergie);

• Essere in numero limitato per evitare l’eccesso delle informazioni.

È opportuno distinguere gli alert clinici significativi, scelti da parte dell’ES dopo condivisione interna con i professionisti, e gli “avvisi” che possono essere anche molto più numerosi, contestualizzati in specifici percorsi o per disciplina, pur sempre di univoca interpretazione e definizione a livello aziendale.

A tal proposito, la CCER dovrà prevedere dei meccanismi che consentano, nel caso in cui vengano apportate modifiche ad informazioni contenute nella CCER stessa, di notificare all’utente che esiste una versione nuova e aggiornata di tale informazione.

La CCER dovrà, inoltre, garantire un livello minimo per quel che riguarda le prestazioni ed in particolar modo i tempi di risposta delle diverse schede che la compongono, anche a fronte di richieste multiple provenienti dai diversi utenti.

Al fine di evitare possibili inserimenti erronei, l’applicativo di CCER non dovrà consentire allo stesso operatore di aprire contemporaneamente due fascicoli elettronici di ricovero appartenenti a differenti persone assistite.

5.6. Disponibilità

La completa disponibilità dei dati clinici dovrà essere garantita sempre e dovunque, anche a fronte di un malfunzionamento del sistema, dell’infrastruttura di comunicazione o di altri sistemi applicativi integrati dell’ES.

Oltre a meccanismi di ridondanza dei dati lato server, la soluzione dovrà consentire la sua erogazione autonoma tramite una specifica componente software installata su postazioni di emergenza dell’ES dedicate e distribuite nella struttura sanitaria, caratterizzate da una copia locale sincronizzata dei dati clinici necessari a garantire la continuità operativa per gli episodi in corso. Dunque, La funzionalità dovrà essere erogabile tramite postazioni di emergenza costituite da PC “tradizionali” installabili presso i singoli reparti e non richiedere ulteriori apparati di classe server.

Dovranno, inoltre, essere adottati meccanismi che consentano l’attribuzione di identificativi provvisori da parte della CCER nei casi in cui il sistema di competenza sia indisponibile da riconciliare una volta ripristinato il sistema.

5.7. Estendibilità e scalabilità

Dovrà essere possibile estendere di volta in volta la CCER con le funzionalità dei vari reparti specialistici o organismi dell’ES interessati a tali dati. I requisiti di scalabilità dovranno essere rispettati attraverso un giusto dimensionamento delle infrastrutture di calcolo, di rete, di archiviazione dati. Il sistema dovrà possedere:

• Scalabilità di carico, ovvero capacità di aumentare le prestazioni del sistema in funzione della potenza di calcolo complessiva dedicata alla sua esecuzione. Tale scalabilità è necessaria per

far fronte al carico computazionale generato dall’ingente e sempre crescente numero di utenti utilizzatori del sistema.;

• Scalabilità geografica, intesa come capacità del sistema di mantenere inalterata la sua usabilità e utilità indipendentemente dalla distanza fisica dei suoi utenti o delle sue risorse. Nel sistema, dunque, dovranno essere integrate sedi periferiche dell’ES;

• Scalabilità amministrativa, ovvero mantenere inalterata la sua gestibilità indipendentemente da quante organizzazioni lo utilizzano.

5.8. Tracciabilità ed esibizione

L’applicativo di CCER dovrà garantire la tracciabilità totale delle operazioni, ossia dovrà tener traccia, per ciascuna operazione di accesso, visualizzazione, inserimento, modifica o importazione, delle informazioni relative a data, ora e autore della operazione, dandone evidenza a livello di interfaccia ove richiesto.

Dovrà sempre essere attivo il meccanismo di salva in bozza, antecedente al perfezionamento di un documento e alla sua pubblicazione, oltre che di tracciabilità della data e dell’ora di registrazione dell’informazione. Si precisa che la bozza dovrà essere accessibile unicamente al suo redattore e sottratta alla pubblicazione, operazione quest’ultima da riservarsi unicamente ai documenti perfezionati. La CCER dovrà garantire inoltre che, fatte salve le bozze, le informazioni registrate siano rese non modificabili e storicizzate.

La CCER dovrà altresì consentire la possibilità di attivazione una validazione/approvazione esplicita, da parte dei soggetti autorizzati, dei documenti/dati ricevuti automaticamente da fonti esterne (ad es. referti, dati di laboratorio, di monitoraggio, ecc.). Qualora attivata, eventuali documenti/dati non ancora validati e quindi non facenti ancora parte della CCER, dovranno comunque essere fruibili dando evidenza del loro stato di validazione.

L’estrazione di copie analogiche di originali informatici, seppur possibile, dovrà avvenire con indicazione chiara della fonte e nel rispetto di eventuale regolamentazione aziendale. Un aspetto particolare dell’estrazione di dati si presenta quando sia richiesta l’esecuzione di una prestazione sanitaria in struttura diversa da quella di ricovero dell’assistito. I sanitari della struttura erogante dovranno poter conoscere le informazioni raccolte nella CCER formata fino a quel momento.

5.9. Gestione della Cartella ibrida cartacea-elettronica

Per quanto riguarda l’operatività in reparto, il sistema di CCER dovrà:

• Fornire la possibilità di produrre stampe di documenti prodotti digitalmente che siano adeguatamente strutturati, formattati secondo il layout aziendale e nei quali siano chiaramente riportati gli estremi identificativi, e con riportata la dicitura “documento firmato digitalmente presente nel repository aziendale”;

5.10. Linee guida AgID

La soluzione proposta deve essere modellata strutturalmente tenendo conto dei principi di Security/Privacy by design, come indicato nelle “Linee guida per la modellazione delle minacce ed individuazione delle azioni di mitigazione conformi ai principi del secure/privacy by design”5 definite da Agenzia per l’Italia Digitale (AgID). Questi principi sono quegli approcci ingegneristici che si concentrano sulla progettazione di applicazioni sicure con l’obiettivo di indirizzare le attività la modellazione delle minacce e conseguente individuazione di azioni di mitigazione.

5 Linee Guida per la modellazione delle minacce ed individuazione delle azioni di mitigazione conformi ai principi del Secure/Privacy by Design - D04.Fase1.SP2 Draft2 (xxxx.xxx.xx)

6. EVENTUALI FUNZIONI MIGLIORATIVE

Oltre alle funzioni modulari sopra descritte che si ritengono mandatorie ai fini della fornitura della CCER, si lascia al fornitore la possibilità di definire e proporre altre caratteristiche innovative, non già citate, che la cartella clinica dovrebbe integrare.

In particolare, di tali funzionalità verrà valutato:

• L’impatto che tali soluzioni hanno sui workflow di lavoro e sul benessere ultimo dei pazienti;

• Il carattere innovativo delle proposte;

• La loro applicabilità trasversale rispetto al patrimonio tecnologico delle singole ASL.

7. Fornitura Opzionale

La fornitura dovrà, altresì, prevedere l'erogazione, quale componente opzionale, del modulo di gestione territoriale, successivamente descritto, che dovrà essere attivato dal Fornitore su richiesta specifica dei singoli enti sanitari.

7.1.1. Gestione Territoriale (PDTA)

Il modulo per la gestione dei PDTA sul territorio, integrato nell’architettura seguente, dovrà garantire, nell’ambito dell’integrazione Ospedale-territorio, il criterio di continuità assistenziale del paziente che passata dalla fase acuta alla stabilizzazione in fase post acuta, o ai percorsi di monitoraggio e gestione delle proprie cronicità e fragilità sul territorio.

Per tale motivo, sulla stessa anagrafica paziente, il quadro clinico va rivalutato, sulla base di quanto dettagliato al momento delle dimissioni, nella fase di presa in carico da parte della struttura territoriale (Cure Domiciliari e palliative, Cure Oncologiche, Cure Croniche, Cure riabilitative estensive, etc; Presso domicilio, RSA, Case della Comunità, etc) e tutto il percorso clinico deve aggiornare la CCER/CCE e il FSE.

La Cartella Clinica per la gestione dei PDTA Territoriali, o per pazienti presi in carico dalle dimissioni precoci o pazienti arruolati presso le Unità Operative territoriali, strutture intermedie (RSA, Case della comunità), Cure domiciliari, Cure oncologiche, Cure Croniche, (arruolati presso centro Diabete), centro NAD, etc. deve avere le seguenti caratteristiche di base:

1. Modulo gestione PDTA territoriali con gestione Unità operative semplice, complesse, distretti, strutture accreditate;

2. Presa in carico territoriale e PDTA in base a settings segnalati;

a. Paziente Post acuto che va in Cure domiciliari e Palliative;

i. Segnalazione alla PUA;

ii. Valutazione team UVI/UVMD anche in teleconsulto con medici di centrale telemedicina;

iii. Definizione del PAI;

iv. Avvio Piano di cura Interno/esterno In caso di Home Care Providers,

a. gestione prequalifica;

b. servizi integrativi verso loro cartelle;

c. Logica attribuzione PAI in accordo CIA e settings;

v. Erogazione del piano;

vi. Dimissioni;

vii. Flussi SIAD;

b. Paziente Xxxxxxx e PDTA cronicità;

i. Segnalazione alla UO o centro corrispondente;

ii. Valutazione di Team anche in teleconsulto con medici di centrale telemedicina;

iii. Definizione del Piano di Cura;

iv. Follow ups;

c. Cure prestazionali di I livello (MMG);

i. Presso AFT;

ii. Assistenza Domiciliare Programmata;

d. Cure prestazionali semplici, domiciliari ed ambulatoriali;

e. Gestione Centrale Operativa Territoriale;

i. Coordinamento UO e suoi operatori;

ii. Coordinamento HCP, suoi operatori e strutture accreditate;

Il modulo territoriale deve poter contare sulle seguenti integrazioni di base:

1. XXX (anagrafe sanitaria);

2. CUP aziendale;

3. LIS, aziendale;

4. RIS E PACS aziendale;

5. FSE regionale;

Le caratteristiche evolutive della cartella PDTA territoriale sono:

1. Gestione delle PUA, valutazioni multidimensionali anche con lo strumento del teleconsulto (con centrale operativa), determinazione dei piani di cura ed affidamento agli operatori accreditati (Home Care Provider, strutture residenziali, case della comunità, etc) con logiche per l’invio dei piani di cura (cure domiciliari, palliative, residenziali, riabilitative, etc) in accorso a scelta del paziente e gestioni delle non conformità;

2. Integrazione con i software degli ambulatori dei medici di medicina generale per la gestione delle prestazioni di primo livello in alcuni particolari setting dei piani delle cronicità deputate al medico di famiglia.

3. Integrazione con la farmacia aziendale, per la gestione della farmacoterapia durante la fase di cura territoriale;

4. Possibilità di integrare, nei PTDA, prestazioni erogate in Telemedicina, e con il coordinamento della centrale operativa ( a tendere integrazione con i servizi AGENAS) e servizi di

• Teleconsulto;

• Televisita;

• Telerefertazione;

• Telemonitoraggio parametri vitali;

• Telediagnostica;

• Teleassistenza;

5. Recupero delle prestazioni erogate con rendicontazione verso NSIS (flussi debito regionale, nazionale);

6. Cruscotto monitoraggio indicatori LEA e possibilità di cruscotto stratificazione popolazione secondo rischio clinico.

8. Requisiti tecnologici

Nel presente Capitolo viene descritto il modello architetturale della soluzione CCER, nonché l’architettura della stessa.

8.1. Architettura della soluzione

La soluzione richiesta dovrà essere fornita come un’unica piattaforma tecnologica, da dover rilasciare sull’infrastruttura dei singoli ES. Là dove disponibile, il fornitore dovrà proporre soluzioni ‘Cloud Native’ con architetture a microservizi e container.

Dal punto di vista applicativo, la soluzione dovrà presentare una struttura modulare, cosicché possa essere integrata con i sistemi applicativi in essere. Tale caratteristica garantirà la scalabilità del sistema CCER in ottica di future integrazioni o modifiche, nonché di adattamenti per rispondere alle diverse esigenze operative dei vari ES.

Inoltre, la soluzione dovrà presentare un’architettura web-based (i.e. secondo un modello client – server o server web) in modo tale da garantire:

- L’accessibilità al sistema informativo locale tramite rete da parte degli operatori sanitari, previa autenticazione degli stessi;

- Tutti i moduli e le funzionalità poter essere fruite sia mediante postazioni di lavoro fisse (es. desktop/laptop) che in mobilità (es. smartphone / PDA);

- L’interoperabilità della soluzione con gli altri moduli del SI ospedaliero.

Rispetto a quest’ultimo punto, la comunicazione in rete dovrà avvenire secondo i comuni protocolli di comunicazione del mondo sanitario, ad esempio HL7 e DICOM.

Inoltre, nella fornitura dovranno essere previsti degli opportuni componenti di interfaccia (i.e. API) che permettano l’invocazione di servizi esterni alla soluzione CCER.

Dal punto di vista infrastrutturale, la soluzione dovrà esse rilasciata sull’infrastruttura indicata e concordata insieme all’ES, tendo conto di fattori generali quali ad esempio qualità della connessione internet, possibilità di installare la soluzione su ambienti virtuali, grado di segmentazione delle reti.

Laddove non sia possibile la virtualizzazione degli ambienti, l’eventuale componentistica hardware e sistemistica supplementare, necessaria per il rilascio della soluzione, risulta essere a carico a del fornitore. Si precisa che “l’eventuale componentistica hardware e sistemistica supplementare”

riguarderà solo i sistemi server nel caso in cui la soluzione offerta non possa essere installata in ambienti virtuali.6

Il fornitore potrà, in accordo con gli ES, eseguire il rilascio della soluzione in ambiente Cloud, secondo un’architettura multi-tenant. L’architettura dovrà rispondere a caratteristiche di conformità a soluzioni tecniche presenti sul mercato e standard di livello regionale e non, oltre che alle peculiarità del sistema in essere degli ES:

• Multi tenancy

o Multi tenancy: le funzionalità applicative della CCER saranno condivise tra i vari ES garantendo allo stesso tempo la segregazione dei dati dei singoli Enti.

• Architettura a microservizi

o Al fine di garantire la massima granularità nella metodologia di sviluppo, il sistema proposto prevederà un’architettura modulare ma non obbligatoriamente a microservizi. Qualora venga proposto un modello a microservizi, dovranno essere isolabili (deployment unit stand alone), containerizzabili e deployabili su piattaforme di orchestrazione;

o L’architettura funzionale del sistema deve essere modulare, ogni modulo deve essere costituito da un insieme omogeneo e coerente di microservizi;

o La comunicazione tra microservizi, tramite API, deve essere realizzata con protocolli di comunicazione sicuri (es. https);

o In generale troveranno applicazione le “best practice” per quanto riguarda lo sviluppo di applicazioni a microservizi (es. modalità di implementazione dello strato di persistenza).

o Il numero di microservizi esposti su Internet dovrebbe essere minimizzato e in tutti i moduli, che prevedono una componente client esposta all’utente, le chiamate a tali microservizi non devono essere cablate all’interno del codice ma mappate in un file esterno di configurazione in modo da poter utilizzare eventuali funzionalità di servizi proxy rese disponibili per i microservizi.

• Container

o La tecnologia a supporto dell’architettura a microservizi che dovrà essere adottata sarà quella di “software container”, al fine di isolare logicamente l’applicazione, permettere la massima elasticità e velocità nelle fasi di modifica e sostituzione dei vari moduli di cui

6 Si precisa altresì che la componentistica è da intendersi a carico del fornitore solamente in ragione di eventuale incompatibilita dei i sistemi software oggetto di fornitura con ambienti virtualizzati in ragione di scelte tecnologiche (non virtualizzabilità) imputabili unicamente al fornitore stesso. Si conferma infine che laddove le amministrazioni non dovessero disporre di infrastrutture di virtualizzazione, la componentistica hardware, la componente sistemistica, gli hypervisor, non saranno da considerarsi in alcun modo a carico del fornitore.

è composta la soluzione. La soluzione deve essere in grado di perseguire e beneficiare dei seguenti obiettivi di scalabilità e portabilità;

o Scalabilità, ovvero la capacità della soluzione di distribuire verticalmente (sui diversi strati applicativi) e orizzontalmente (su diversi nodi dell’infrastruttura di erogazione) carichi di lavoro crescenti o eventuali picchi di utilizzo dovuti ad eventi estemporanei, assicurando la scalabilità a livello di singolo container o microservizio; la presente iniziativa vuole infatti dotare gli ES coinvolti di una soluzione CCER scalabile in termini applicativi;

o Portabilità, ovvero la possibilità di installare i moduli della piattaforma sui sistemi più diffusi senza necessità di riconfigurazioni. A tal fine non si dovranno utilizzare servizi dipendenti dalla scelta del singolo Cloud Service Provider per ridurre il rischio di vendor lock-in e facilitare eventuali migrazioni che si ritenessero necessarie;

o Orchestrazione dinamica, per gestire i cicli di vita dei container, la gestione delle risorse, il bilanciamento del carico, la programmazione dei riavvii dopo un guasto interno e il provisioning e il deployment dei container sui nodi del cluster;

o L’immagine deve essere configurata con il minimo dei privilegi, eliminando utenze di default e impostazioni di debug, al fine di limitare la superficie d’attacco.

• Linee guida AgID

o La soluzione proposta (sia strutturale sia concettuale) deve essere modellata tenendo conto del principio di Privacy by design, ovvero quell’approccio ingegneristico che si concentra sull’intero processo di tutela della privacy e che segue i sette principi su cui si basa:

o Proattivo non reattivo, preventivo non correttivo;

o Privacy come impostazione predefinita;

o Privacy incorporata nella progettazione;

o Piena funzionalità - somma positiva, non somma zero;

o Sicurezza end-to-end - Tutela dell'intero ciclo di vita;

o Visibilità e trasparenza;

o Rispetto per la privacy degli utenti.

8.2. Requisiti e Vincoli

Laddove sia prevista un’erogazione della soluzione in ambiente Cloud, quest’ultima dovrà essere conforme ai requisiti applicabili dal Regolamento recante i livelli minimi di sicurezza, capacità elaborativa, risparmio energetico e affidabilità delle infrastrutture digitali per la PA e le caratteristiche di qualità, sicurezza, performance e scalabilità, portabilità dei servizi cloud per la pubblica amministrazione, le modalità di migrazione, nonché le modalità di qualificazione dei servizi

cloud per la pubblica amministrazione (secondo quanto previsto dall’articolo 33-septies, comma 4, del decreto-legge 18 ottobre 2012, n. 179, convertito, con modificazioni, dalla legge 17 dicembre 2012, n. 221), approvato con Determinazione AGID n.628/2021 e successivamente modificato dall’allegato 1 alla Determinazione ACN (Agenzia per la Cybersicurezza Nazionale) n.307/2022 – Aggiornamento degli ulteriori livelli minimi di sicurezza, capacità elaborativa, e affidabilità delle infrastrutture digitali per la pubblica amministrazione e delle ulteriori caratteristiche di qualità, sicurezza, performance e scalabilità dei servizi cloud per la pubblica amministrazione, nonché requisiti di qualificazione dei servizi cloud per la pubblica amministrazione.

In particolare, il riferimento del livello di qualificazione per i sistemi/servizi da erogarsi per la Regione Abruzzo è pari al:

- livello QC3 per i servizi cloud;

- livello QI3 per le infrastrutture.

Di conseguenza dovranno essere adottate tutte le misure ritenute applicabili al sistema/servizio erogato, specificandole in una dichiarazione di applicabilità e motivando adeguatamente quelle che saranno eventualmente ritenute non applicabili. Le misure applicate inoltre dovranno essere adeguatamente documentate e compatibili con le policies adottate dalla Regione Abruzzo in qualità di Cloud Service Provider qualificato per l’erogazione di servizi IaaS, PaaS e SaaS. Da tenere presente, infatti, che i Data Center della Regione Abruzzo sono CSP (Cloud Service Provider) qualificati e certificati secondo gli standard internazionali di sicurezza richiesti dai livelli di qualificazione AgID/ACN (UNI CEI EN ISO/IEC 27001:2017, ISO/IEC 27017:2015, ISO/IEC 27018:2019, ISO/IEC

20000-1:2018, UNI EN ISO 9001:2015; di prossima adozione saranno gli standard ISO/IEC 22301:2019 e CSA Star di Livello 2): quanto documentato dovrà quindi essere in linea con i requisiti relativi a tali standard e alle policies interne sviluppate; la verifica di compatibilità verrà effettuata in sede di valutazione del Documento Progettuale di Dettaglio (DPD).

In caso di utilizzo di servizi CLOUD (PAAS/SAAS), è necessario che questi siano presenti sul catalogo dei servizi qualificati da AGID per le PA (Cloud Marketplace AgID) previa verifica che analoghi servizi siano già disponibili sulle piattaforme regionali del CSP offerto dalla Regione Abruzzo.

Si chiede comunque che vengano forniti al Committente i dettagli relativi alle schede tecniche dei servizi e, nel caso in cui si intenda adottare servizi qualificati Agid, deve essere esplicitata la rispondenza alle esigenze di realizzazione imposte dal Committente senza che tale adozione possa introdurre dei lock-in tecnologici.

Relativamente a tali scelte, il Committente si riserva comunque di apporre la sua approvazione.

In virtù dei vincoli relativi al livello di sicurezza previsto per i servizi Cloud, erogati dalla Regione Abruzzo (QC3 – QI3), Il fornitore inoltre è chiamato a riportare, in un Documento Progettuale di Dettaglio, che sarà redatto in fase esecutiva del presente capitolato, come successivamente descritto, le seguenti informazioni:

- descrizione architettura generale della soluzione fornita riportante i dettagli di tutti i servizi e i moduli componenti e degli interfacciamenti (API) verso sistemi/moduli/servizi utilizzati; la descrizione dovrà evidenziare la suddivisione tra i vari livelli dello stack riportando l’eventuale utilizzo di servizi SaaS, PaaS e IaaS.

- inventario dettagliato di moduli e componenti del sistema/servizio e relative modalità di aggiornamento (Configuration Management).

- specifica indicazione nell’inventario di cui al punto precedente dell’eventuale presenza di moduli, componenti e servizi utilizzati dal sistema che siano esterni all’infrastruttura residente presso le strutture del committente (es.: servizi cloud, di monitoraggio, ecc…); per ognuno di questi moduli, componenti e servizi utilizzati dovranno essere forniti i relativi dettagli tecnici (es.: dati forniti, direzione in-out, modalità di autenticazione, ecc…)

- per ogni modulo, componente e servizio del sistema dettaglio dell’eventuale contenuto di dati residenti at rest;

- modalità di gestione del processo IAM (Identity and Access Management), sia per le utenze applicative che per le utenze di servizio e relativi criteri di sicurezza configurabili; riportare in dettaglio le modalità amministrative di gestione e gli aspetti relativi alla gestione delle autorizzazioni. Indicare la possibilità di poter applicare criteri di least privilege a tutte le tipologie di utenze, anche di servizio;

- modalità di applicazione di soluzioni di cifratura (at rest, in transit) e pseudonimizzaizone dei dati (descrizione eventuale architettura delle soluzioni adottate); Indicazione dei protocolli e delle modalità di gestione delle chiavi;

- modalità di gestione dei servizi di manutenzione (presso la sede del committente e da remoto): saranno consentite interazioni con il sistema dall’esterno della rete della Regione Abruzzo esclusivamente attraverso le metodologie previste dalle policies approvate.

- generazione e raccolta dei log applicativi, di sistema e di sicurezza con livelli di dettaglio da concordare con il Committente;

- Soluzioni, tecniche e protocolli disponibili per la comunicazione (interscambio e interfacciamento tra i sistemi componenti l’architettura generale del sistema/servizio);

- descrizione delle modalità di gestione delle configurazioni sicure e dell’hardening di tutte le componenti del sistema/servizio;

- modalità di gestione delle vulnerabilità tecniche di sistema e del patch management

- modalità di gestione degli upgrade (es.: software/firmware) per finalità di aggiornamento normativo e di sicurezza.

- soluzioni di monitoraggio dello stato dei sistemi in termini di performance,

- metodologie di ingegnerizzazione sicura dei sistemi utilizzate per lo sviluppo ed il testing (Security & Privacy by Design e by Default, defence in depth, default deny, fail securely, least privilege).

- eventuale impiego di tool atti a verificare la correttezza del codice riducendo le vulnerabilità.

- modalità previste per la garanzia di continuità operativa del sistema secondo gli SLA (Service Level Agreement) concordati con il Committente.

- modalità di gestione di eventuali incidenti/data breach (anche di eventuali servizi esterni utilizzati nell’ambito della fornitura di servizi al Committente) e fornitura di supporto al per la gestione di tali eventi.

La verifica della compatibilità della soluzione ai suddetti requisiti verrà effettuata in sede di valutazione del Documento Progettuale di Dettaglio (DPD).

Tutti i sistemi ed i servizi forniti inoltre dovranno avere caratteristiche tecniche e di sicurezza adeguate a quanto indicato dal Reg. UE 2016/679 sulla protezione dei dati (c.d. GDPR) con particolare riferimento agli artt. 24 e 32.

Dovrà essere comunicato l’elenco di eventuali componenti e/o servizi esterni utilizzati o qualunque interazione del sistema/servizio con terze parti, con particolare riferimento ad eventuali comunicazioni extra-UE o verso data center gestiti da provider la cui proprietà è riconducibile a società extra-UE.

Qualora previste dal sistema/servizio, dovranno essere comunicate e descritte le modalità di utilizzo e le relative misure di sicurezza adottate in relazione all’applicazione di tecnologie di AI (Artificial Intelligence), IoT (Internet of Things) e Blockchain specificando normative di riferimento e standard applicati.

I sistemi dovranno essere sviluppati nel rispetto delle linee guida, strumenti e metodologie definite dall’Open Web Application Security Project (OWASP).

Inoltre, in linea generale, la soluzione di CCER resa disponibile dal Fornitore dovrà soddisfare i seguenti requisiti, evidenziando nell’offerta tecnica eventuali difformità:

• Garantire nel tempo l’allineamento della soluzione CCER all’evoluzione della RA per quanto riguarda le versioni dei prodotti utilizzati;

• Mantenere l’applicazione allineata alle nuove versioni dei prodotti/framework utilizzati, ovvero l’applicazione non dovrà utilizzare versioni di prodotti prossimi a “end-of-life” e/o “end-of-support”;

• Tutte le componenti all’interno dell’immagine container sono considerate componenti applicative, e quindi di competenza del fornitore;

• Gestire adeguatamente la tracciatura degli eventi (log audit);

• Ciascun componente architetturale della soluzione dovrà essere progettato in modo da poter lavorare in alta affidabilità e in modo che un singolo failure non comporti un’interruzione del servizio;

• Gli aggiornamenti di tipo “minor” della soluzione devono essere possibili “a caldo”, senza interruzioni del servizio (se non in termini di “secondi” per l’eventuale riavvio dei servizi);

• L’infrastruttura deve dare garanzia di elevate performance anche in presenza di notevoli livelli di carico e un elevato numero di contatti giornalieri. Per quanto concerne le transazioni di front-end (ad es. apertura di singole schermate popolate con i dati del sistema), si ritiene che il tempo di risposta massimo debba essere di norma inferiore ai 2 secondi.

9. GESTIONE DELLA PRIVACY E DELLA SICUREZZA DELLE INFORMAZIONI

9.1. Gestione della privacy

La normativa vigente in materia di protezione dei dati personali, sulla base di quanto disposto dal Reg. UE 2016/679 (Regolamento Europeo in materia di protezione dei dati personali), dal D.lgs. 196/2003, come novellato dal D.lgs. 101/2018, e dai Provvedimenti emanati dalle Autorità competenti italiane ed europee (di seguito, complessivamente, “Normativa Privacy”), è volta a garantire che il trattamento dei dati personali derivante dalla prestazione dei servizi di cui alla presente gara si svolga nel rispetto dei diritti e delle libertà fondamentali, nonché della dignità dell'interessato, con particolare riferimento alla riservatezza, all'identità personale e al diritto alla protezione dei dati personali.

In particolare, la Normativa Privacy prevede:

• La necessità di strutturare e mettere in atto un’organizzazione specifica per la protezione dei dati personali attraverso l’identificazione di opportuni ruoli e le relative procedure di nomina;

• Un insieme di misure atte a preservare efficacemente tutte le informazioni e i dati personali secondo lo stato della tecnica da assi non autorizzati, alterazione, distruzione o perdita, da trasmissione non autorizzata, trattamento non autorizzato e altri abusi nel quadro di un progetto di sicurezza che dia ampia e completa applicazione delle misure tecniche e organizzative atte a garantire un livello di sicurezza adeguato al rischio, ai sensi dell’art.32 del GDPR ed in generale della Normativa Privacy.

L’Autorità Garante per la Protezione dei dati personali ha inoltre espresso misure e accorgimenti specificamente destinati ai titolari del trattamento per i trattamenti effettuati con strumenti elettronici relativamente alle attribuzioni delle funzioni di amministratore di sistema (Provvedimento del 27 novembre 2008 e s.m.i.) ancora in vigore con il Reg. UE 2016/679.

Nei Paragrafi successivi vengono descritti, secondo l’ordine logico appena definito, i requisiti in ambito protezione dei dati personali che i fornitori partecipanti al bando di gara devono rispettare.

9.1.1. Requisiti relativi agli aspetti organizzativi

Il Fornitore, per quanto di competenza in riferimento alla presente gara, verrà nominato responsabile del trattamento dei dati personali (di seguito, anche solo “Responsabile”) dal titolare del trattamento (di seguito, anche solo “Titolare”).

Il Fornitore designato Responsabile del trattamento procede ad individuare:

• Le “persone autorizzate al trattamento” che svolgono le attività di trattamento dei dati personali oggetto della presente Fornitura, garantendo il loro impegno alla riservatezza.

• Gli “Amministratori di sistema” per le attività legate alla Fornitura oggetto della presente gara, sia che questi operino presso la propria sede o altra sede ove svolgono la propria attività.

Il Titolare si riserva di chiedere in qualunque momento al Fornitore aggiudicatario della gara l’elenco aggiornato delle persone autorizzate al trattamento e degli amministratori di sistema.

9.1.2. Requisiti relativi alle misure di sicurezza

Il Fornitore, ai sensi dell’art. 32 del Reg. UE 2016/679, dovrà mettere in atto misure tecniche e organizzative adeguate a garantire un livello di sicurezza adeguato al rischio.

Nel valutare l’adeguato livello di sicurezza, il Fornitore dovrà tenere conto dei rischi presentati dal trattamento, in particolare da quelli che derivano dalla distruzione, dalla perdita, dalla modifica, dalla divulgazione non autorizzata o dall’asso, in modo accidentale o illegale, a dati personali trasmessi, conservati o comunque trattati.

L’evoluzione della Normativa Privacy, mediante la pubblicazione di provvedimenti, regolamenti, ecc. ad hoc da parte dell’Autorità Garante, ha richiesto e potrebbe richiedere in futuro, l’implementazione di misure di sicurezza ulteriori rispetto a quanto già contemplato. Si chiede quindi al Fornitore di considerare e applicare ogni ulteriore misura che potrà derivare dall’evoluzione normativa. Tali misure dovranno essere applicate durante tutto il ciclo di vita del trattamento, conformemente al principio ‘privacy by default’

Il Fornitore dovrà garantire e monitorare l’applicazione delle prescrizioni di seguito descritte anche da parte degli eventuali suoi sub-fornitori, anche attraverso specifiche attività di audit.

Il Fornitore dovrà altresì garantire, per tutta la durata del contratto, l’aggiornamento delle versioni di tutti software forniti (software e altri moduli applicativi, sistemi operativi, database, ecc.) in modo da garantire l’uso di versioni sempre supportate dai relativi produttori e la disponibilità degli aggiornamenti di sicurezza. In particolare, i già menzionati soggetti dovranno considerare i seguenti aspetti:

Protezione contro software dannoso (virus, malware, ecc.)

Tutti gli strumenti elettronici utilizzati nell’ambito del trattamento dei dati dovranno prevedere sia l’installazione di un software antivirus aggiornato costantemente, sia la realizzazione di operazioni di manutenzione correttiva e preventiva dei programmi e del sistema operativo con cadenza periodica.

Gestione dei Back-up

Nell’ambito del trattamento dei dati, dovranno essere definite opportune norme per il loro backup, su base almeno settimanale. Tali norme dovranno essere impartite a tutto il personale operativo.

Rilevazione delle vulnerabilità tecniche

Ai fini di garantire la sicurezza perimetrale della strumentazione elettronica, questi dovranno essere protetti contro l'asso abusivo mediante l'utilizzo di idonei presidi sulla base del rischio effettivo (ad esempio ponendoli su segmenti di rete protetti da software o apparati di protezione perimetrale quali Firewall, IDS/IPS, ecc.).

9.1.3. Data breach

Il Fornitore dovrà tempestivamente comunicare, entro il limite di 24 ore, ogni violazione dei dati o di incedenti informatici con un impatto significativo sui dati personali contenuti nelle banche dati, secondo le procedure previste e quanto concordato con il Titolare, nel rispetto dell’art. 33 del Reg. UE 2016/679.

9.1.4. Obblighi di assistenza e collaborazione

Il Fornitore dovrà assistere il Titolare, qualora formalmente delegata dal Titolare ai sensi dell’art. 28 Reg. UE 2016/679, nell’ipotesi di esercizio dei diritti da parte degli interessati al trattamento dei dati, collaborando al fine di dar seguito alle loro eventuali richieste (asso, rettifica, cancellazione, portabilità, opposizione).

Il Fornitore dovrà inoltre fornire la massima collaborazione al Titolare nelle attività di valutazione di impatto (DPIA) previste dall’art. 35 del Reg. UE 2016/679 e di aggiornamento del Registro del trattamento previsto dell’art. 30 del Reg. UE 2016/679.

9.1.5. Requisiti tecnici della soluzione

In linea generale, secondo le suddette normative, il trattamento dei dati personali da parte della soluzione, dovrà rispettare i seguenti principi fondamentali:

• Essere eseguito secondo i principi generali di Privacy by Design e Privacy by Default

• Essere eseguito in modo tale che vengano rispettati i principi fondamentali dell’interessato, quali laicità del trattamento, diritto all’oblio, etc. (cfr. art. 5 del GDPR)

• Essere eseguito in modo tale che vengano adottate le oppure misure di sicurezza, che possono essere intese come l’insieme di procedure, regole, strumenti (anche informatici) volte a garantire i tre principi fondamentali della sicurezza delle informazioni: riservatezza, integrità e disponibilità.

Rispetto a quest’ultimo punto, la soluzione dovrà quindi garantire la possibilità di:

• Visualizzare in forma anonima, o pseudonimizzata, le informazioni del paziente, nonché garantire che l’accesso alle informazioni in chiaro, compresi i dati clinici del paziente, al solo personale autenticato, in modo da garantire la riservatezza dell’informazione stessa.

• Effettuare back-up periodici, in modo tale da garantire la disponibilità delle informazioni

• Firmare digitalmente la documentazione clinica contenente i dati sensibili del paziente.

9.2. Gestione della Sicurezza delle informazioni

Il fornitore ed i suoi collaboratori saranno tenuti ad operare con modalità e comportamenti lavorativi in ottemperanza ai documenti e procedure di sicurezza degli ES e le loro modalità di amministrazione e gestione.

Di seguito vengono riportate le misure di sicurezza atte a preservare l’integrità, la disponibilità e la riservatezza dei servizi e delle informazioni che dovranno essere attuate dal Fornitore nell’ambito delle attività ad esso assegnate.

Il Fornitore dovrà garantire e monitorare l’applicazione delle prescrizioni di seguito descritte anche da parte degli eventuali suoi sub-fornitori, anche attraverso attività di audit.

9.2.1. Gestione del personale del Fornitore

Il Fornitore dovrà garantire che il proprio personale (dipendenti e collaboratori), abbia piena consapevolezza delle problematiche relative alla sicurezza delle informazioni.

9.2.2. Modalità e specifiche di connessione

La connessione remota (dove per remota è da intendersi eseguita da sedi non del Titolare) ai sistemi del Titolare è permessa solo attraverso:

• Connessioni dedicate;

• Connettività VPN di tipo site-to-site.

La connettività VPN-Client, che dovrà essere nominale, è autorizzata solo in casi eccezionali e corredata da opportuna motivazione scritta.

La connettività Internet e l'apparato remoto lato Fornitore saranno a suo carico così come pure la configurazione della connessione VPN (nel caso di connettività site-to-site).

Il Titolare fornirà le specifiche di configurazione, a cui la connettività VPN deve rispondere, che dovranno essere applicate dal Fornitore. La VPN sarà unica per ciascun Fornitore (nel caso di RTI sarà resa disponibile una VPN per ogni società appartenente all’RTI). Non sono possibili in nessun caso VPN multiple per lo stesso Fornitore.

9.2.3. Infrastruttura del Fornitore

Il Fornitore, in funzione delle attività assegnate, dovrà implementare sulla propria infrastruttura e sui propri sistemi le opportune regole di sicurezza in funzione della criticità del servizio e/o dell’informazione trattata.

9.2.4. Analisi e gestione dei rischi

Ove richiesto dal Titolare, il Fornitore è tenuto a svolgere attività di analisi dei rischi rispetto alla sicurezza delle informazioni sull’intero oggetto del contratto.

I risultati dell’analisi dei rischi dovranno essere presentati al Titolare dal Fornitore nei tempi e nei modi che saranno concordati opportunamente tra le parti e dovranno almeno prevedere:

• L’identificazione e la descrizione del rischio;

• Il livello di gravità del rischio;

• L’eventuale impatto sui servizi;

• Le indicazioni sulle possibili soluzioni congiuntamente alle relative stime sui tempi e costi.

Il documento dovrà essere aggiornato ove dovessero intervenire eventi/circostanze impattanti sul contenuto e di tali variazioni dovrà essere data evidenza al Titolare.

Il Fornitore, condividendolo con il Titolare, definirà, ove necessario, le modalità di gestione del rischio (ovvero mitigazione, esternalizzazione ed attenzione) e sarà responsabile della redazione di un Piano di Trattamento dei Rischi da attuare nei tempi concordati con il Titolare.

9.2.5. Sicurezza fisica

Il Fornitore, al fine di garantire a tutte le informazioni e a tutti i dati gestiti per conto del Titolare adeguati livelli di tutela, dovrà definire, implementare e mantenere opportune soluzioni di sicurezza relativamente a: sicurezza perimetrale, controllo degli assi fisici, sicurezza di uffici, locali tecnici ed attrezzature e quanto necessario. Ad esempio, l’alimentazione elettrica e la sicurezza dei cablaggi, i supporti di memorizzazione in ingresso e in uscita, lo smaltimento e il riutilizzo delle apparecchiature stesse.

9.2.6. Gestione degli eventi anomali, degli incidenti e della Business Continuity

Il Fornitore dovrà garantire che le anomalie e gli incidenti aventi ripercussioni sul sistema informativo e sui livelli di sicurezza, siano tempestivamente riconosciuti e correttamente gestiti attraverso efficienti sistemi di prevenzione, comunicazione e reazione, per minimizzare l’impatto sul business.

È fatto obbligo al Fornitore di una altrettanto tempestiva notifica nei confronti del Titolare degli eventi anomali e/o incidenti di sicurezza che coinvolgono sistemi del Fornitore che contengono o trattano dati o codice del Titolare.

Nel dettaglio il Fornitore dovrà:

• Implementare le procedure di gestione degli incidenti di sicurezza e di comunicazione degli stessi al Titolare;

• Rilevare gli incidenti che possano avere un impatto sui livelli di sicurezza. dovrà altresì garantire la completa gestione degli eventuali effetti, reali o potenziali, derivanti dall’incidente, ove possibile in tempi brevi, garantendo il rispetto delle procedure, ove presenti o definite, sempre in accordo con il Titolare;

• Prevedere un sistema di registrazione e classificazione degli incidenti e degli eventi anomali per effettuare analisi volte al miglioramento dei livelli di sicurezza coerente con le reali problematiche riscontrate;

• Raccogliere le evidenze a seguito di un incidente di sicurezza, conservarle e presentarle qualora sussista la necessità di azioni legali di natura civile o penale;

• Attivare e mantenere idonee procedure di Business Continuity nella misura ed in relazione al servizio prestato al Titolare, in coerenza con i livelli di servizio previsti dal contratto;

• Concorrere all’attivazione e al coordinamento dei gruppi operativi del proprio personale dedicato alla gestione delle emergenze e della crisi comunicandolo al Titolare e tenendo aggiornati i nominativi e i recapiti che garantiscano la pronta rintracciabilità delle figure competenti individuate; dovrà partecipare ai test tecnici e organizzativi di Business Continuity e di Disaster Recovery, per quanto di competenza.

9.2.7. Rispetto delle procedure di sicurezza

Il Fornitore si impegna a rispettare le procedure di sicurezza del Xxxxxxxx.Xx rispetto delle procedure di sicurezza e di qualsiasi loro modifica introdotta dal Titolare, anche durante il corso della fornitura, è sempre parte integrante della Fornitura stessa. Il Fornitore non potrà avanzare richieste di estensione contrattuale o pagamenti specifici connessi a questo specifico ambito.

9.2.8. Report da parte del Fornitore

Entro trenta giorni dalla stipula del contratto, il Fornitore dovrà predisporre una proposta di documento di autocertificazione periodica delle regole e delle policy relative alla sicurezza delle informazioni.

In particolare, tale documentazione dovrà includere:

• La descrizione delle azioni implementate e delle regole definite;

• Il risultato dei test effettuati, atti a garantire l’effettivo rispetto di tali regole.

Una volta approvato il documento da parte del Titolare, il Fornitore dovrà, mediante lo stesso, autocertificare, annualmente o su richiesta del Titolare, il rispetto delle regole e delle policy relative alla sicurezza delle informazioni. Questa documentazione è considerata parte del sistema complessivo di monitoraggio della Fornitura.

9.2.9. Attività di verifica e controllo

Il Titolare avrà facoltà di effettuare attività di verifica e controllo del prodotto. La verifica può essere effettuata sia tramite visita presso il Fornitore o, congiuntamente, presso i suoi sub-fornitori, sia tramite richiesta di idonea documentazione attestante la conformità ai requisiti di sicurezza richiesti contrattualmente nonché dalla normativa di riferimento.

9.2.10. Deroghe

In casi straordinari e con le dovute autorizzazioni opportunamente documentate sarà possibile operare in deroga alle regole di sicurezza qui stabilite.

Le richieste da parte del Fornitore dovranno essere formalizzate e tracciate, oltre che adeguatamente documentate. In particolare, dovranno essere esplicitate le motivazioni che giustificano la deroga, gli ambiti operativi e temporali di intervento, l’identificazione del personale esterno e le attività da autorizzare.

La richiesta dovrà essere indirizzata agli specifici referenti operativi del Titolare che provvederanno, coinvolgendo le opportune strutture aziendali interne, ad ottenere autorizzazione scritta per le richieste ammissibili.

9.2.11. Reperibilità

Il Fornitore è tenuto a comunicare i numeri di reperibilità relativi alle figure di Security Manager, a garanzia di una corretta e tempestiva erogazione di tutti i servizi a suo carico, di cui viene riportato di seguito un elenco esemplificativo, ma non esaustivo:

• Comunicazione e gestione di incidenti di sicurezza;

• Comunicazione e gestione di eventi di data breach;

• Test tecnici e/o organizzativi di Disaster Recovery;

• Attivazione dei servizi in Disaster Recovery;

• Piano di rientro dal Disaster Recovery.

La reperibilità per tale figura è da intendersi 24x7x365.

10. AVVIAMENTO, GESTIONE, ASSISTENZA, MANUTENZIONE E DELIVERY DELLA SOLUZIONE CCER

10.1. Fasi progettuali e relative tempistiche

La presente sezione contiene le informazioni connesse all‘introduzione della nuova soluzione CCER definendo le principali attività che dovranno essere svolte a livello Regionale e Locale, nonché ai requisiti a cui il Fornitore dovrà rispondere in fase di delivery della soluzione.

Infatti, il modello adottato per la delivery della soluzione è articolato su due macro-livelli:

• Livello Regionale

• Livello Locale

A livello regionale, La Regione Abruzzo sarà responsabile di gestire gli investimenti e le attività necessarie per garantire la disponibilità della CCER trasversale alle singole ASL.

In particolare, pur garantendo l’autonomia operativa di ciascuna ASL e in conformità con le normative in merito di trattamento e tutela dei dati personali, le informazioni gestite a livello locale potranno essere consolidate anche a livello regionale.

Il livello locale, composto dalle quattro ASL, si occuperà di creare le condizioni affinché la soluzione “generalista” si adegui verticalmente alle caratteristiche peculiari delle singole ASL. In particolare, questa fase sarà necessaria per declinare:

• le integrazioni;

• la diffusione sugli ambiti di attuazione;

• le configurazioni;

• le personalizzazioni di carattere non “invasivo” (es. moduli, verbali, etc.)

Si sottolinea che le attività di introduzione della nuova soluzione CCER dovranno essere svolte garantendo il minor disservizio possibile per operatori e pazienti.

10.1.1. Fase 1: Assessment, Parametrizzazione, Stesura del Documento Progettuale di Dettaglio (DPD), Configurazione, Test e Collaudo, Avviamento alla diffusione e del processo di formazione

Questa fase ha una durata complessiva di 6 mesi entro i quali La Regione Abruzzo sarà responsabile di gestire gli investimenti e le attività necessarie per garantire la disponibilità della CCER trasversale alle singole ASL.

In particolare, il Fornitore procede all’esecuzione e allo sviluppo di un documento di assesment per individuare il parco tecnologico (infrastrutturale e applicativo) dell’ES che verrà impattato, in modo tale da ottenere:

• Una mappatura dei processi che interessano l’introduzione della soluzione CCER

• Una mappa delle integrazioni presenti (sia HL7 che di altro tipo) tra le applicazioni del Sistema Informativo (SI);

• Valutazione dei sistemi presenti nell’ ecosistema regionale o in corso di sviluppo (es. sistemi di autenticazione, gestioni dei ruoli, sistemi di protocollo e gestione documentale), con cui il sistema fornito dovrà interfacciarsi.

Sulla base dell’assesment, il Fornitore dovrà parametrizzare le attività da mettere in campo per il delivery della soluzione, fornendo una strategia che tenga conto delle attività da eseguire come, ad esempio, per la predisposizione degli ambienti virtuali.

Il fornitore, al termine delle suddette attività, dovrà redigere un Documento Progettuale di Dettaglio (DPD) contenente, in maniera strutturata:

- la descrizione generale del sistema/servizio fornito

- la descrizione di dettaglio delle singole componenti del sistema/servizio fornito (anche esterne), comprensivo dei dettagli esecutivi di installazione, configurazione e interfacciamento (es.: tracciati, protocolli, ecc…)

- la descrizione di dettaglio delle misure di sicurezza adottate in relazione alle normative vigenti applicabili al contesto dei sistemi/servizi della Regione Abruzzo e delle ASL regionali. A tal scopo dovranno essere fornite le informazioni necessarie all’esecuzione della Valutazione di Impatto sulla Protezione dei Dati Personali/Data Protection Impact Assessment – DPIA – al fine di gestire e mitigare i rischi connessi agli specifici trattamenti supportati dal sistema/servizio; in particolare dovranno essere fornite le indicazioni in relazione alle modalità con cui il sistema/servizio supporti la gestione dell’esercizio dei diritti degli interessati ed il rispetto dei principi previsti dalla normativa vigente (Reg. UE 679/2016):

o Art. 5.1.b – Misure per garantire la limitazione della finalità del trattamento (dati non utilizzati per altre finalità)

o Art. 5.1.c – Misure per garantire la minimizzazione dei dati del trattamento

o Art. 5.1.d – Misure per garantire la esattezza/qualità dei dati (integrità)

o Art. 5.1.e – Misure per garantire la limitazione della conservazione

o Art. 15 – Misure per garantire il diritto di Accesso dell’interessato

o Art. 16 – Misure per garantire il diritto di Rettifica

o Art. 17 – Misure per garantire il diritto alla Cancellazione (“Oblio”)

o Art. 18 – Misure per garantire il diritto alla Limitazione del Trattamento

o Art. 19 – Misure per garantire l’obbligo di Notifica in caso di rettifica o cancellazione dei dati personali o limitazione del Trattamento

o Art. 20 – Misure per garantire il diritto alla portabilità dei dati

o Art. 21 – Misure per garantire il diritto di Opposizione

o Art. 22 - Misure per garantire la sicurezza in caso di processo decisionale automatizzato relativo alle persone fisiche, compresa la profilazione

- un piano di implementazione del sistema che tenga conto delle fasi progettuali e delle relative tempistiche, descritte successivamente.

Riguardo all’esercizio operativo del sistema, nel DPD dovrà essere documentato come il Fornitore intenda rispondere ai requisiti relativi alla gestione della fornitura e come intenda gestire l’intero ciclo di vita della soluzione per tutta la durata contrattuale. Dovranno essere, tra l’altro, documentate in dettaglio le attività e la responsabilità del Fornitore. Relativamente all’eventuale sviluppo di componenti software specifiche, si ricorda che la proprietà del codice è della Regione Abruzzo.

Tale documento, sarà soggetto ad una valutazione ed approvazione da parte del Committente ai sensi della L.R. 14 marzo 2000, n. 25 e successiva DGR n. 367 del 06.07.2020 avente ad oggetto “Organizzazione del comparto sistemi informativi e telematici”.

Il Committente si riserva dunque la facoltà di richiederne eventuali modifiche e/o aggiornamenti mentre è onere dell’aggiudicatario impegnarsi ad eseguire tutte le eventuali modifiche al DPD entro 5 gg lavorativi dalla ricezione delle osservazioni da parte del Committente.

A seguito dell’approvazione del DPD, il Fornitori procederà alla relativa attuazione, che dovrà prevedere l’esecuzione delle configurazioni necessarie per eseguire il rilascio, i test ed il collaudo della soluzione ‘trasversale’.

Successivamente verrà eseguito il deploy della soluzione trasversale nonché il relativo collaudo, che dovrà essere eseguito relativamente ad una prima struttura ospedaliera, che funzioni da pilota per le successive strutture sanitarie.

Il collaudo dovrà essere eseguito sulla base di un piano concordato con l’ES e contenente modalità e tempistiche per ogni tipologia di test, i casi d’uso coperti dal test e le funzionalità impattate. Dovranno essere eseguite le principali tipologie di test:

Principali tipologie di test
Tipo di test	Deliverable
Funzionali	Verbale di esecuzione dei test funzionali con il relativo esito


Di sicurezza	Verbale di esecuzione dei test di sicurezza
Di integrazione	Verbale di esecuzione dei test di integrazione
Test di non regressione	Verbale di esecuzione dei test di non regressione

Tabella 3: Principali tipologie di test

Tra i test di sicurezza, dovrà essere prevista l’esecuzione di specifici Vulnerability Assessment e Penetration Test da parte del Committente. Tali test potranno essere periodicamente effettuati per verificare il mantenimento di un adeguato livello di sicurezza dei sistemi.

Entro i 6 mesi dall’inizio della presente progettualità dovrà essere garantito l’avvio della diffusione della soluzione presso almeno due ES secondo le modalità descritte nel successivo paragrafo.

10.1.2. Fase 2: Formazione, avviamento e completamento della diffusione 7

Come sopra citato, la diffusione della soluzione CCER avverrà in modo tale che entro 6 mesi dall’avvio della presente iniziativa progettuale sia avviata la formazione al personale e che inizi il rilascio di soluzioni verticali da almeno due ES. 8

Entro invece il 24-esimo mese, si prevede che la formazione e il rilascio sia completato per tutte e quattro gli ES.

Riassumendo, la diffusione prevede:

• Deploy della soluzione sull’infrastruttura target e personalizzazioni applicative.

In questa fase ogni ES sarà responsabile della verticalizzazione della CCER entro il loro perimetro di competenza, per cui gli oneri relativi a ogni integrazione, personalizzazione, diffusione sugli ambienti di attuazione e configurazione si ritengono a loro carico.

7 Relativamente a quanto indicato nel par 10.1.2. "In questa fase ogni ES sarà responsabile della verticalizzazione della CCER entro il loro perimetro di competenza, per cui gli oneri relativi a ogni integrazione, personalizzazione, diffusione sugli ambienti di attuazione e configurazione si ritengono a loro carico" si precisa:

1. che tali attività non rientrano nel perimetro di fornitura e che il fornitore dovrà occuparsi delle sole attività di formazione e supporto all'avvio date le verticalizzazioni a carico delle ASL e

2. che sarà responsabilità delle ASL accertarsi che tali verticalizzazioni vengano indirizzate in tempo utile per consentire l'attuazione del piano di roll-out nei successivi 24 mesi come richiesto a pag 63 "Entro invece il 24-esimo mese, si prevede che la formazione e il rilascio sia completato per tutte e quattro gli ES.".

8 si precisa che che il collaudo della soluzione, in caso di scelta dell'approccio orizzontale da parte della ASL, sarà circostanziato alle componenti fornite dalla proponente e quindi senza le verticalizzazioni di cui al par 10.1.2

In parallelo alla fase di diffusione, il Fornitore dovrà organizzare tutte le attività utili ad agevolare l’introduzione della nuova soluzione CCER sia agli utilizzatori finali (personale amministrativo, medico, infermieristico, assistenziale), sia a ruoli chiave all’interno delle strutture tecniche degli ES (Direzione Sistemi Informativi, Help Desk interno, terze parti coinvolte) per un periodo di almeno 90 giorni dal momento dell’installazione della soluzione.

Le attività di formazione dovranno essere preventivamente condivise con l’ES e riportate all’interno di un Piano di Formazione che includa il dettaglio delle attività di formazione previste e il calendario delle giornate di formazione, nonché le modalità di svolgimento che possono prevedere la consegna di un Video Tutorial, descrittivo delle funzionalità principali della soluzione di CCER, da destinare a sessioni di auto-formazione da parte di utilizzatori (medici e altro personale).

10.1.3. Fase 3: Gestione a regime

A seguito dell’avviamento a regime della soluzione CCER, il Fornitore dovrà garantire, fino al termine dell’incarico tutte quelle attività e servizi necessari ad assicurare il corretto funzionamento della soluzione CCER, nel rispetto degli opportuni Livelli di servizio come descritto nel Capitolo 9.

In particolare, le attività necessarie a garantire il corretto funzionamento della soluzione CCER dovranno essere erogate dai gruppi di lavoro che il Fornitore metterà a disposizione per i servizi di:

• Gestione della domanda e Supporto per la pianificazione delle evoluzioni dei servizi: in particolare per quanto riguarda le attività necessarie a monitorare e garantire nel tempo l’allineamento fra le esigenze degli ES e l’evoluzione dei servizi stessi;

• Gestione operativa delle installazioni: per quanto riguarda le attività di assistenza e gestione di servizi applicativi e dell’infrastruttura connessa all’esercizio della soluzione CCER, compresi interventi migliorativi quali ad esempio software;

• Supporto e Manutenzione dei servizi della soluzione CCER: per quanto riguarda le attività di manutenzione di servizi applicativi esistenti e servizi di supporto connessi.

• Assistenza e supporto applicativo: per quanto riguarda le attività di assistenza specialistica di servizi applicativi, Help Desk di II° Livello;

• Delivery della soluzione CCER: per le attività necessarie a far evolvere le soluzioni in esercizio negli ES (ad es. effettuare i rilasci delle versioni della soluzione CCER contenenti migliorie ed evoluzioni).

Resta inteso che durante la fase di esercizio e dunque per tutta la durata del contratto il Fornitore dovrà garantire i servizi necessari ad assicurare il corretto funzionamento della soluzione CCER, nel rispetto degli opportuni Livelli di servizio come descritto nel Capitolo 9.

10.2. Servizi professionali

L’iniziativa dovrà essere accompagnata da una gamma di servizi professionali di natura tecnica e gestionale atti a supportare la transizione al nuovo servizio, nonché orientati alla efficace operatività della soluzione stessa.

Tali servizi definiscono le responsabilità e il perimetro di azione del Fornitore tanto che potranno essere richiesti dagli ES in sede di esecuzione contrattuale.

10.2.1. Servizi applicativi

• Project management dell'iniziativa: rientrano in queste attività il coordinamento gestionale e amministrativo dell’iniziativa complessiva ed il supporto agli ES nella gestione dei singoli cantieri di lavoro per tutta la durata dell’iniziativa.

• Analisi, Progettazione, Pianificazione della delivery: rientrano in queste attività la progettazione, realizzazione e declinazione sul contesto abruzzese della suite di servizi e soluzioni applicative facenti parte della soluzione CCER. In particolare, tali attività riguarderanno:

o La definizione delle specifiche funzionali e di interfaccia;

o La definizione delle specifiche di interfaccia verso i sistemi informativi esterni;

o La definizione delle specifiche tecniche del software;

o Il test delle componenti software.

• Delivery e Supporto alla messa in esercizio: rientrano in queste attività tutti quei servizi di supporto alla fase di implementazione della soluzione CCER, della sua diffusione e del governo complessivo del sistema, nonché le attività specialistiche lato Fornitore volte all’integrazione della soluzione CCER con i sistemi applicativi dell’ES.

• Gestione operativa delle installazioni, Tuning, Monitoraggio della soluzione CCER: rientrano in queste attività tutti i servizi di manutenzione, assistenza ed esercizio della CCER sia nella sua versione originaria sia con le eventuali personalizzazioni, aggiornamenti e implementazioni introdotti nel tempo a partire dal completamento della prima attivazione della Fornitura agli ES fino al termine del contratto.

• Pianificazione e realizzazione delle evoluzioni dei servizi: rientrano in queste attività tutti i servizi di vera e propria evoluzione della soluzione CCER complessiva e dei servizi correlati, intesi come sviluppo di nuovi sistemi e/o funzionalità specifiche (ad es. sviluppo di software ad hoc), che potranno essere richieste dagli ES

10.2.2. Servizi applicativi a richiesta

Gli ES potranno avvalersi, sulla base delle loro esigenze di servizi applicativi a richiesta dal singolo ES, delle seguenti tipologie:

• Manutenzione evolutiva aggiuntiva rispetto alle giornate definite per la MEV;

• Realizzazione di integrazioni non standard.

Tali servizi saranno remunerati sulla base delle giornate erogate a partire dalle tariffe definite nell’ambito della gara, prevedendo alcune configurazioni di pacchetti predefiniti di giornate (es. giornate per supporto on-site ulteriore).

10.3. Gestione della fornitura

L'impianto contrattuale con il Fornitore, individuato tramite procedura di gara, prevedrà un contratto esecutivo singolare per ASL.

10.3.1. Governo della Fornitura

In questa sede non verranno quindi imposti vincoli sull’organizzazione che il Fornitore dovrà dare alle proprie risorse, ma solo per quanto riguarda Competenze/Ruoli chiave. A questo proposito, sarà onere del Proponente fornire evidenza della qualità dell’organizzazione e delle figure proposte.

Allo stesso modo, sarà imprescindibilmente necessaria l’adozione, documentata, di un modello di governo secondo metodologie di riferimento quali il Framework PMBoK (Project Management Body of Knowledge del Project Management Institute), PRINCE/PRINCE2 (PRojects IN Controlled Environments), o analogo framework riconosciuto di project management per la pianificazione e sussiva gestione di ogni fase dell’iniziativa. Coerentemente con la metodologia scelta, sarà poi opportuno effettuare, fin dall'inizio della Fornitura, un tailoring sulla base delle specifiche esigenze e del contesto organizzativo in essere.

Sarà, inoltre, necessario l’utilizzo, documentato, del Framework ITIL, COBIT (Control Objectives for Information and related Technology (COBIT), CMMI (Capability Maturity Model Integration) o analogo framework di gestione dei processi per l’implementazione dei processi di erogazione dei servizi richiesti. Il Fornitore è tenuto a documentare come ha adottato e intende implementare una

metodologia di lavoro strutturata per la gestione operativa dei servizi applicativi e dei servizi professionali richiesti.

Infine, tutte le procedure di realizzazione ed esecuzione dovranno essere coerenti con lo standard ISO/IEC 80001 “Application of risk management for IT-networks incorporation medical devices”.

La Regione si riserva di valutare e segnalare incompatibilità del personale predisposto dal Proponente per l’erogazione della Fornitura e richiederne la sostituzione, con istanza insindacabile.

In caso di variazione al gruppo di lavoro, il Proponente dovrà assicurare alle nuove risorse un periodo di affiancamento come da Livelli di servizio, senza ulteriori oneri.

10.3.2. Gestione del contratto con il Fornitore e relative tempistiche

I momenti di controllo e verifica dell’andamento della fornitura sono costanti per tutta la durata del contratto esecutivo e garantiscono una visibilità completa e dettagliata dell’avanzamento delle attività. Le attività di verifica e controllo riguardano:

• verifica dell’andamento operativo della fornitura (SAL Operativo);

• verifica dell’andamento economico e generale del contratto (SAL Economico-Generale).

Il dettaglio è riportato nella tabella che segue.

Dettagli su attività di verifica e controllo
Attività di verifica	Oggetto	Finalità	Attori	Frequenza	Output
SAL OPERATIVO	Uno o più Servizi/attività	Monitoraggio attività operative, controllo costi e attestazione di consegna dei rilasci, controllo della qualità della fornitura e del rispetto degli SLA definiti	Referente nominato dalla regione e referente del Fornitore	Mensile o su richiesta dell’Ente.	Verbale di SAL
SAL ECONOMICO - GENERALE	Intero contratto esecutivo	Verifica costi, consumi e andamento generale del contratto	Referente nominato dalla regione e referente del Fornitore	Su richiesta dell’Ente.	Verbale di SAL

Tabella 4: Dettagli su attività di verifica e controllo

10.3.3. Ruoli di Governo

Di seguito sono descritti i principali attori coinvolti nel governo della Fornitura.

Responsabile del Contratto del Fornitore

Il Fornitore dovrà individuare un proprio Responsabile del Contratto che costituirà il suo punto di riferimento nei confronti della Regione per tutte le necessità di governo del contratto.

Comitato di Direzione

Al fine di esercitare il controllo sull’attuazione generale del Servizio Regione avrà facoltà di definire un Comitato di Direzione.

Il Comitato di Direzione eserciterà il controllo strategico sul Servizio e sarà incaricato della valutazione dello stato di avanzamento complessivo.

10.3.4. Principali processi di Governo

Di seguito vengono descritti i principali processi di Governo che regolamentano la gestione dei rapporti fra ES, Regione e Fornitore.

Gli organismi di Governo gestiranno i seguenti processi principali:

• Determinazione delle penali;

• Avvio dell’erogazione della Fornitura;

• Processi di audit;

10.3.5. Gestione operativa della Fornitura

Le funzioni di erogazione dei servizi agiscono sotto il coordinamento dei ruoli di governo. Hanno una autonomia organizzativa e operativa, ma sono al tempo stesso allineate tra loro e alle funzioni di governo da un framework di obiettivi coerente. Le parti che seguono hanno l’obiettivo di specificare ruoli e responsabilità di una figura che si ritiene siano chiave in termini di interfaccia operativa tra fornitore e Regione. Di seguito si descrivono le competenze del Project Manager di cantiere che il Fornitore dovrà indicare quale referente operativo per la realizzazione di quanto previsto contrattualmente.

Si precisa che il Project Manager di cantiere dovrà essere il riferimento di più alto livello per la gestione del progetto nel suo complesso e per la risoluzione delle potenziali problematiche che potrebbero presentarsi.

Al fine di garantire un efficace coordinamento e monitoraggio delle attività effettuate il singolo Project Manager di cantiere dovrà garantire un supporto continuativo e dedicato; pertanto, il

Fornitore dovrà considerare il suo impegno, nel periodo compreso tra la data di avvio del progetto e la conclusione.

Relativamente alle caratteristiche richieste per tale tipologia di profilo (Project Manager) si prega di far riferimento a quelle esplicitate all’ Appendice 1A (“Profili Professionali”) Al Capitolato Tecnico Speciale dell’Accordo Quadro CONSIP “Servizi Applicativi in ambito “SANITA’ DIGITALE - Sistemi Informativi Clinico-Assistenziali” Per Le Pubbliche Amministrazioni del SSN”

10.4. Manutenzione, Assistenza, Conduzione Applicativa e rendicontazione

10.4.1. Manutenzione

Il Fornitore dovrà garantire la manutenzione sui sistemi e applicativi preposti all’erogazione della Fornitura come:

• Manutenzione correttiva: comprende tutti gli interventi volti ad indagare e rimuovere le cause e gli effetti di eventuali malfunzionamenti dei sistemi e applicativi preposti all'erogazione della soluzione CCER che determinano un comportamento del sistema difforme da quello definito in specifica, anche in termini di prestazioni, assicurando il ripristino dell’operatività. Sono parte di tali interventi;

o La presa in carico delle segnalazioni di malfunzionamento, la loro gestione e risoluzione;

o I contributi di competenza sistemistica e specialistica necessari alla corretta soluzione del malfunzionamento;

o Il ripristino di basi dati danneggiate dagli errori;

o Il ripristino di software malfunzionanti;

o La modifica della documentazione per il mantenimento della coerenza con quanto erogato.

La manutenzione correttiva è compresa nella Fornitura.

• Manutenzione evolutiva (MEV): comprende tutti gli interventi atti ad introdurre nel sistema corrente nuove funzionalità o modificare e rimuovere funzionalità esistenti. L'intervento sarà realizzato su richiesta degli ES tramite interventi del Fornitore "a corpo". Il Fornitore sarà tenuto a rispondere alla richiesta di intervento proponendo un progetto di lavoro e la stima dell’impegno necessario, che saranno oggetto di validazione da parte degli ES e della

regione Abruzzo. Le attività erogate saranno remunerate secondo le modalità previste per i

Servizi professionali a richiesta.

10.4.2. Assistenza

Il fornitore dovrà integrarsi con i dipartimenti e procedure e predisposti all’assistenza presenti negli ES e garantire la gestione dei ticket e richieste di assistenza. Il Fornitore dovrà garantire assistenza e supporto all’utenza mediante un servizio di helpdesk di primo e secondo livello. Per le chiamate inerenti alla segnalazione di guasti e malfunzionamenti o alle richieste di assistenza di qualsiasi genere, deve essere definito un riferimento unico e indistinto per le varie componenti software del nuovo Sistema. Tale servizio viene attivato:

• Dal servizio di help-desk di primo livello dell’Azienda, a fronte di richieste e segnalazioni di guasto, da parte degli utenti, che non possono essere risolte dallo stesso.

• Da richieste del personale ICT dell’Azienda per problematiche afferenti al Sistema Informativo comprese le integrazioni.

• Da richieste del personale aziendale referente per ambito di attività.

• Da allarmi del sistema di monitoraggio aziendale.

Il Fornitore dovrà mettere a disposizione idonee procedure operative di verifica sui sistemi/servizi oggetto di Fornitura, nonché raccogliere le casistiche di segnalazione/soluzione in un apposito sistema di Knowledge Base condiviso tra gli ES, destinato alla esecuzione semplice e rapida di operazioni basiche da parte degli operatori degli ES di I livello.

Nell’ottica di garantire la fruibilità della soluzione CCER, l’assistenza di II livello richiesta in generale dovrà:

• Prendere in carico le segnalazioni ricevute da parte di operatori, da parte del sistema di help- desk di primo livello o dal sistema di monitoraggio aziendale;

• Risolvere le segnalazioni in merito a problematiche riscontrate nel rispetto dei Livelli di servizio contrattuali;

• Gestire le segnalazioni e le comunicazioni agli interlocutori indicati dall'ES in caso di anomalie/incidenti;

• Supportare, ove necessario, gli ES nell’utilizzo della soluzione CCER;

• Predisporre e realizzare tutti gli interventi di supporto nelle fasi di avviamento di una nuova funzionalità o di una personalizzazione di funzionalità già in esercizio;

• Eseguire estrazioni estemporanee di dati.

Il servizio richiesto ha la responsabilità di affrontare e risolvere i problemi segnalati; in particolare, dovrà garantire:

• Accettazione e registrazione o presa in carico della richiesta di assistenza ricevuta tramite i canali definiti con assegnazione del livello di urgenza;

• Analisi del problema e risoluzione;

• Comunicazione tempestiva ed efficace con i livelli di assistenza o direttamente con gli interlocutori dell'ES interessato;

• Chiusura della richiesta di assistenza ed eventuale verifica con gli interlocutori dell'ES interessato in caso di segnalazioni dirette;

• Fornire supporto per l’affiancamento a primi gruppi di utenti ed eventuale partecipazione per la preparazione ed erogazione degli interventi formativi mirati all’utilizzo delle applicazioni in caso di avviamento di nuove funzionalità o di nuovi servizi.

In caso di problemi che richiedano modifiche di prodotto dovranno essere fornite, ove possibile, soluzioni temporanee (workaround).

L’assistenza del Fornitore dovrà inoltre garantire un costante e continuo allineamento delle strutture di I livello competenti degli ES durante la risoluzione delle problematiche più complesse o nei casi in cui siano richiesti tempi più lunghi di lavorazione per la risoluzione e la chiusura del problema segnalato (sempre nel rispetto dei Livelli di servizio contrattuali).

Per una corretta erogazione dell'assistenza è necessario effettuare una classificazione dei possibili malfunzionamenti in modo da attribuire correttamente l’urgenza da associare ad ogni segnalazione.

Al Fornitore è richiesta l’assistenza H24, 7 giorni su 7.

10.4.3. Conduzione applicativa

Al Fornitore è richiesto il servizio di “Conduzione Applicativa - Gestione applicativi e base di dati”, secondo quanto descritto nel Capitolato Tecnico Speciale del dell’Accordo Quadro CONSIP “Servizi Applicativi in ambito “SANITA’ DIGITALE - Sistemi Informativi Clinico-Assistenziali” Per Le Pubbliche Amministrazioni del SSN”, le attività del servizio trovano collocazione rispetto alla maggior parte delle fasi previste.

10.4.4. Rendicontazione

La Fornitura dovrà fornire un ambiente di rendicontazione in grado di presentare, tramite cruscotti informativi e rapporti di dettaglio, i valori aggiornati e su base storica di una serie di indicatori di erogazione della Fornitura.

I cruscotti e i rapporti, specifici nei contenuti offerti in funzione del fruitore cui sono indirizzati, dovranno fornire un resoconto sul funzionamento della soluzione CCER, sia in termini di volumi di studi e referti lavorati che di performance erogate, ed essere prodotti dinamicamente sulla base di parametri di indagine (ad es. periodo di osservazione, tipologia documentale, ecc.) definiti dall'operatore. Dovranno in particolare essere resi disponibili specifici rapporti finalizzati al calcolo dei costi della Fornitura, sia per il controllo dei costi da parte dei singoli ES, sia per il monitoraggio complessivo da parte di regione Abruzzo.

L’ambiente di rendicontazione dovrà permetterne la consultazione, l’archiviazione e il download su postazione di lavoro dei rapporti prodotti in formati standard o di mercato ad alta diffusione (quali ad esempio PDF, Excel, Libreoffice, ecc.).

Infine, come già precedentemente descritto, il Fornitore dovrà mettere a disposizione un sistema professionale di performance monitoring per l’intera durata contrattuale (sia in sede di collaudo che in sede di erogazione a regime) finalizzato alla misurazione end-to-end del numero di richieste gestite dal sistema e dei tempi di consegna degli studi.

La definizione dei contenuti dei cruscotti e dei rapporti dovrà essere prodotta dal Fornitore secondo uno schema condiviso e validato dagli ES.

10.5. Exit Strategy

Nella presente sezione vengono descritte le attività e le procedure che saranno richieste al Fornitore nella fase finale del rapporto contrattuale, per il passaggio delle consegne al personale del Committente, per le aree di competenza previste, e per il trasferimento di tutte le conoscenze necessarie a garantire la fluida transizione nella erogazione e la continuità operativa per l’utenza dei servizi in fornitura del Committente. Al fine di garantire la corretta pianificazione di questa fase, dovrà essere redatto dal fornitore e approvato dai singoli ES il Piano di trasferimento (PTF), modificabile secondo le esigenze e richieste degli ES che potrebbero occorrere durante la fase di trasferimento.

Alla scadenza del contratto il Proponente presterà l’assistenza necessaria a trasferire la gestione dei servizi al Committente o ad una terza parte da esso individuata per un periodo pari al minimo agli ultimi due (2) mesi di contratto.

La fase di Exit management, oltre a quanto detto, contempla i seguenti aspetti:

• Fornitura del servizio e delle modalità di garanzia di continuità nella fase di trasferimento;

• Gestione del processo di trasferimento: ruoli, responsabilità, autorizzazioni e risorse da assegnare;

• Diritti di proprietà intellettuale: accordi necessari, licenze, codice (ove previsto), etc.;

• Due diligence: definizione della documentazione e dei contenuti da trasferire ad un altro Fornitore subentrante, nonché la definizione delle altre obbligazioni e penalità previste;

• Contratti e licenze;

• Sicurezza;

• Piano di comunicazione.

In particolare, sulla base dei contenuti e delle caratteristiche qualificanti dell’attività di Exit, il Proponente si deve impegnare durante la fase finale, fino al termine del periodo contrattuale a soddisfare i seguenti requisiti generali:

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

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

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

La proposta di una adeguata strategia di Exit sarà oggetto di approfondita valutazione tecnica.

Di seguito si riporta una traccia dei contenuti e delle caratteristiche qualificanti dell’attività di Exit, che dovranno essere progettate e gestite di concerto con il Committente:

• Piano di Trasferimento: Le attività di affiancamento e rilascio sono specificate e governate dal PTF, in cui saranno riportate tutte le attività previste in termini di tempi, risorse impiegate, punti di verifica e controllo dei risultati attesi, criteri di accettazione, i rischi, la cadenza degli incontri per la verifica dello stato di avanzamento delle attività;

• Responsabilità: durante il periodo di affiancamento e migrazione al termine del Contratto, la responsabilità del Servizio viene mantenuta dal Fornitore fino al termine previsto contrattualmente.

• Governo del processo: il Fornitore assicura tutte le attività finalizzate a coordinare e verificare la corretta ed efficace esecuzione delle attività di Affiancamento e Rilascio nel rispetto dei termini concordati nonché la coerenza con i requisiti, i vincoli ed i termini stabiliti nei documenti contrattuali; a tale scopo viene individuata una figura unica per il Fornitore (Project Manager) che coordinerà tutte le attività e che interfaccerà il Committente ovvero l’eventuale Fornitore terzo subentrante;

• Continuità dei servizi: al fine di garantire al Committente il mantenimento dei richiesti livelli di servizio da parte del subentrante, nel Piano di Transizione sono previste fasi di verifica e validazione sia del trasferimento di know-how che del rilascio della documentazione; altresì, contestualmente al trasferimento delle conoscenze, si prevede un adeguato periodo di affiancamento delle risorse del subentrante nella operatività corrente del Fornitore uscente;

• Risorse professionali: un gruppo di risorse del Fornitore appositamente designato affiancherà le risorse del Committente e/o del Fornitore subentrante per il trasferimento delle conoscenze sui servizi e sulle relative attività di gestione; il team sarà composto da personale già impegnato nell’erogazione dei servizi.

11. LIVELLI DI SERVIZIO (O SLA)

In questa parte del documento si definiscono gli indicatori atti a descrivere i Livelli di qualità dei Servizi (LdS), che verranno applicati alle forniture oggetto dell’Appalto, le relative modalità di rilevazione, i Livelli di servizio minimi richiesti e il periodo di misurazione su cui calcolare il valore dell’indicatore.

Il Fornitore, durante l’intera durata dell’incarico, dovrà periodicamente produrre e consegnare specifici rapporti di dettaglio che verranno utilizzati per la valutazione del rispetto dei Livelli di servizio costruiti secondo formati e contenuti coerenti con la tipologia dell'indicatore in esame e con periodicità congruente con il relativo periodo di riferimento. La struttura dei rapporti dovrà essere prodotta dal Fornitore secondo uno schema condiviso e approvato dagli ES e da regione Abruzzo. Per alcuni Livelli di servizio, esplicitamente indicati, le informazioni elementari raccolte dal Fornitore per il calcolo degli stessi dovranno essere registrate, su base giornaliera, in specifici file in formato.csv, che dovranno:

• Possedere un identificativo progressivo;

• Essere marcati temporalmente.

Si precisa che tali file dovranno essere prodotti, su un template condiviso e approvato dagli ES e da Regione, e inviati agli stessi e potranno essere utilizzati per verificare la correttezza dei report dei Livelli di servizio.

Indipendentemente dal periodo di consuntivazione (variabile in relazione allo specifico indicatore) il Fornitore è tenuto ad uno stretto controllo dell’andamento dei livelli qualitativi dei servizi offerti per intervenire tempestivamente nel ripristino dei valori target non appena si rilevino deviazioni significative. Il non rispetto dei Livelli di servizio in seguito alla rilevazione del superamento dei valori di soglia crea le condizioni per azioni contrattuali.

I Livelli di servizio che trovano applicazione in questa gara sono relativi alla richiesta di fornitura e sono definiti a partire dall’allegato 2 del Capitolato Tecnico Speciale dell’AQ “Servizi Applicativi in ambito “SANITÀ” DIGITALE - Sistemi Informativi Clinico-Assistenziali” per Le Pubbliche Amministrazioni del SSN”, suddivisi nelle seguenti macrocategorie:

1. Governo della fornitura;

2. Servizi realizzativi, in relazione al collaudo della soluzione acquistata ed i servizi di MEV;

3. Manutenzione Correttiva (MAC) e Adeguativa (MAD);

4. Conduzione Applicativa;

5. Servizio Conduzione Tecnica;

Relativamente alle tipologie di azione contrattuale per singolo LdS e alla loro descrizione di dettaglio si prega di far riferimento a quelle esplicitate all’ Appendice 2 (“Livelli di Servizio”) al Capitolato Tecnico Speciale dell’Accordo Quadro CONSIP “Servizi Applicativi in ambito “SANITA’ DIGITALE - Sistemi Informativi Clinico-Assistenziali” Per Le Pubbliche Amministrazioni del SSN”. Nello specifico viene definita la matrice di corrispondenza tra gli Indicatori di Qualità validi per l’intera fornitura e le azioni contrattuali previste nel caso di non rispetto dei valori di soglia, ovvero rilievo, quota sospesa e penale.

Oltre ai Livelli di Servizio sopra citati, è stato aggiunto un ulteriore livello (non presente nell’AQ CONSIP ma ritenuto fondamentale) denominato “Produzione dei rapporti dei LdS”, a cui viene richiesto al Fornitore di adempiere.

Si precisa che qualora il Fornitore abbia dichiarato nella propria Offerta Tecnica il miglioramento dei valori di soglia rispetto a quanto indicato nel presente documento, gli scostamenti al fine dell’applicazione delle penali saranno calcolati rispetto ai valori soglia dichiarati nell’Offerta Tecnica.

I Livelli di servizio descritti ai punti precedenti saranno misurati negli orari di seguito indicati, fatto salvo dove diversamente specificato.

• punti 1) e 5): dalle ore 9.00 alle ore 18.00, da lunedì a venerdì, festività escluse;

• punti 2), 3), 4), e 6): H24, 365 gg./anno;

Ciascun Livello di servizio riporta le modalità di applicazione delle sanzioni in caso di scostamenti rispetto alla soglia definita. Rimarrà facoltà dell’ES l’applicazione di penali di entità minore a quelle previste, sulla base di valutazioni inerenti al grado di responsabilità del Fornitore nel mancato rispetto del Livello di servizio. Tutti i Xxxxxxx di servizio si intendono sempre applicati a livello di singolo ES, salvo ove diversamente precisato. Nei prossimi paragrafi sono presentate ulteriori indicazioni.

11.1. Governo della fornitura

Di seguito sono descritti gli indicatori per misurare i livelli di servizio nell’ambito del governo della fornitura.

Dettagli sulla misurazione dei livelli di servizio
ID	CODICE	DESCRIZIONE
SLA-1.1	RSER	Impegni rispettati in offerta tecnica
SLA-1.2	TIP	Tempestività nell’inserimento di personale
SLA-1.3	RSCT	Rispetto di una scadenza contrattuale
SLA-1.4	MAPP	Mancata Approvazione di un Artefatto della Fornitura
SLA-1.5	VQF	Valutazione Qualità della Fornitura
SLA-1.6	RLFN	Rilievi sulla fornitura
SLA-1.7	MIDG	Monitoraggio indicatori di digitalizzazione
SLA-1.8	TAI	Tempo di Attivazione degli Interventi
SLA-1.9	INPF	Indisponibilità Portale di Fornitura
SLA-1.10	ATPF	Mancata Attivazione Portale di Fornitura

Tabella 5: Dettagli sulla misurazione dei livelli di servizio

Di seguito si riportano le metriche per la definizione dei livelli di servizio sopra indicati.

SLA 1.1 - RSER

L’indicatore di qualità verifica il numero di impegni rispettati dal Fornitore in offerta tecnica, afferenti obbligazioni contrattuali non adempiute nei tempi e/o nei modi rappresentati nel Contratto Quadro e/o nei Contratti esecutivi con relativi allegati e/o tracciati sui Piani di lavoro, siano esse presidiate da specifici indicatori o non presidiate.

Tabella 6: SLA 1.1 - Impegni rispettati in offerta tecnica

SLA 1.2 - TIP

Con questo indicatore si misura la tempestività nell’inserimento/sostituzione delle risorse impiegate nella fornitura, compresi i Referenti.

Tabella 7: SLA 1.2 – Tempestività nell’inserimento di personale

SLA 1.3 - RSCT

L’indicatore misura il rispetto di scadenze temporali derivanti dalla documentazione contrattuale inclusa l’offerta tecnica del fornitore e/o pianificate in un piano di lavoro approvato.

Tabella 8: SLA 1.3 – Rispetto di una scadenza contrattuale

SAL 1.4 - MAPP

L’indicatore misura l’inadeguatezza o incompletezza di Artefatti soggetti ad approvazione quali i prodotti del processo di sviluppo software: documento di Stima, Piano di Lavoro, Documento dei Requisiti, Analisi, Disegno, Documento di Architettura, Rapporti di Esecuzione Test, ecc...

La mancata approvazione è equiparata a mancata consegna. Il ritardo sulla riconsegna del documento viene misurata dagli specifici indicatori di ogni servizio.

Tabella 9: SLA 1.4 – Mancata Approvazione di un Artefatto della Fornitura

SLA 1.5 - VQF

L’indicatore costituisce un indice sintetico della qualità misurata e percepita del contratto esecutivo, rilevato secondo quanto specificato al par. “Rilevazione della Qualità della Fornitura” del Capitolato Tecnico Speciale.

Aggiunge alla componente oggettiva, derivante dalla rilevazione di tutti gli indicatori applicabili alla fornitura, una componente soggettiva derivante dalla misura dell’esperienza d’uso dei servizi da parte degli utenti e dell’Amministrazione.

Tabella 10: SLA 1.5 - Valutazione Qualità della Fornitura

SLA 1.6 - RLFN

L’indicatore conteggia le non conformità rilevate dall’Amministrazione per obbligazioni contrattuali non adempiute nei tempi e nei modi previsti, siano esse rilevate da specifici indicatori o non conformità, non presidiati da specifici indicatori.

Tabella 11: SLA 1.6 - Rilievi sulla fornitura

Tabella 12: SLA 1.7 – Monitoraggio indicatori di digitalizzazione

SLA 1.7 - MIDG

L’indicatore misura il rispetto delle tempistiche nella raccolta delle informazioni ai fini della determinazione degli indici di digitalizzazione di cui al paragrafo 6 dell’Appendice 2 - Livelli di Servizio del Capitolato Tecnico Speciale dell’Accordo Quadro Consip.

SLA 1.8 - TAI

L’indicatore TAI misura la tempestività di attivazione degli interventi relativi ai servizi previsti nel Contratto Esecutivo, a partire dalla richiesta dell’Amministrazione.

SLA 1.9 - INPF

L’indicatore verifica gli eventi imputabili al Fornitore, che non assicurino la disponibilità, la raggiungibilità tramite Internet in una logica multicanale, e la piena operatività del “Portale della Fornitura”, tali da non consentire alle singole Amministrazioni ed agli Organismi di coordinamento e controllo di attivare e governare agevolmente i servizi.

Tabella 13: SLA 1.9 - Indisponibilità Portale di Fornitura

SLA 1.10 - ATPF

L’indicatore verifica l’attivazione del “Portale della Fornitura”.

Tabella 14: SLA 1.10 - Mancata Attivazione Portale di Fornitura

11.2. Collaudo

Essendo il periodo di collaudo finalizzato alla verifica e validazione del sistema rilasciato è considerata fisiologica una difettosità residua rispetto alle attività di test effettuate dal fornitore. Tale fisiologica difettosità residua comprende malfunzionamenti di categoria non bloccante nonché test negativi eseguiti con modalità differenti rispetto a quanto dichiarato dal fornitore. Diversamente trattasi di malfunzionamenti bloccanti come disciplinato dal successivo indicatore DFCC – Difettosità in collaudo. Tutti i malfunzionamenti e le non conformità devono essere risolte per l’accettazione del software.

Il fornitore deve assicurare il supporto e garantire la tempestiva correzione degli errori sul software e sulla documentazione entro e non oltre i tempi previsti dal TRCG – Tempestività di Ripristino dell’Operatività in collaudo ed in garanzia (cfr. paragrafo successivo). Si specifica che sono bloccanti le non conformità relative a:

• Sicurezza e Protezione dei dati: per tutti gli interventi realizzativi, ivi compresi gli interventi di correttiva;

• Manutenibilità, Interoperabilità, Efficienza prestazionale, Affidabilità: per tutti gli interventi che realizzano servizi IT;

• Manutenibilità e Affidabilità: per tutti gli interventi realizzativi su applicazioni di classe A;

• Usabilità e Portabilità per tutti gli interventi che realizzano/modificano servizi esposti all’esterno (siti, portali, app mobili).

Negli altri casi – fermo restando che tutte le non conformità devono essere risolte per l’accettazione del software – saranno considerate non bloccanti.

Di seguito sono descritti gli indicatori per la fase di collaudo definiti dall’AQ:

Fase di collaudo definiti dall’AQ
ID	CODICE	DESCRIZIONE
SLA-2.1	GSCO	Giorni di sospensione del collaudo
SLA-2.2	DFCC	Difettosità in collaudo;

Tabella 15: Fase di collaudo definiti dall’AQ

SLA 2.1 - GSCO

La sospensione del collaudo è indice di una grave carenza qualitativa e incompletezza della soluzione richiesta.

La sospensione può attivarsi automaticamente alla presenza di malfunzionamenti bloccanti in collaudo come disciplinato nell’indicatore DFCC – Difettosità in collaudo, o su decisione dell’Amministrazione qualora si verifichino situazioni “anomale” che, a giudizio della stessa, sia per numerosità sia per gravità, sia per non rispetto dei tempi massimi previsti per la risoluzione delle difformità, non consentano lo svolgimento o la prosecuzione delle attività.

Costituisce altresì causa di sospensione un Piano di Test del fornitore con carenze tali da compromettere l’esecuzione del collaudo e/o il riscontro di almeno un test con esito negativo (rispetto a quanto dichiarato positivo dal fornitore nel Rapporto di esecuzione test).

La sospensione del collaudo comporta lo slittamento del termine pianificato e tale ritardo sarà a totale carico del Fornitore comportando le azioni contrattuali previste dal presente indicatore. La consegna della versione corretta dei prodotti dovrà avvenire entro il nuovo termine fissato dall’Amministrazione.

In caso di più di 2 sospensioni sul medesimo obiettivo l’Amministrazione si riserva la facoltà di dichiarare “non approvabile/accettabile” il prodotto oggetto di collaudo per inadempimento del Fornitore come previsto dal Contesto Applicativo “Modalità di Approvazione dei prodotti” del paragrafo 8.2 dell'Allegato 2 del Capitolato Tecnico Speciale dell'Accordo Quadro Consip". Si precisa che la tabella riferibile all'indicatore GSCO è la Tabella 17.

Tabella 16:

SLA 2.2 - DFCC

L’indicatore misura il numero di non conformità bloccanti rilevate in collaudo.

Tabella 17: SLA 2.1 – Giorni di sospensione del collaudo

Tabella 18: SLA 2.2- Difettosità in collaudo

11.3. Servizi realizzativi

Di seguito sono descritti gli indicatori di qualità da applicarsi ai Servizi Realizzativi di prodotti software che nell’ambito della presente iniziativa si applicano ai servizi di manutenzione evolutiva (MEV) e deploy della soluzione richiesta.

Qualità da applicarsi ai Servizi Realizzativi di prodotti software
ID	CODICE	DESCRIZIONE
SLA-3.1	RSPL	Rispetto del Piano di lavoro di obiettivi
SLA-3.2	DAES	Difettosità in avvio in esercizio
SLA-3.3	TRCG	Tempestività di Ripristino dell’Operatività in collaudo ed in garanzia

Tabella 19: Qualità da applicarsi ai Servizi Realizzativi di prodotti software

SLA 3.1 - RSPL

L’indicatore RSPL verifica il rispetto della pianificazione di ogni obiettivo, misurando il rispetto della scadenza temporale di ciascuna milestone quali ad esempio:

• la date di consegna degli artefatti per ogni modifica applicativa (la data pianificata di consegna del documento dei requisiti, del documento di analisi e piano di test, del documento di re-design, e così via per ogni artefatto obbligatorio del servizio);

• la data di consegna di ogni artefatto aggiuntivo offerto in offerta tecnica e concordato con l’Amministrazione nel Piano di lavoro;

• la data pianificata di “pronti al collaudo”, la data pianificata di termine collaudo con esito positivo, la data pianificata di rilascio, la data pianificata di termine avvio in esercizio formalmente.

Si precisa che per data effettiva di consegna di un artefatto va considerata la data di consegna del deliverable che soddisfa i requisiti minimi definiti nella documentazione contrattuale.

Pertanto, a titolo esemplificativo:

• una consegna incompleta o parziale non potrà essere considerata efficace e la data di consegna effettiva sarà quella dell’intero prodotto;

• il termine effettivo della fase di collaudo richiede la risoluzione di tutte le anomalie riscontrate nel corso del collaudo medesimo e la riconsegna della documentazione associata.

In ogni caso, si individuano le metriche per la definizione del livello di servizi:

SLA 3.2 - DAES

Il presente indicatore rileva la difettosità residua funzionale e non funzionale.

Relativamente ai servizi esposti all’esterno, devono essere raccolti in particolare l’aderenza ai requisiti di accessibilità, usabilità, sicurezza, prestazioni che devono permettere la piena fruizione delle funzionalità e dei servizi a cittadino/impresa/operatore amministrativo/decisore/ fruitore.

Il periodo di avvio in esercizio è di 3 mesi.

Tabella 20: SLA 3.1 - Rispetto del Piano di lavoro di obiettivi

Tabella 21: SLA 3.2 - Difettosità in avvio in esercizio

SLA 3.3 – TRCG

Il presente livello di servizio si applica a:

• Non conformità funzionali e non funzionali rilevate durante il collaudo.

• Non conformità funzionali e non funzionali rilevate nel periodo di esercizio di funzionalità/servizi rilasciati dal fornitore e dunque in garanzia (le anomalie rilevate nella fase di Avvio in Esercizio dell’obiettivo realizzativo sono considerate unicamente nell’indicatore DAES e pertanto sono escluse dal presente indicatore);

• Non conformità funzionali e non funzionali rilevate nel periodo di post-erogazione ed entro il periodo di garanzia: il software e l’ambiente dovranno essere mantenuti dal fornitore presso la propria struttura sino alla scadenza della garanzia.

Tabella 23: SLA 3.3 - Tempestività di ripristino dell'operatività in collaudo ed in garanzia (parte II)

Tabella 22: SLA 3.3 - Tempestività di ripristino dell'operatività in collaudo ed in garanzia (parte I)

11.4. Conduzione Applicativa & Assistenza

I seguenti indicatori si applicano a tutti i servizi di gestione. Nel caso di attivazione di servizi separati, i livelli di servizio vengono rilevati e calcolati distintamente.

Il fornitore, per i servizi erogati presso la propria sede, deve mettere a disposizione dell’Amministrazione strumenti per la verifica della capacità di gestione delle richieste e della disponibilità del servizio stesso.

Tra tali servizi di gestione, rientrano i servizi professionali descritti nel capitolo 10.4, tra cui i servizi di assistenza.

Per la misura dei livelli di servizio, è possibile utilizzare:

Indicatori su conduzione Applicativa & Assistenza
ID	CODICE	DESCRIZIONE
SLA-4.1	DSGP	Disponibilità dei servizi di gestione del portafoglio applicativo
SLA-4.2	RSCA	Rispetto di una scadenza dei servizi di gestione del Portafoglio
SLA-4.3	TRRA	Tempestività di risoluzione delle richieste di assistenza
SLA-4.4	RSGT	Rilievi sui servizi di gestione del Portafoglio

Tabella 24: Indicatori su conduzione Applicativa & Assistenza

SLA 4.1 - DSGP

L’indicatore misura la disponibilità del servizio secondo i tempi ed i modi definiti nel Contratto Esecutivo, nel Piano di lavoro Generale e Piano di lavoro del servizio, ivi incluse le estensioni di orario di servizio, la reperibilità e l’extra-orario.

Tabella 25: Disponibilità dei servizi di gestione del portafoglio applicativo

Document Metadata

Table of Contents

Capitolato Tecnico

Document Metadata