PACS REGIONALE FVG

Il presente capitolato disciplina, per gli aspetti tecnici, l’affidamento delle attività di conduzione e manutenzione del servizio PACS regionale del Friuli Venezia Giulia (di seguito FVG).

L’Aggiudicatario sarà, pertanto, responsabile del corretto funzionamento del sistema nel suo complesso, della continuità di servizio e della disponibilità, correttezza e completezza dei dati per l’intera durata del contratto.

2. Durata del contratto ‌

Il contratto avrà una durata di 60 mesi a partire dalla data di collaudo positivo del sistema nella sua totalità. Si prevede inoltre l’opzione di proroga per un periodo di 48 mesi ai sensi del D. Lgs. 36/2023 art.120 comma 10, previa richiesta scritta in tal senso espressa dall’Ente appaltante.

Nel periodo contrattuale è prevista l’erogazione di tutti i servizi specificati nel seguito del presente

Capitolato Tecnico.

3. Valore dell’appalto ‌

L’importo a base d’asta è di 12.000.000,00 €, IVA e oneri per la sicurezza pari a 10.000,00€ esclusi. Tali importi devono essere considerati comprensivi di, a titolo non esaustivo:

1. canoni di installazione e/o noleggio per la dotazione di archivi locali e in datacenter INSIEL;

2. canoni di noleggio delle licenze d’uso - base e applicative - di tutti gli applicativi SW, necessari a garantire la piena funzionalità attesa per il sistema;

3. costi per la fase di formazione propedeutica all’avviamento del sistema e per ogni altro evento

formativo durante l’intero periodo contrattuale, sia rivolti a personale sanitario che tecnico;

4. collaudo e costi per l’affiancamento durante la fase di avvio e di messa a regime del sistema;

5. costi per l’assistenza da remoto e on site;

6. costi per tutte le attività di manutenzione per l’intera durata contrattuale.

l prezzi di offerta devono essere intesi come comprensivi di tutte le spese, nessuna esclusa, per:

- il trasporto, l’imballo, lo scarico, l’installazione, il montaggio, gli interfacciamenti con gli applicativi di Insiel S.p.A.;

- viaggi e trasferte;

- condizioni di chiusura del contratto comprensivo degli oneri di phase out e di ogni tipo di supporto per garantire la continuità di servizio nel caso futuro di subentro di un nuovo contratto di fornitura.

4. Obiettivi ‌

Il sistema PACS del FVG gestisce l’archiviazione di tutte le immagini e reperti strumentali biomedicali prodotti a livello multidisciplinare in seno al SSR. Inoltre, il sistema dovrà essere corredato di ogni altro modulo SW in grado di permettere la refertazione diagnostica specialistica – inclusa la redazione dei referti - in radiologia e medicina nucleare, la distribuzione delle immagini a qualsiasi destinatario anche esterno al SSR come i Medici di Medicina Generale (MMG), altri professionisti esterni e il cittadino per mezzo degli opportuni strumenti (FSE).

Il sistema intende perseguire l’utilizzo dei reperti e delle immagini per il loro uso diagnostico,

terapeutico o d’approfondimento o per qualsiasi altra rielaborazione ad uso delle discipline eroganti nel SSR.

Il sistema, inoltre, persegue la condivisione delle immagini al fine di favorire i migliori percorsi di cura e dunque la condivisione, il teleconsulto, l'accesso emergenziale, i gruppi multidisciplinari, lo screening mammografico di II livello, e l’attivazione di percorsi di aumento della qualità d’erogazione dei servizi avvalendosi di strumenti di Intelligenza artificiale e data mining.

La gestione persegue gli obiettivi di massimizzazione e l’appropriatezza dell’utilizzo del sistema, valutando in tal senso in maniera continua le tecnologie software e hardware messe a disposizione degli operatori, senza dimenticare il presidio continuo degli aspetti di sicurezza clinica e informatica.

5. Volumi e profondità temporale ‌

La produzione annuale di riferimento per il dimensionamento dei servizi di gestione del sistema PACS oggetto di fornitura è di circa 1.700.000 esami diagnostici. Infatti, tale dato può essere utilizzato per il dimensionamento iniziale del traffico da gestire e dello spazio di archiviazione

necessario nell’ambito del contratto. Al sistema è richiesta la profondità temporale di CINQUE anni nell’archivio corrente, per poi estendersi a DIECI anni attraverso l’accesso all'archivio di conservazione legale messo a disposizione nell’ambito della piattaforma dei sistemi informativi ospedalieri di INSIEL come da modello di integrazione. In ogni caso, non deve esistere,

nell’esperienza utente offerta dal sistema, nessuna differenza di funzionalità applicativa – o di trattamento a interfaccia utente – tra gli studi recuperati dai diversi archivi. L’unica differenza ammessa eventualmente è la differente performance di recupero.

La dimensione complessiva dell’archivio deve comunque garantire in prospettiva un

incremento annuo stimato in almeno il 10% dell’impegno di archivio dell’anno precedente.

Si conferma che l’archiviazione comprende tutte le discipline in essere nel SSR, comprese quelle di ambito terapeutico, come ad esempio la radioterapia.

La profondità dell’archiviazione corrente deve poter essere tecnicamente almeno raddoppiata, in funzione della possibile attivazione dell’archiviazione dei volumi del servizio dell’anatomia patologica. Tale ipotesi di estensione di fornitura è da considerare quale opzione vincolante per l’operatore economico partecipante alla gara e resta nella facoltà dell’ente appaltante chiedere

l’attivazione nel corso del periodo di validità contrattuale.

6. Descrizione dello scenario da gestire da parte dell’aggiudicatario ‌

Il Servizio Sanitario Regionale del FVG (SSR-FVG) dispone di un impianto PACS di proprietà, di cui, nel seguito del documento, si propone una descrizione delle sue funzionalità e della dimensione quantitativa.

Il servizio di gestione dell’impianto è in scadenza alla fine del 2024 e lo scrivente ente appaltante, su mandato della Regione, intende mantenere ed elevare lo stesso allo stato dell’arte tecnologico e funzionale. Pertanto, ARCS intende individuare, tramite la presente procedura di gara, un unico interlocutore che possa fornire il servizio di gestione che miri alla massima performance, all’efficacia e al più alto livello di sicurezza possibile del sistema PACS FVG.

L'affidamento del servizio di gestione del sistema PACS FVG si declina nella fornitura dei servizi di conduzione e di manutenzione preventiva, correttiva ed evolutiva e dei relativi servizi correlati.

Va premesso che per sistema PACS s’intende l’insieme delle apparecchiature, delle attrezzature informatiche e dei moduli software che gestiscono le immagini - o meglio i reperti strumentali in formato DICOM - biomedicali. Fanno dunque parte del sistema PACS, in generale, tutti gli strumenti in grado di gestire ed elaborare tali oggetti in ogni specialità, ad esempio i vari verticali di reparto (o di parte di esso) di gastroenterologia, radiologia, medicina nucleare, cardiologia, dermatologia, ... .

Il perimetro d’azione dei servizi richiesti – al netto di quanto previsto nel servizio di conduzione, che copre l’intero sistema PACS - è minore di quello individuato alla suddetta definizione e, in particolare per la procedura in oggetto, sono da ritenersi inclusi nel perimetro d’azione dei servizi le aree funzionali di:

- l’archiviazione in maniera trasversale a tutte le discipline. Il sistema, in particolare, gestisce in un unico archivio logico, per ogni Azienda, tutti i reperti indipendentemente dalla disciplina sorgente e provvede direttamente ad alimentare il servizio di conservazione legale sostitutiva messo a disposizione da INSIEL S.p.A.

- la distribuzione delle immagini in maniera trasversale a tutte le discipline

o nelle Aziende – legate a DSE e cartella clinica elettronica

o tra le Aziende – FSE-Operatore

o al Cittadino – FSE (2.0), piattaforma di telemedicina e produzione CD Paziente

- la refertazione verticale, ovvero il completo flusso di lavoro dematerializzato della:

o Radiologia (RIS/Viewer)

o Medicina Nucleare (MIS/Viewer).

All’interno del perimetro i servizi richiesti si sostanziano in due componenti: i servizi veri e propri e la messa a disposizione di tutte le componenti hardware e software necessarie a realizzare le funzionalità che verranno richieste in capitolato.

Resta inteso che, nel dimensionamento richiesto, il sistema PACS e le componenti trasversali si integreranno, senza oneri aggiuntivi per l’Ente Appaltante – siano essi d’integrazione o servizi aggiuntivi - oltre a quelli previsti nella presente procedura, con ogni modulo di elaborazione SW e ogni componente tecnologica di futura acquisizione, per le quali le integrazioni siano implementate secondo standard già supportati. A titolo d’esempio, l’aggiudicatario integrerà senza oneri ulteriori modalità, ulteriori verticali di reparto e viewer che richiamino immagini, con la sola eccezione che il livello di standardizzazione dei livelli d’integrazione delle apparecchiature/applicazioni integrante sia così lacunoso da richiedere all’aggiudicatario sviluppi custom.

La soluzione di tale circostanza verrà discussa caso per caso dall’aggiudicatario e dall’Ente appaltante.

7. Ipotesi alternativa alla presa in carico della manutenzione degli asset esistenti ‌

Il parco degli asset oggetto di servizio è dettagliato in seguito e comprende asset di diversi fornitori. Molti di essi sono – per le caratteristiche di impatto sulla salute dei pazienti – classificati come dispositivo medico.

Per permettere la più ampia progettualità e portare il sistema al più alto livello tecnico/funzionale possibile, è permessa e regolamentata la messa a disposizione di componenti alternative a quelle poste in manutenzione.

Infatti, qualora il Fornitore non sia in grado di eseguire il servizio richiesto su alcune componenti, è sua facoltà avvalersi dei soggetti in grado di farlo, o sostituire le componenti con soluzioni almeno di pari funzionalità e performance che gli permettano di eseguire il servizio, senza alcun onere ed effort aggiuntivo per l’Ente appaltante, né per alcuna Azienda a cui sono destinati i servizi oggetto di fornitura.

Detto in altri termini, l’offerente - davanti allo scenario e al parco asset da gestire - sarà libero di proporre – senza oneri aggiuntivi per l’Ente - la modifica del parco che ritiene necessaria per gestire al meglio il sistema nell’intero periodo contrattuale almeno secondo i livelli di servizi attesi.

I dettagli della fase di sostituzione sono riportati nel paragrafo “Subentro e gestione del transitorio”.

8. Modello di gestione delle risorse hardware‌

Le Aziende del SSR possiedono le licenze software ad uso perpetuo e le componenti hardware descritte nell’ALLEGATO A: DIMENSIONAMENTO DELL’IMPIANTO PACS FVG, che

costituiscono l’inventario base di quanto sottoposto a contratto di manutenzione full risk, di cui di seguito si riporta l’articolazione dettagliata:

• Modello di gestione degli asset fisici (HW)

Gli asset fisici caratteristici del sistema PACS – esclusa la componentistica di connettività – si dividono in:

o HW standard di elaborazione lato client: il PC/workstation che costituisce le Postazioni di Lavoro (PdL);

o HW specialistico: comprendente, a titolo non esaustivo, i monitor medicali delle PdL, tutto l’hardware necessario alla distribuzione dei CD paziente e le postazioni di visualizzazione custom per ambienti speciali, quali le stazioni di visualizzazione di sala operatoria

o componentistica HW lato server: necessaria all’erogazione del servizio applicativo. Il modello gestionale prevede:

1. l’affidamento all’aggiudicatario, per l’intera durata contrattuale, della gestione della

manutenzione dell'HW specialistico con intervento diretto per tutti i dispositivi;

2. il mantenimento in condizioni di perfetta efficienza del sistema dei server computazionali e di archivio, all’interno dell’architettura infrastrutturale prevista in fornitura.

Ad esclusione delle componenti relative al precedente terzo punto, il rinnovo a fine ciclo di vita dei componenti in manutenzione è a carico delle Aziende del SSR, in genere a seguito di rapporto dettagliato e motivato dal Fornitore, che risulta gestore del parco degli asset per il loro intero ciclo di vita. Per quanto riguarda le componenti al punto 3, l’Aggiudicatario è responsabile del mantenimento e della scalabilità di quanto messo a disposizione, in modo

da mantenere nel tempo i livelli di servizio attesi. Detto in altri termini, l’eventuale messa a disposizione di nuovo hardware lato server per supportare, a titolo non esaustivo, nuove versioni dei software manutenuti o modifiche dello scenario d’attività da gestire nel contratto, sono ritenute dovute e a carico dell’Aggiudicatario senza ulteriori oneri per l’Ente appaltante.

Fanno eccezione i microfoni per la refertazione vocale in radiologia, medicina nucleare. Essendo essi di fatto un accessorio necessario per la fruizione del RIS, essi si intendono forniti, manutenuti ed eventualmente sostituiti o rinnovati a causa – a titolo non esaustivo - di guasto o evoluzione del software a totale ed esclusivo carico dell’aggiudicatario. Essi

dovranno essere forniti nella misura necessaria a permette l’attività di refertazione a tutti i professionisti che ne hanno titolo (numero di radiologi/medici di medicina nucleare) in servizio di refertazione contemporaneo.

Coerentemente con questo scenario, ovvero sistemi dove il carico computazionale è spostato sulla parte server, che riduce il ruolo computazionale delle Postazioni di Lavoro, il fornitore deve accettare le specifiche tecnologiche delle Postazioni di Lavoro che verranno man mano approvvigionate dall’Ente. Evidentemente, esse saranno sempre dimensionalmente adeguate ad ospitare una scheda video discreta per monitor medicali delle varie destinazioni d’uso (ad esempio: disponibilità di slot PCI-E mid o full size e disponibilità di adeguata potenza d’alimentazione per la destinazione d’uso diagnostica) e di performance che l’Ente ritiene adeguata, sempre e comunque nel rispetto dei requisiti minimi previsti per il mantenimento delle prestazioni essenziali della parte DM del PACS.

• Modello di gestione asset software (SW)

Con riferimento all’ALLEGATO A: DIMENSIONAMENTO DELL’IMPIANTO PACS FVG, ogni asset SW è manutenuto – sia in accezione preventiva che correttiva - dall’aggiudicatario per l’intera durata contrattuale a rispetto delle SLA attese.

9. Caratteristiche tecnologiche richieste in ogni componente del sistema ‌

In coerenza con l’approccio richiesto – che prevede un unico interlocutore contrattuale responsabile del servizio di gestione - si richiede che il modello di gestione delle applicazioni sia esclusivamente SaaS (Software as a Service) e tutte le componenti, sia hardware che software (piattaforma e applicazioni) dovranno possedere le caratteristiche tecnologiche indispensabili ad implementare tecnicamente tale paradigma ed essere gestite secondo tale paradigma.

9.1. Architettura dell’infrastruttura a supporto delle applicazioni ‌

Il servizio dovrà avvalersi di strumenti tali da permettere il raggiungimento di un livello di gestione semplice ed efficace delle risorse, tramite l’utilizzo di soluzioni tecnologiche avanzate e robuste. L’infrastruttura su cui dovrà basarsi la soluzione si intende articolata come segue:

1. un livello on premise a massima funzionalità e performance, attivo di default, ma a ridotta

profondità temporale d’archivio;

2. un livello remoto – in housing presso il datacenter di Insiel S.p.A. e connesso con gli utilizzatori finali con l’infrastruttura di rete Insiel – come copia a piena funzionalità e profondità temporale;

Il Fornitore dovrà pertanto mettere a disposizione tutta l’infrastruttura hardware di calcolo e storage necessaria ad erogare i servizi richiesti nelle due aree, facendosi garante del dimensionamento nel tempo per il rispetto delle SLA.

In merito al punto 1, implementando le più basilari regole di sicurezza (anche in riferimento a quanto previsto nell’ambito della norma ISO27000), le apparecchiature e applicazioni del fornitore verranno segregate in VLAN isolata, per e dalla quale saranno consentiti solo i traffici applicativi – e gestionali (es. VPN) - esplicitamente necessari all’attività.

L’accesso alle reti, ad esempio per assistenza da parte del fornitore dall’esterno della RUPAR, sarà concesso solo ad utenti personali le cui credenziali siano richieste, a norma, ai relativi Titolari e da essi erogate e secondo le best practice di sicurezza internazionali. Non sono previsti accessi di tipo Lan to Lan o affini.

Pertanto, i sistemi messi a disposizione NON saranno inseriti all’interno dei domini aziendali di gestione, poiché le regole di gestione sono a carico del fornitore, ma dovranno comunque accedere alle risorse utente in esse contenute attraverso la già citata autenticazione federata.

Le Aziende del SSR metteranno a disposizione, per ogni sito, un apposito spazio rack in locale tecnico di comunicazioni con connettività alla LAN ridondata e doppia linea di alimentazione elettrica. La banda disponibile sarà di almeno 8, solitamente 20 Gbit/s senza single point of failure verso le PdL fruitrici del servizio (al netto del collegamento al desktop).

In merito punto 2, il datacenter INSIEL fornirà spazi, connettività, continuità elettrica e gestione

dell’accesso fisico adeguato alla gestione dei dati critici ospitati nel sistema PACS.

In particolare, tutti gli impianti a servizio del data center sono stati prima disegnati e poi realizzati in configurazione di ridondanza 2N, questo ha anche consentito di ottenere la certificazione ANSI TIA-942B-2017 Rated-3. Oltre a questa certificazione, il data center è anche certificato ISO 50001:2018.

La superficie, pressoché rettangolare, è di circa 600 m2. L’accessibilità è esclusivamente

pedonale ed avviene grazie ad alcune porte di accesso comunicanti con i rimanenti spazi di piano.

L’area dedicata al Data Center è collocata al piano terra nel volume esteso verso il xxxxxxx xxxxxxx xxx xxxxxx 00 xx xxx Xxx Xxxxxxxxx x Xxxxxxx. La sala dedicata all’housing di infrastrutture terze è denominata “OLO room”, in questa sala saranno ospitati gli apparati previsti dalla nuova soluzione PACS. La OLO Room è dedicata ad ospitare utenze esterne, Insiel offre solo l’infrastruttura la connettività di rete e garantisce la continuità elettrica. La sala è composta attualmente da armadi, idonei ad ospitare tutti i dispositivi dei fornitori esterni, due colonne di raffreddamento “In row” ad alta efficienza in ridondanza e due colonne di distribuzione elettrica (RDP) hot swap. La sala è dimensionata per erogare al massimo 35kw di potenza elettrica. Il set point, in base alle indicazioni previste dalle linee guide e best practices ASHRAE TC9.9 è attualmente fissato in 26 gradi.

Gli apparati del progetto PACS avranno a disposizione due armadi da 42 rack unit, con due PDU collegate a due linee di potenza completamente indipendenti. La potenza massima disponibile ad armadio è di 7Kw per linea.

L’accesso alla sala è garantito H24 grazie alla presenza del servizio della control room.

A sorveglianza del datacenter, è presente una control room che è il cuore operativo del Data Center. Personale altamente qualificato si alterna in turni h24 per 365 giorni, al fine di monitorare, controllare e garantire il corretto funzionamento dell’intero Data Center e l’erogazione dei servizi alla Regione FVG. Oltre al personale della Control room, a disposizione per l’eventuale escalation funzionale è disponibile il personale in reperibilità lato impianti e IT specialist per quanto riguardo i sistemi.

Nel limite della necessaria compartimentazione dei dati e del loro trattamento in funzione dei diversi Titolari e dunque nel pieno rispetto della normativa e del GDPR, l’aggiudicatario potrà costituire un'infrastruttura fisica unica per l’intero servizio regionale, adeguatamente ridondata e sufficientemente performante per gestire l’intero carico regionale e gli SLA attesi, anche nel caso in cui gli edge siano non disponibili.

L’architettura logica potrà poi essere usata per implementare la necessaria separazione delle istanze aziendali e l’applicazione delle dovute misure a protezione dei dati e del loro corretto uso. In tal senso dovrà essere prevista la microsegmentazione dei server, anche se virtuali, e la distribuzione dei contesti di distribuzione VRF aziendali ai server di competenza.

Le due zone dell’architettura dovranno lavorare in sinergia per garantire:

- RTO/RPO quasi zero;

- aggiornamenti a caldo delle componenti;

- ampia scalabilità per l’aumento di carico, indipendentemente dal fattore (es. nuove tecnologie o modalità);

- non percepibilità da parte dell’operatore nel passaggio dalla consultazione di immagini e

servizi erogati tra le due zone.

Tutte le componenti hardware s’intendono messe a disposizione come servizio e funzionali all’erogazione del servizio; dunque, nessuna fornitura è prevista in senso patrimoniale. Resta inteso che tutte le componenti sono manutenute in senso full risk dall’aggiudicatario che è responsabile del loro mantenimento allo state dell’arte in particolare per la sicurezza e appropriatezza all’erogazione del servizio.

Nel periodo contrattuale potrà essere attivato il datacenter secondario di INSIEL di Palmanova (UD). Di conseguenza, in funzione della logica e dei meccanismi di business continuity per le applicazioni di housing previsti da Insel, potrà essere richiesta un’eventuale ricollocazione delle componenti d’infrastruttura in housing per aumentare i livelli di continuità attesi.

9.2. Connettività di distribuzione ‌

La connettività fornita dalla RUPAR (Rete Unitaria Pubblica Amministrazione Regionale), gestita dall’in-house della Regione FVG, Insiel S.p.A., è progettata anche per la distribuzione di servizi applicativi sanitari. Essa rende disponibili le seguenti performance:

- per le sedi maggiori viene fornita connettività a 1 Gbps (con ridondanza) ed è in programma l’adeguamento anche nelle sedi minori, ad esempio distrettuali, non raggiunte da tale servizio ed il potenzialmente delle performance delle sedi maggiori (ospedali) a 10Gbit/s;

- la latenza media nella intranet regionale verso il datacenter di Insiel S.p.A. è inferiore ai 5 ms;

- l’uscita verso internet è centralmente fornita in maniera condivisa per tutta la RUPAR.

9.3. Caratteristiche tecnologiche delle applicazioni ‌

Tutte le applicazioni, tecnologicamente, dovranno essere zero footprint e utilizzare i servizi di autenticazione/autorizzazione regionali basati su OAuth2.0/OpenIDCONNECT, sia per l’autenticazione degli utenti che per l’autenticazione/autorizzazione degli stessi ad accedere – con selezione di uno specifico ruolo – ai servizi del sistema informativo sanitario regionale.

In tal modo, gli applicativi forniti potranno essere utilizzati dalle postazioni di lavoro aziendali senza commistione dei perimetri di gestione dei sistemi e senza confusione della responsabilità di applicazione delle regole di sicurezza informatica o, in generale, delle configurazioni.

Qualora il fornitore non possegga componenti zero footprint si potrà avvalere di componenti infrastrutturali di virtualizzazione applicativa che permettano l’accesso alle applicazioni, comunque, via web (solo mediante protocolli sicuri, almeno HTTPS) e utilizzando l’autenticazione federata all’applicativo/sessione virtuale.

Qualora il fornitore non possegga nemmeno questa possibilità, esso verrà penalizzato, qualora risultasse vincitore, nel canone economico aggiudicato fino a correzione della situazione.

Per i nuovi software forniti, che devono essere necessariamente installati sui PC Aziendali e dai reparti IT in maniera autonoma e automatizzata attraverso Microsoft InTune, è richiesto a onere del fornitore la fornitura di un certificato di “software validation” per validare, nello sviluppo del software, il rispetto delle linee guida dello sviluppo sicuro del software. Il fornitore dovrà anche indicare come ritiene dimostrarne il rispetto durante il ciclo di vita del software (ad esempio l’aggiornamento) nel periodo contrattuale.

Per l’uso della distribuzione automatizzata aziendale, da parte del fornitore, è richiesto che l’impacchettamento del software per il distributore sia realizzato come da best practice. È richiesto che tutti i test – ad ogni livello anche sistemistico - siano condotti prima dell’effettiva messa in produzione e che dunque sia minimizzato l’effort richiesto allo staff IT Aziendale.

Qualora tale condizione non venga rispettata dal fornitore, le Aziende possono rifiutare di eseguire la distribuzione senza che questo possa costituire motivo di non rispetto delle SLA attese (ad esempio di aggiornamento del sistema, sia di sicurezza che funzionale).

10. Caratteristiche dei servizi di gestione richiesti in fornitura‌

Il servizio di gestione richiesto si compone di almeno i seguenti servizi operativi:

1. Conduzione tecnica

2. Manutenzione correttiva e adeguativa

3. Manutenzione preventiva

4. Manutenzione evolutiva

5. Formazione e affiancamento

6. Documentazione e reportistica

Per ciascun servizio, di seguito, sono descritte le caratteristiche di dettaglio.

10.1. Conduzione tecnica‌

All’aggiudicatario verranno affidate alcune attività di conduzione tecnica del sistema PACS

secondo le procedure definite dalle Aziende. A titolo non esaustivo:

a. verifica di interfacciamenti standard (per esempio DICOM, HL7) secondo quanto predisposto dalle aziende e funzionale alla redazione di un report sulla funzionalità dello stesso;

b. verifica, assistenza alla configurazione e test di specifici parametri delle modalità di acquisizione (es. Compressione o altre Transfer Syntax);

c. analisi di esigenze degli operatori e dell’uso della strumentazione, redazione di

documentazione analitica quale, ad esempio, casi d’uso;

d. realizzazione di materiale formativo e informativo, o di particolari report di sintesi

sull’impianto;

e. IMAC degli asset in gestione. Nel servizio IMAC sono incluse le attività di nuova installazione e movimentazione, entrambe con trasporto, nonché di aggiornamento e modifica delle componenti hardware e software del sistema PACS con particolare riferimento ai server, alle postazioni di lavoro e workstation e ad altro hardware rilevante (robot cd paziente, pc d’acquisizione).

La quantità di attività affidabile è misurata nel massimo del 20% delle ore uomo disponibili per il tramite del personale on site.

Al personale di presidio potranno essere affidate alcune sotto attività di conduzione

applicativa e tecnica di componenti del sistema non in manutenzione, nell’ambito delle conoscenze specialistiche e dei profili del personale di presidio e secondo procedure definite dall’Azienda. A titolo non esaustivo: spostamento dei dispositivi mobili del sistema, supporto alle attività di gestione delle tecnologie, verifica di interfacciamenti standard, analisi di esigenze degli operatori e dell’uso della strumentazione, realizzazione di materiale formativo e informativo, generazione di report e proposta di soluzioni di ottimizzazione del sistema e del suo uso. Le attività verranno comunicate al responsabile.

Le attività di conduzione tecnica svolte dovranno essere tracciate nei report periodici necessari all’autorizzazione della liquidazione delle fatture.

10.2. Servizi di manutenzione ordinaria preventiva e correttiva: requisiti generali ‌

Vanno intese come incluse nel servizio richiesto le attività di:

• manutenzione ordinaria preventiva: di primo livello, ovvero controlli preventivi, e di secondo livello, ovvero verifiche, prove e misure eseguite da operatori tecnici qualificati;

• manutenzione ordinaria correttiva: di primo e di secondo livello, intese come ordine temporale di intervento e livello di qualifica di chi interviene, così come definite dalle norme UNI/ISO di riferimento;

In ogni caso, tali attività dovranno essere svolte coerentemente con i regolamenti delle

rispettive Aziende e le politiche di sicurezza (intese come “safety”, “security” e sicurezza sul lavoro) e

di privacy, nonché – più in generale – nel rispetto delle norme di buona tecnica, delle “best practice”, dei regolamenti, delle norme tecniche e della legislazione vigente.

In generale, le attività di manutenzione applicativa devono essere eseguite con il minimo dei privilegi amministrativi strettamente necessari. Di conseguenza, in coerenza con il paradigma zero- footprint e zero-trust, l’architettura applicativa non deve richiede privilegi amministrativi sulle workstation o postazioni di lavoro, salvo specifica valutazione e autorizzazione da parte delle singole Aziende.

Inoltre, in ogni caso le suddette attività dovranno comprendere l’espletamento di tutti gli interventi operativi e specialistici necessari a realizzare l’erogazione dei servizi atti a garantire continuità di funzionamento del sistema nel suo complesso e dei singoli elementi che lo costituiscono, nonché tutto quanto necessario per rimuovere o superare qualsiasi impedimento operativo si presenti all’utenza.

Tutte le attività che verranno svolte dovranno essere sempre espletate compatibilmente con

le esigenze dell’attività sanitaria e in accordo con le Aziende.

Tutte le attività di manutenzione ordinaria, preventiva e correttiva, dovranno essere svolte sulla base di un piano di manutenzione, redatto – in accordo con le Aziende - preliminarmente

all’avvio del servizio di manutenzione oggetto del presente contratto in modo da riportare la periodicità e il dettaglio degli interventi preventivi nonché le modalità di risoluzione di guasti tipo.

Fermo restando tutto quanto richiesto nell’ambito del presente contratto in termini di documentazione, dovrà essere prodotto un report relativamente a qualunque attività periodica programmata nonché per ciascun intervento non programmato. Tali report dovranno essere redatti in forma scritta, esplicita e sottoscritta, e dovranno contenere tutte le informazioni relative

all’attività periodica (almeno: nome e cognome tecnico, tipo di intervento, data e ora di esecuzione (inizio e fine), oggetto dell’intervento, descrizione dettagliata delle attività svolte) e all’intervento (almeno: nome e cognome tecnico, tipo di intervento, oggetto dell’intervento, data e ora di apertura della chiamata, data e ora di intervento (inizio e fine), data e ora di chiusura della chiamata, descrizione dettagliata delle attività svolte).

Per tutte le componenti del sistema PACS di proprietà degli Enti del SSR FVG, è necessaria un’attività di manutenzione con contestuale mantenimento delle proprietà di funzionamento e anche del rispetto dei livelli essenziali di sicurezza (marcatura dispositivo medico). Infatti, tutti gli elementi del sistema, così come descritti nell’Allegato A, sono dispositivi medici (eccetto i microfoni per la dettatura) con coerente destinazione d’uso al ruolo rivestito nel sistema PACS. Tali requisiti e performance sono oggetto di ineluttabile mantenimento a carico del Fornitore dei servizi.

Per tutti gli asset del sistema oggetto del servizio di manutenzione, che oggi lo compongono o che lo comporranno nell’intero periodo contrattuale, il Fornitore dovrà essere l’unico interlocutore del servizio di manutenzione del sistema per le Aziende Sanitarie.

Per quanto concerne gli aspetti manutentivi legati ai dispositivi medici (così com’è definito dal

D. Lgs. 37/2010, in recepimento della direttiva comunitaria 2007/47/CE, e dal precedente D.Lgs. 46/97, in recepimento della direttiva 93/42/CEE), ai fini del mantenimento delle caratteristiche che ne hanno consentito la marcatura CE, un dispositivo medico deve essere oggetto di un’adeguata manutenzione per tutto il suo tempo di vita secondo le specifiche del fabbricante. Analogo approccio vale per quanto concerne gli aspetti manutentivi legati agli apparecchi elettromedicali ed ai sistemi elettromedicali (secondo la definizione della norma CEI EN 60601-1). In ogni caso, a valle di ogni attività di manutenzione ordinaria, preventiva (a titolo di esempio non esaustivo, interventi di riparazione o modifica) e correttiva, dovranno essere effettuate tutte le verifiche, prove e misure necessarie ad accertare il ripristino del corretto e sicuro funzionamento di quanto oggetto di attività. Fermo restando le responsabilità per le Aziende “in eligendo” ed “in vigilando”, le stesse delegheranno al Fornitore la responsabilità della manutenzione dei dispositivi medici riconducibili al servizio in oggetto.

Qualora sia necessario effettuare attività di manutenzione che costituiscano impedimento alla normale operatività (sanitaria e non) delle Aziende, tali attività andranno programmate nell’ottica di ridurre al minimo i disservizi. Ove ciò comporti che le stesse debbano essere effettuate in orari e giorni esterni alla fascia oraria del servizio di assistenza indicata nel presente articolo, esse si intendono comunque incluse e quindi non verrà riconosciuto nessun onere aggiuntivo.

In tal senso il Fornitore dovrà redigere un piano di business continuity del servizio PACS offerto al SSR che dettagli con che modalità la funzionalità del sistema è garantita (o meno) anche in caso di manutenzioni correttive, straordinarie o evolutive. Il piano sarà parte del Piano di Manutenzione propedeutico all’avvio del servizio. Come già evidenziato, per aziende, oggi filmless, il sistema è considerato critico e nel piano di business continuity deve essere salvaguardata la refertazione d’emergenza per tutte le relative modalità (CR/DX/CT) in primis e la messa a disposizione delle immagini in sala gessi/sala operatoria e, in ogni caso, non deve avere, per tali funzionalità, alcun single point of failure nell’architettura hardware e software.

10.2.1 Manutenzione ordinaria correttiva ‌

Per quanto concerne la manutenzione ordinaria correttiva (o “a guasto”, ovvero in generale interventi di “revisione”, “sostituzione” o “riparazione”, solo a guasto avvenuto) dovrà essere compreso un numero illimitato di interventi di riparazione su chiamata da effettuarsi sia in teleassistenza che in loco. Tali interventi dovranno garantire la risoluzione del guasto e il completo ripristino della situazione precedente al guasto, riportando al corretto e sicuro funzionamento.

Il servizio deve essere erogato – per guasti bloccanti – 7 giorni su 7 e 24 ore su 24.

I guasti vengono definiti “bloccanti” o “di particolare gravità” quando inficiano il funzionamento dell’intero sistema o di una sua funzionalità, bloccando di fatto la possibilità di usufruire dell’intero sistema o di una sua funzionalità o pregiudicando l’attività di almeno un intero Servizio o Reparto. Gli altri tipi di guasto sono definiti “ordinari” o “non bloccanti”.

Eventualmente, la risoluzione potrà essere anche “provvisoria” (intesa come sostituzione di apparecchiature che permettano comunque identiche funzionalità e prestazioni, anche in termini di correttezza e sicurezza) e in tal caso la situazione originale dovrà essere ripristinata entro quindici giorni lavorativi (risoluzione “definitiva”). A seguito della risoluzione definitiva del guasto dovrà essere effettuata la chiusura della chiamata, che perciò non dovrà mai andare oltre i quindici giorni lavorativi dal momento dell’apertura della stessa.

Il Fornitore dovrà dare evidenza delle avvenute soluzioni provvisorie, tracciando le componenti utilizzate per tutto il tempo d’intervento sino alla soluzione definitiva e segnalando l’avvenuto mediante gli appositi strumenti (report di intervento/report periodico).

Fermo restando quanto suddetto, nel corso di ogni intervento di manutenzione ordinaria correttiva dovranno essere eseguite almeno le seguenti attività:

• eliminazione degli inconvenienti che hanno determinato la richiesta di intervento,

• controllo e ripristino delle normali condizioni di funzionamento,

• fornitura e applicazione – ove necessario – di parti di ricambio nuove di fabbrica adeguate a mantenere inalterate le caratteristiche, comprese le eventuali certificazioni (a titolo di esempio marcature CE),

• ove vi sia sostituzione di componenti con matricola, di proprietà delle Aziende e oggetto di manutenzione full risk, va garantita una comunicazione alle Aziende per l’eventuale aggiornamento della documentazione relativa all’inventario,

• redazione del “verbale di intervento”.

Tutte le parti di ricambio necessarie per le attività di manutenzione ordinaria saranno a carico del Fornitore, senza alcun onere di spesa per le Aziende. Tali parti di ricambio dovranno essere originali o comunque avere caratteristiche confrontabili con quelle sostituite; materiali non propriamente “consumabili” ma cosiddetti “usurabili”, si intendono compresi nel servizio di manutenzione senza alcun onere aggiuntivo per le Aziende.

Non saranno accettate dichiarazioni di non riparabilità, tranne che per documentate compromissione delle performance e dell’efficacia dell’asset su cui è operata la manutenzione o documentata fine del ciclo di vita dell’asset stesso.

La cura dell’efficienza e delle performance delle postazioni di lavoro del sistema PACS Regionale sono a carico del Fornitore, che dovrà garantire la manutenzione delle componenti applicative e delle postazioni di lavoro, di adeguate caratteristiche, fornite dalle Aziende.

Il Fornitore utilizzerà quanto messo a disposizione dalle Aziende Sanitarie per la composizione delle postazioni di lavoro, eseguendo – come parte del servizio oggetto di fornitura - tutte le operazioni di IMAC, di primo intervento e di intervento specialistico interfacciandosi con i referenti Aziendali ed eseguendo l’attività di configurazione e integrazione degli asset specialistici in gestione.

Durante l’intero periodo contrattuale, il Fornitore dovrà predisporre e documentare i piani di rinnovo (a seguito delle attività di manutenzione preventiva, correttiva e controlli funzionali), che verranno validati ed eseguiti dall’Amministrazione/Azienda Sanitaria e prendere in carico la gestione del materiale e degli eventuali contratti di manutenzione.

Le componenti sostituite e/o rese disponibili come nuove dalle Aziende Sanitarie per il servizio, che dovranno essere compatibili con i requisiti di sistema delle applicazioni (di cui all’all.A) ovvero nuovi pc, monitor editoriali, carrelli, e tutto quanto non specialistico, come anche le componenti nuove e sostituite specialistiche, dovranno essere prese in carico dal Fornitore che eseguirà l’installazione (secondo manualistica fornita dall’Azienda), la configurazione finale, la predisposizione delle postazioni utente di pertinenza (workstation di refertazione, postazioni di sala), la gestione delle chiamate di primo intervento (per richieste di manutenzione correttiva), la manutenzione preventiva e controllo funzionale. Il tutto senza comportare oneri aggiuntivi per le Aziende. Tutti questi asset devono comparire nell’inventario del sistema.

Qualora le Aziende acquisissero, per ogni tipologia di componenti, una quota di elementi che incrementi fino al 20% la baseline degli elementi afferenti alla parte in manutenzione full-risk ad inizio contratto, anche questi dovranno essere gestiti all’interno del presente servizio senza oneri aggiuntivi per gli Enti. Tale prescrizione vale per tutti gli elementi anche se al termine del periodo di garanzia e aggiunti alla baseline per tutta la durata del contratto.

Qualora, al termine della garanzia, vengano acquisiti elementi in quantità superiore rispetto alle percentuali sopra esposte, potrà essere affidata al Fornitore – anche a titolo oneroso secondo la

legislazione in essere - anche la manutenzione di tali elementi come parte integrante del servizio, fino al 50% della baseline.

Nel dettaglio, per tutti i componenti del sistema esistenti ed eventuali aggiunte durante il contratto, nel periodo in cui i componenti sono in garanzia, il Fornitore dovrà gestire la chiamata per i guasti e intrattenere i contatti con gli altri fornitori fino alla chiusura della stessa. Allo scadere della garanzia gli elementi entreranno direttamente senza oneri aggiuntivi per le Aziende nell’ambito degli elementi gestiti dal presente contratto.

Le SLA del servizio si applicano sugli elementi sopra descritti, eccedenti la baseline, come

sull’insieme di componenti costituenti la baseline di inizio contratto.

Per ogni Azienda sanitaria e per ogni tipologia di dispositivo specialistico, dovrà essere previsto almeno un muletto di pari prestazioni, in maniera da garantire la sostituzione in modalità hot-swap. Per i monitor medicali dovrà essere salvaguardata la coppia, ovvero per i monitor accoppiati dovrà essere prevista una coppia di monitor per l’eventuale hot-swap. Il muletto dovrà essere reso disponibile entro 2h dall’apertura della chiamata da parte dell’Azienda Sanitaria, per tutte le PdL afferenti, nell’ambito del PACS, ai servizi di pronto soccorso (radiologico e non) o emodinamica – ove si effettuano procedure in urgenza/emergenza.

Tutte le componenti del sistema, e in particolare quelle sopra elencate, sono funzionali e necessarie al corretto funzionamento complessivo del sistema che il Fornitore deve comunque garantire. Infatti, è inteso che la manutenzione deve garantire il corretto e sicuro funzionamento complessivo dei sistemi PACS aziendali – comprese tutte le integrazioni con sistemi di terze parti ove il malfunzionamento non sia imputabile alle stesse – consistente nella disponibilità del sistema 24 ore su 24, nel mantenimento delle funzionalità, della sicurezza del dato e delle performance del sistema nel tempo.

Considerato che il motore software del sistema per la refertazione delle immagini nel suo complesso è un dispositivo medico, e che costituisce parte critica del sistema il cui fermo impatta sensibilmente sull’attività clinica, il Fornitore dovrà mantenere il software, incluse le operazioni inerenti il ciclo di vita dello stesso (patch/risoluzione bachi/evoluzione), nel rispetto dei requisiti essenziali di sicurezza, quindi non inficiando la marcatura CE e l’utilizzo coerente con la destinazione d’uso del dispositivo medico.

Si ricorda che – dal punto di vista applicativo - per ogni componente non gestibile come zero footprint, le componenti software oggetto del perimetro dei servizi dovranno essere o essere rese adeguate all’esecuzione secondo le policy di sicurezza allo stato dell’arte in essere negli Enti del SSR, e, in particolare, modificate in caso di variazioni necessarie per adempimenti normativi o per l’adeguamento a best practice. A titolo esemplificativo devono - come tutte le componenti applicative

- superare i test dei servizi di software validation (che verificano la sicurezza at rest e at work secondo le best practice internazionali) e distribuibili massivamente con gli strumenti di software validation in essere negli Enti.

Solo nel caso in cui il guasto sia causato da eventi dolosi o calamità naturali o a cascata da altri guasti ad altri impianti delle Aziende, l’onere della riparazione sarà a carico delle Aziende stesse, ma sarà cura del Fornitore da un lato provvedere alla riparazione e ripristino delle corrette e sicure funzionalità del sistema con le medesime modalità e tempistiche previste per gli altri guasti, dall’altro provvedere a produrre tutta la documentazione necessaria per il rimborso da parte dell’assicurazione delle Aziende.

Tutti i danni conseguenti allo svolgimento erroneo del servizio di manutenzione, causati direttamente o indirettamente dal Fornitore, dovranno essere riparati tempestivamente a cura e

spese dello stesso. Qualora i danni non possano essere riparati, l’onore del risarcimento sarà del Fornitore. Si sottolinea che per danni si intendono danni materiali ed immateriali quali per esempio danni all’immagine delle aziende o danni causati dalla perdita di dati.

Perimetro delle componenti sulle quali è applicato un servizio del tipo full risk ‌

Il servizio di manutenzione, per le componenti nei seguenti ambiti, è richiesto di tipo full risk.

1. Licenze software

Il parco delle licenze software del sistema, dettagliato nell’ALLEGATO A: DIMENSIONAMENTO DELL’IMPIANTO PACS FVG, funge da inventario tecnico per la manutenzione applicativa full-risk. Nell’ allegato trova posto anche una descrizione funzionale dei moduli esistenti, utile alla valutazione di un’eventuale sostituzione.

2. HW specialistico

a. Postazione di lavoro, di refertazione o visualizzazione

L’affidatario dovrà garantire la manutenzione e l’IMAC di tutte le componenti hardware specialistiche. Per tali componenti, ad esempio i monitor medicali, l’affidatario dovrà prendersi carico della manutenzione full-risk e dell’IMAC degli stessi, inclusa la scheda video dedicata. Nel caso sia necessaria la dismissione del monitor a seguito di valutazione negativa delle performance, oppure accertata irreparabilità, anche per uso improprio o danno accidentale, la sostituzione sarà in carico agli Enti del SSR. Il fornitore dovrà tuttavia provvedere a non interrompere il servizio a cui quell’asset contribuisce fornendo temporaneamente un muletto, o sostituendo – nell’ambito dell’attività di IMAC - con altro materiale ad esso affidato dagli Enti del SSR. Inoltre, il fornitore dovrà provvedere alla gestione dei monitor con il relativo sistema informatizzato (es. QAWEB, RadiCS già attivi in Regione) e alla gestione anche della componentistica nell’ottica di garantire la qualità del servizio (es. sostituzione scheda video se inappropriata all’uso richiesto).

Periodicamente, dovrà fornire un report dello stato di salute di tutti i dispositivi di visualizzazione in manutenzione.

b. Postazioni di visualizzazione di sala operatoria

L’affidatario dovrà garantire la manutenzione e l’IMAC delle postazioni di visualizzazione di sala operatoria. Tutte le loro componenti: PC, accessori quali carrello, mouse e tastiera sanificabili, in quanto parte funzionale alla destinazione d’uso del sistema PACS, ricadono nella manutenzione full risk. Il fornitore dovrà prendersi carico del mantenimento delle performance nel tempo fino a fine ciclo di vita ovvero documentata necessità di rinnovo tecnologico

Qualora per esaurimento delle performance o dichiarazione di irreparabilità delle stazioni, esse debbano essere sostituite, esse verranno prese in carico dalle Aziende Sanitarie per effettuare l’approvvigionamento e renderle nuovamente disponibili all’affidatario per la gestione. Nel frattempo, l'affidatario deve rimpiazzare le stazioni guaste in modo da non interrompere l’operatività – anche utilizzando dei muletti temporanei anche di diversa tipologia (es: mobili) di performance adeguate. Una volta che gli Enti del SSR hanno reso disponibile la stazione o le parti d’evoluzione, sarà cura del Fornitore del servizio rimetterlo in funzione recuperando le proprie soluzioni di workaround. Il Fornitore dovrà provvedere in ogni caso alla gestione dei monitor e alla valutazione del loro stato di salute.

Di seguito la rappresentazione del flusso di gestione manutentivo su richiesta di manutenzione correttiva di asset in quota parte full-risk.

Perimetro delle componenti sulle quali è applicato il servizio del tipo “primo intervento e gestione della chiamata”‌

Per tutti gli ulteriori ambiti connessi all’esercizio del servizio PACS, il servizio gestirà il primo intervento, inclusa la classificazione della chiamata, e poi il ciclo di vita della stessa ingaggiando i secondi livelli messi a disposizione dalle Aziende.

In particolare, l’hardware standard delle postazioni di lavoro è manutenuto dalle Aziende del SSR come quota parte del proprio parco PC o Postazioni di Lavoro. Nel caso sia necessaria la dismissione a seguito di valutazione negativa delle performance oppure di irreparabilità, la sostituzione sarà in carico agli Enti del SSR. Il fornitore dovrà tuttavia provvedere a non interrompere il servizio a cui quell’asset contribuisce nell’ambito dell’attività di IMAC.

Di seguito la rappresentazione grafica del flusso di gestione della chiamata di assistenza sulla postazione refertazione/consultazione - parte normale integrata agli asset in gestione full risk. È richiesta al Fornitore del servizio l’ownership del ciclo della chiamata. Esempio: pc desktop, tastiera, mouse, monitor editoriale, lettore smartcard.

Modalità di ingaggio ‌

Il Fornitore dovrà garantire un servizio di assistenza su chiamata di tipo hot-line, ovvero con un servizio remoto (“teleassistenza”) in grado di intervenire in tempo reale sui sistemi, e un servizio di assistenza on-site, effettuato con personale di presidio. Il primo dovrà essere complementare al secondo, integrandone le prestazioni per competenza ed opportunità.

Il servizio di assistenza dovrà essere garantito in tutti i giorni lavorativi non festivi dal lunedì al venerdì almeno nella fascia oraria continuativa compresa tra le 8:00 e le 17:00.

Nell’ambito del servizio di assistenza su chiamata di tipo hot-line, dovrà essere messo a disposizione un servizio di help desk, in forma di struttura dedicata e specialistica relativamente ai PACS delle singole Aziende, che dovrà funzionare da centro di ricezione e gestione delle chiamate relative alle richieste di informazione e assistenza e da sito tecnico di intervento in teleassistenza, per un numero illimitato di chiamate, e garantire la possibilità di tracciatura del ciclo della chiamata, inclusa l’eventuale escalation a altri specialisti interni al Fornitore.

In particolare, il personale del servizio di help desk dovrà provvedere alla ricezione delle segnalazioni di guasti – perlopiù provenienti dai servizi di help desk già in uso da parte degli enti del SSR (tra cui quello di Insiel S.p.A.) – alla verifica del malfunzionamento e all’apertura dei relativi ticket

– da risolvere in teleassistenza o da indirizzarsi all’assistenza on-site o al livello specialistico remoto opportuno, documentando ogni passaggio e ogni evoluzione delle attività e dello stato della chiamata fino alla risoluzione del guasto.

L’help desk dovrà inoltre essere in grado di ricevere la segnalazione, con la medesima tempestività, anche per mezzo di mail automatica derivante dal sistema di ticketing degli Enti – a formattazione concordata. Il sistema di ticketing del Fornitore dovrà provvedere a adeguato e tempestivo ritorno informativo, automatico o manuale, verso il sistema di ticketing chiamante stesso, garantendo la mappatura dei numeri di chiamata, le note di chiusura e la sincronizzazione dello stato.

In ogni caso è il sistema di ticketing del chiamante che detiene i dati sull’esecuzione del servizio, e ai quali Il Fornitore accetta di far riferimento per la tracciatura/misurazione delle proprie attività e l’eventuale comminazione delle penali, secondo le regole esplicitate nell’apposito paragrafo “PENALI”.

Le Aziende dovranno essere messe in grado, mediante adeguato strumento, di seguire il percorso della chiamata, monitorandone tempi e modi di risoluzione, anche in tempo reale. Il servizio di help desk, per ogni segnalazione ricevuta, dovrà emettere un numero di identificazione univoco per ciascun ticket.

L’help desk o l’assegnatario del ticket dovrà contattare i riferimenti delle Aziende individuati nel ticket per fornire le prime indicazioni circa la natura dei disservizi e le previsioni per il completo ripristino e avrà comunque il compito di aggiornare le Aziende sullo stato del guasto, fino al completo ripristino.

Quando la chiamata passa ai secondi livelli messi a disposizione dal fornitore, esso deve sempre dare evidenza alle Aziende dello stato della segnalazione, di quale servizio ce l’ha in carico, e dell’eventuale previsione della data di messa a disposizione del workaround (soluzione temporanea) o della soluzione definitiva.

Le chiamate potranno venire rifiutate dal servizio di help desk del Fornitore, ove non di propria competenza, ma dovranno essere tracciate nel sistema e girate dall’help desk dell’azienda di riferimento. La tracciatura della chiamata sui sistemi Aziendali sarà funzionale alla misura dell’appropriatezza delle chiamate passate al servizio oggetto del presente capitolato, per un miglioramento continuo della gestione delle chiamate integrata con i due help desk delle Aziende, e alla misura delle SLA del servizio.

10.2.2 Manutenzione ordinaria preventiva ‌

Per quanto concerne la manutenzione ordinaria preventiva (o “periodica”; ovvero in generale interventi manutentivi di “revisione”, “sostituzione” o “riparazione”, prima che si manifesti il guasto) il contratto proposto dovrà comprendere almeno DUE interventi annui di manutenzione ordinaria preventiva di secondo livello, fermo restando tutte le attività peculiari richieste nel presente contratto (anche con cadenza differente). Tali interventi dovranno prevedere l’esecuzione di tutte le operazioni necessarie a prevenire eventuali anomalie sull’hardware e sul software, le verifiche e misure necessarie a garantire nel tempo un livello costante di qualità del sistema, nonché tutto il necessario per conseguire il corretto e sicuro funzionamento del sistema nel suo complesso.

Sono inclusi nelle attività di manutenzione ordinaria preventiva di secondo livello, tutti gli interventi necessari a garantire il funzionamento del sistema su nuove versioni dei browser o del sistema operativo e su ogni variazione sull’infrastruttura aziendale o delle policy di gestione dei sistemi che non comportino sviluppi dedicati del singolo prodotto. Le aziende comunicheranno tali cambiamenti al Fornitore, il quale stimerà l’impatto delle attività entro cinque giorni lavorativi, in maniera da poter concordare le azioni necessarie con le Aziende o evidenziare le necessità di sviluppo. Il Fornitore dovrà installare prontamente ogni potenziamento apportato alla versione del software al fine di migliorare le funzionalità esistenti in termini di prestazioni, semplicità di utilizzo,

ottimizzazione delle performance e delle modalità gestionali.

Il Fornitore dovrà mantenere aggiornati alle ultime major e minor release di ciascun software mantenuto nell’ambito full-risk, di terze parti e non. Entro due settimane dal rilascio di ogni release, il Fornitore dovrà rilasciare le release notes ad ARCS, che conseguentemente valuterà l’opportunità o meno di far eseguire gli aggiornamenti, ed in caso affermativo il Fornitore dovrà provvedere ad iniziare l’aggiornamento del parco macchine entro due settimane. Il servizio dovrà inoltre includere la messa in uso di ogni modifica che si rendesse necessaria a seguito della sopravvenienza di eventuali norme obbligatorie, incluse quelle inerenti alla sicurezza informatica.

Sono da intendersi incluse nelle attività di manutenzione ordinaria preventiva di secondo livello anche tutte le verifiche e prove periodiche previste dalla normativa vigente e comunque necessarie alla verifica del mantenimento nel tempo delle caratteristiche degli apparecchi

elettromedicali e sistemi elettromedicali con cadenza almeno annuale. A titolo non esaustivo: le verifiche di sicurezza elettrica sui sistemi in manutenzione full risk. Per i sistemi elettromedicali (a titolo di esempio non esaustivo, le postazioni di visualizzazione di sala operatoria), per i quali le verifiche coinvolgono apparecchi riconducibili al servizio in oggetto e non, l’esecuzione delle stesse potrà essere concordata nei modi e nei tempi con le strutture aziendali di riferimento.

10.2.3 Organizzazione operativa dei servizi e del personale ‌

Dal punto di vista organizzativo, il servizio dovrà essere composto da NOVE risorse on site di presidio di cui una con funzione di coordinamento tecnico a livello regionale, come di seguito dettagliato, ovvero di una figura (di seguito “Responsabile”) unica responsabile dell’esecuzione locale del contratto, e coordinatrice dei rapporti tra la squadra messa a disposizione dal Fornitore e le figure operative on site.

Questa figura dovrà essere una persona indicata nominativamente nel progetto, con allegato CV e indicazione delle relative competenze.

Sarà responsabilità di tale figura garantire il corretto andamento della fornitura nel suo complesso relativamente a tutte le attività previste nel presente capitolato, nonché alle esigenze specifiche e peculiari delle Aziende, anche con riferimento alla necessità di continuo miglioramento.

Dovrà garantire specificatamente la qualità del servizio e della sua organizzazione, le tempistiche e le modalità di attuazione in relazione alle fasi realizzative descritte nel presente capitolato e il ritorno informativo; il tutto in stretta collaborazione con il personale delle Aziende Sanitarie, cui compete la sorveglianza e la verifica di tutti gli adempimenti oggetto del presente capitolato.

Il Responsabile è comunque una persona con alta esperienza del sistema, in grado di eseguire analisi sullo stato del sistema, sulle opportunità di espansione/evoluzione e con

l’autorevolezza per interfacciarsi con gli stakeholder aziendali.

Le figure on-site operative compongono il servizio di presidio e conduzione operativa, continuativo e dedicato, che è dimensionato per NOVE unità FTE.

Il servizio deve essere erogato da personale opportunamente formato ed in grado di gestire il sistema e affiancare gli utilizzatori in completa autonomia. Il personale del servizio di presidio deve garantire un alto livello di efficacia nel supporto all’utenza, in linea con la criticità dell’applicativo. Le figure onsite devono pertanto avere competenze adeguate: ogni risorsa deve essere in possesso di un titolo di laurea a tema, e dunque con curriculum di studi inerente alle materie del contratto, o comprovata esperienza di almeno 5 anni di attività specifica comparabile con quella del contratto nel settore healthcare. In ogni caso, deve avere documentata esperienza sui prodotti oggetto di manutenzione.

Tutti gli on site dovranno conseguire almeno una certificazione, o frequentare con successo un corso di formazione specifico sui temi inerenti al contratto ogni anno, fornendo

all’Amministrazione documentazione a prova della frequentazione. Almeno una volta all’anno, nei

report trimestrali, dovrà esser pertanto riportata evidenza delle attività di formazione o

affiancamento condotte dai tecnici per il mantenimento e l’aggiornamento dei propri skill.

Il presidio effettuerà attività di manutenzione, conduzione operativa e affiancamento agli operatori. In tal senso, sarà inoltre promotore della formazione continua degli operatori.

Si intende inclusa nel servizio l’assistenza, anche con eventuale intervento on site se necessario, nel caso di eventi fuori orario di servizio on site. Tali eventi saranno organizzati e richiesti con congruo anticipo dalle Aziende.

Il presidio dovrà essere garantito presso i locali di ogni Azienda Sanitaria, in particolare nei locali messi a disposizione dalle aziende. Il servizio di presidio consiste nella presenza continuativa, durante l’orario di assistenza (8:00-17:00) per tutti i giorni lavorativi dell’anno, delle risorse full-time previste, in controllo del Fornitore, che dovranno svolgere completamente, rispettando tutti i requisiti previsti, i compiti descritti nel presente documento.

Ogni variazione del personale di presidio va tempestivamente comunicata alle Aziende.

Eventuali mancanze non comunicate saranno considerate non conformità.

La sostituzione del personale per cause improvvise, malattia o impegni personali improvvisi, deve essere effettuata a partire dal second business day a partire dall’evento, con comunicazione alle aziende dell’evento di assenza in giornata e della relativa eventuale sostituzione next business

day. In ogni caso, non potrà mai rimanere senza servizio on site alcuna sede ospedaliera hub, ovvero

quest’ultime dovranno essere sempre presidiate.

Il Fornitore dovrà documentare giornalmente la presenza delle risorse. Queste informazioni sono parte integrante dei report richiesti dal contratto e propedeutici al pagamento delle fatture, come anche l’indicazione almeno per macro attività, dell’attività specifica effettuata nel periodo di riferimento.

L’assenza nei report di attività specifica costituisce evidenza di mancanza di personale con le qualifiche richieste. Il registro delle presenze giornaliere comprenderà anche la registrazione di ogni intervento di eventuale altro personale.

Nella loro attività on site, i tecnici lavoreranno a stretto contatto con il personale delle Aziende Sanitarie e dovranno osservare i regolamenti aziendali e utilizzare strumenti e procedure in linea con tali regolamenti.

Nella fattispecie questi dovranno almeno:

• relazionarsi ed interfacciarsi in modo diretto con le Aziende, in particolare con i referenti Aziendali del sistema PACS;

• svolgere attività di produzione e tenuta di tutta la documentazione e reportistica;

• svolgere attività di manutenzione ordinaria preventiva di secondo livello e correttiva;

• svolgere attività di installazione, messa in servizio e predisposizione al collaudo delle nuove forniture e di IMAC come specificato;

• svolgere attività di formazione e affiancamento, anche quotidiano, degli utenti al fine di formare gli stessi all’uso sicuro, appropriato ed economico degli applicativi e del sistema, secondo le peculiari esigenze degli stessi;

• svolgere tutte le attività inerenti all’alimentazione del flusso verso la conservazione legale,

così come richieste nel presente documento;

• eseguire le attività di conduzione e di gestione delle problematiche inerenti al sistema PACS extra parco macchine full risk affidate.

Anche l’attività di assistenza da remoto dovrà essere svolta da personale adeguatamente

qualificato e identificato secondo le norme.

Le Aziende si riservano di verificare a campione le competenze del personale utilizzato. Il Fornitore dovrà garantire comunque quante risorse risultino necessarie per l’esecuzione di attività di manutenzione ordinaria e conduzione, anche nel caso in cui picchi di richieste richiedano un

impegno maggiore dell’ordinario per il mantenimento dei livelli di servizio previsti.

Si intende inclusa l’eventuale esecuzione di interventi straordinari in orario notturno o festivo, per la necessaria salvaguardia della continuità dell’attività clinica, per, al massimo, 2

interventi all’anno per Azienda coinvolgendo, per quanto necessario, anche del personale tecnico di alto profilo specialistico del fornitore, in aggiunta alle risorse del servizio di assistenza tecnica disponibili on site.

Vista la peculiarità del contesto e la complessità dell’intero sistema, è auspicabile che anche la teleassistenza, oltre all’assistenza on site vengano svolte il più possibile dallo stesso gruppo di tecnici competenti e con basso turn over.

La variazione dei tecnici non dovrà impattare in alcun modo sull’operatività delle Aziende e non dovrà causare ugualmente alcun onere di transizione né in termini di costi che di risorse per le Aziende. Ogni presenza diversa dai tecnici dichiarati “di presidio” nelle aziende dovrà essere comunicata con preavviso alle aziende.

Gli enti del SSR si riservano comunque la facoltà di esprimere il proprio gradimento per ogni singola risorsa assegnata a tempo pieno o parziale al servizio oggetto del presente affidamento, anche preventivamente, anche sulla base delle verifiche sulle competenze e sul comportamento, e di richiedere la sostituzione delle risorse non gradite.

Tutto il personale dovrà essere dotato di telefono cellulare aziendale fornito dal Fornitore ed i numeri comunicati ed aggiornati alle Aziende in caso di variazione. In particolare, almeno una risorsa dovrà essere sempre raggiungibile al telefono cellulare ai riferimenti comunicati (o

eventualmente con l’ausilio di apparecchi cercapersone forniti dalle Aziende) negli orari descritti

precedentemente.

Il personale, incluso quello di presidio, dovrà inoltre essere dotato dal Fornitore di adeguati mezzi di trasporto, ovvero almeno un’auto/furgone per ogni presidio e attrezzi quali, ad esempio, almeno un carrello, per essere messo in grado di movimentare materiale (in primis PC, Monitor) ed eseguire interventi in tutte le sedi delle Aziende. Inoltre, per quanto riguarda le sedi più coinvolte dal presente servizio, si ritengono inclusi nel servizio anche l’abbonamento per la sosta, almeno per i mezzi privati/aziendali del personale di presidio.

Tutti gli operatori dovranno rispettare le norme di educazione che definiscono i criteri di un comportamento civile e di correttezza del lavoro nell’ambito ospedaliero riassunte di seguito. In particolare, dovranno:

• essere muniti di cartellino identificativo a norma di legge;

• rispettare il divieto di fumo in tutta l’area delle Aziende;

• lasciare immediatamente i locali delle Aziende al termine delle attività contrattualmente previste;

• rispettare l’assoluto divieto di fornire a chicchessia notizie di cui sia venuto a conoscenza durante l’espletamento delle attività contrattualmente previste, al di fuori di quelle

strettamente necessarie all’esecuzione delle stesse;

• non chiedere o accettare da chicchessia compensi o regalie di alcun tipo;

• evitare qualsiasi intralcio o disturbo al normale andamento dell’attività;

• uniformarsi a tutte le norme di carattere generale emanate dalle Aziende per il proprio personale ed attenersi a tutte le norme inerenti all’igiene e la sicurezza del lavoro anche specifiche.

Di fatto, il compito della squadra on-site non è il solo garantire il corretto funzionamento del sistema, ma il mantenimento dello stesso allo stato dell’arte, nel tempo, e di garantire che vengano conosciute ed eventualmente apprezzate ed utilizzate tutte le funzionalità.

• ASUFC QUATTRO RISORSE:

o almeno due risorse devono essere di presidio della sede di Udine e in particolare

della Radiologia e altre attività con carattere d’urgenza

o due risorse presidiano i presidi ospedalieri spoke di XXXXX

• XXXX e CRO DUE RISORSE:

o una risorsa presidia le sedi dell’Ospedale di Pordenone e una presidia le sedi ospedaliere spoke e il CRO

• ASUGI, Area Isontina e Burlo TRE RISORSE:

o una risorsa presidia gli Ospedali di Gorizia, Monfalcone e dell’IRCSS Burlo

o due risorse presidiano il presidio di Cattinara e Maggiore

10.2.4 Luogo di esecuzione dei servizi ‌

I servizi richiesti dovranno essere svolti da remoto e presso le sedi delle Aziende del SSR. Quest’ultime renderanno disponibili al Fornitore adeguati spazi per l’esecuzione delle attività previste nel presente contratto.

In merito ai locali messi a disposizione dalle Aziende, queste ultime dovranno mettere a disposizione delle postazioni di lavoro per gli onsite previsti per ogni sede prevista.

In merito a tali postazioni, dovranno essere adeguate all’uso previsto di lavoro d’ufficio, a tiolo non esaustivo, dovranno essere adeguati – anche ai sensi della legge 81/2008 per altezza, aerazione, condizionamento, pulizia, illuminazione etc.

I locali saranno locati il più possibile vicino alle sedi di erogazione dei servizi sanitari che utilizzano i sistemi gestiti dal fornitore, in prima approssimazione le Radiologie delle sedi oggetto del presidio o, in alternativa, i locali della struttura aziendale che gestisce i rapporti e gli asset. Tutto ciò al fine di ottimizzare e promuovere l’efficace collaborazione con committente e utilizzatore finali.

Per ogni sede, le Aziende individueranno delle soluzioni per mettere a disposizione del fornitore del servizio un laboratorio e un magazzino, al fine di permettere le attività di IMAC e di conduzione, da sviluppare in sinergia con il l’organizzazione della gestione degli asset della singola Azienda.

Inoltre, ogni Azienda, si impegna, nei confronti dell’Appaltatore, durante tutta la durata dell’appalto a:

1. fornire ogni informazione e supporto istituzionale, necessari o utili all’espletamento delle

attività appaltate;

2. fornire la documentazione tecnica relativa alle apparecchiature oggetto del servizio, per quanto a sua disposizione;

3. comunicare i rischi presunti nei locali oggetto dell’appalto;

4. concordare in sede di avvio del servizio tutti gli aspetti operativi necessari;

5. effettuare tutte le operazioni amministrative e operative per la dismissione e lo smaltimento delle apparecchiature dismesse e lo smaltimento dei rifiuti speciali salvo quanto assunto a proprio carico dall’Appaltatore in sede di offerte tecnica;

6. coprire i costi di energia, acqua, riscaldamento, ecc., necessari al funzionamento degli spazi messi a disposizione:

7. garantire la preventiva pulizia e disinfezione delle apparecchiature o aree dove possano sussistere pericoli di contaminazione di qualsiasi natura.

10.3 Manutenzione evolutiva e caratteristiche funzionali del sistema PACS ‌

Il servizio di manutenzione evolutiva del sistema intende perseguire l’evoluzione funzionale del sistema. Di fatto, per sostituzione o manutenzione, tutte le funzionalità in essere del sistema deve essere costantemente aggiornato allo stato dell’arte.

Di seguito, in aggiunta, vengono descritte le funzionalità che si intendono messe a

disposizione dall’aggiudicatario per la durata contrattuale.

10.3.1 Sistema verticale di radiologia e medicina nucleare (RIS)‌

Si intende attivare un sistema RIS omogeneo per tutte le Radiologie e Medicine Nucleari della Regione (vedi ALLEGATO A: DIMENSIONAMENTO DELL’IMPIANTO PACS FVG)

Tale RIS deve permette la gestione digitale dell’intero workflow dei due reparti, pienamente integrato con il sistema informativo Regionale nell’ottica di adesione ai profili IHE più adatti e di adempimento a tutti i flussi informativi e di reportistica necessari, incluso l’aderenza alle indicazioni di HL7 Italia per il progetto FSE 2.0.

A titolo non esaustivo, andando a selezionare alcuni particolari del workflow e delle funzionalità attese, il RIS deve:

Funzionalità tipiche della fase di prenotazione/accettazione ‌

- in caso di blocco dei sistemi, per gestire le urgenze, deve essere garantita la piena operatività nella presa in carico dell’assistito inclusa la possibilità di effettuare inserimenti diretti (Accettazione diretta); una volta risolte le problematiche, il sistema deve garantire l’allineamento e la ricongiunzione sia dei dati anagrafici dell’assistito e riportare in linea il caso con gli altri sistemi del SIO

- consentire all’operatore la stampa di documenti utili (ad es. una scheda di prenotazione con

l'indicazione della preparazione necessaria per effettuare gli esami, etc.)

- possibilità di invocare la stampa del CD Paziente – inclusivo di referto e immagini;

- produrre modulistica specifica per l’informativa e i moduli per il consenso informato, per il trattamento dei dati e il trattamento sanitario da far firmare all’assistito e al medico, con firma grafometrica, come descritto nella sezione Firma digitale;

- stampare etichette con dimensione e layout definibile e personalizzabile su richiesta;

Funzionalità tipiche della fase di esecuzione dell’esame ‌

- assegnare a ciascun esame, automaticamente (in presenza del servizio DICOM MPPS) o manualmente (in assenza del servizio DICOM MPPS), le informazioni relative a:

o tecnico esecutore e, se presenti, infermieri, anestesisti o altri operatori;

o data/ora inizio dell’esame;

o data/ora di fine dell’esame e relativa eventuale gestione delle informazioni, qualora non sia possibile concludere l’esame (per es. motivazione o riprogrammazione esame);

o inserimento e archiviazione di informazioni anamnestiche e cliniche (visualizzabili anche successivamente);

o annotazioni riguardanti l’esecuzione dell’esame;

o tipo mezzo di contrasto utilizzato e relativo dosaggio;

o visualizzazione e gestione del cambio di stato dell’esame (ad es. xxxxxxxxx, accettato,

eseguito, refertato, annullato, etc.).

- dare evidenza agli operatori che l’archiviazione degli oggetti multimediali sia avvenuta con

successo;

- poter gestire la storia radiologica dell’assistito, comprese le indicazioni relative all’informazione dosimetrica connessa all’esposizione (D.Lgs 101/20 e s.m.i.), con possibilità di facile consultazione degli esami pregressi e delle richieste pendenti, con relativo stato di evasione;

- assegnare la refertazione di uno specifico esame a un determinato medico o team refertante;

- gestire la richiesta di un approfondimento, di un richiamo tecnico o altre eventualità (distinguendole e tracciandole);

- garantire il recupero delle informazioni clinico/amministrative tramite FSE/Cartella clinica regionale (ad es. allergie, anamnesi, terapia in corso, etc.) e permetterne la modifica/integrazione nei relativi “contenitori” di informazioni;

- la maschera informazioni del tecnico dev'essere configurabile secondo necessità (esempio: screening mammografico di secondo livello);

Funzionalità tipiche della fase di refertazione ‌

- prevedere un referto strutturato configurabile (dosimetria, quesito clinico, valori ematochimici, immagini chiave come link, inserimento di grafiche rappresentanti tratti anatomici e simili);

- prevedere la possibilità di firma di un referto iniziato da un medico e concluso da un altro;

- prevedere la compilazione del referto con campo dello specializzando (indicizzabile e ricercabile per statistiche);

- avere la possibilità di sviluppare percorsi di refertazione multimodale (radiologica e medico nucleare) con documenti a doppia firma;

- possibilità di aprire esami di più pazienti e/o di salvare lo stato di elaborazione di uno studio per poterlo riprendere dallo stesso punto di lavorazione (caso d'uso: durante una refertazione complessa viene chiesto di valutare un caso urgente)

- evidenza dello stato di avanzamento in tempo reale (granulare. Es: bozza) del flusso a tutti gli attori interessati al flusso di lavoro;

- creare la lista di lavoro in modo differenziato in base a specifiche regole definibili a sistema. A titolo esemplificativo e non esaustivo: tempi massimi di refertazione dell’esame, medico refertante, metodica, modalità, sala o provenienza, associazione del medico refertante a una diagnostica, priorità, intervallo temporale, stato dell’esame (ad es. esame da refertare, in sospeso, in attesa di firma, referto provvisorio, da confermare, etc.);

- permettere una semplice riconfigurazione, per utenti autorizzati, delle liste di lavoro alle varie modalità, molto utile nel caso di guasti improvvisi;

- prevedere aggiornamento automatico della lista e allarmi impostabili sull’arrivo di un caso

emergente

- effettuare la refertazione sia per mezzo di riconoscimento vocale automatico del dettato a voce, con produzione diretta del testo scritto, sia con scrittura del referto direttamente da parte del medico. In ogni caso con evidenze cromatiche della lateralità e parole significative;

- copiare il testo di un referto precedente al fine di trasferirlo sul referto in via di redazione;

- integrare automaticamente nel testo del referto strutturato informazioni quali-quantitative derivanti dall’analisi delle immagini;

- invocare e inserire testi di referti preimpostati, configurabili per singolo operatore, unità operativa, o generici, richiamabili sia con comando vocale sia con richiamo da tastiera/mouse;

- utilizzare il referto strutturato nel formato CDA2 previsto da HL7 Italia (parte integrante dello standard DICOM – servizio SR) con pieno supporto della refertazione garantendo la creazione di una reportistica completa e aderente alle linee guida introdotte dalla SIRM e utilizzando la codifica ICD-9-CM (deve essere possibile associare al referto immagini chiave, misure, ricostruzioni ed elaborazioni effettuate sull’immagine dal medico, etc.);

- produrre referti compatibili con l’FSE 2.0 da produttore accreditato

- garantire il recupero delle indicazioni relative all’informazione dosimetrica connessa all’esposizione (D. Lgs.vo 101/20 e ss. mm. ii.);

- gestire i processi di prescrizione e somministrazione dei farmaci, di prescrizione di prestazioni, di certificati di malattia e di ogni altra funzionalità messa a disposizione dal SIO, tramite chiamata di contesto almeno per paziente, episodio, studio, etc;

- per gli assistiti ricoverati o in emergenza/urgenza, possibilità di effettuare prescrizioni tramite chiamata di contesto alla funzionalità Gestione richieste presente sul sistema SIO;

- effettuare la chiusura del referto con firma digitale, come descritto nella sezione Firma digitale;

- permettere la gestione delle modifiche (ad es. addendum, sostituzione, etc.) di un referto firmato, con gestione complessiva del referto sostitutivo, secondo normativa vigente;

- permettere la produzione, tramite opportune configurazioni in base alla tipologia di accesso o di prestazione, dei supporti informatici (ad es. CD, DVD) da consegnare agli assistiti, tramite integrazione con il sistema di produzione degli stessi, in conformità con la normativa vigente.

Funzionalità relative allo screening di II livello ‌

Il sistema dovrà garantire, nella gestione delle prestazioni di screening mammografico di secondo livello, le funzionalità di seguito riportate.

Funzionalità ad uso del personale tecnico:

- accesso alle informazioni derivanti al primo livello necessarie per l’esecuzione degli esami di

approfondimento (anamnesi, indicazioni fornite dai lettori, ecc);

- possibilità di aggiornare i dati anamnestici raccolti al primo livello;

- registrazione degli operatori.

Funzionalità ad uso del personale medico:

- accesso ai dati di anamnesi e agli esiti di primo livello;

- possibilità di raccogliere all’interno di una cartella digitale dedicata tutte le informazioni relative all’intero percorso diagnostico di secondo livello della paziente, con caratterizzazione delle eventuali lesioni presenti. I dati relativi alle indagini eseguite, ai risultati ad esse associati, alla diagnosi e alle indicazioni suggerite devono essere raccolti in forma strutturata, suddivisi per lesione, mettendo in atto meccanismi volti a garantire la completezza e la coerenza delle informazioni inserite;

- possibilità di definire e caratterizzare più lesioni per ciascun lato;

- possibilità di aggiungere esami in corso di indagine, anche associandoli, se necessario, alle singole lesioni.

- disponibilità di schede di raccolta dati strutturata dedicate agli esami di laboratorio (citologie, microbiopsie) per la registrazione di informazioni relative alle modalità di esecuzione dell’esame e all’esito;

- possibilità di redazione di un referto conclusivo testuale;

- strumenti di refertazione assistita (frasi predefinite, refertazione vocale, ecc.);

- possibilità di registrare tutti gli operatori (medici e non) coinvolti nei diversi esami di approfondimento;

- la soluzione deve garantire la possibilità di eventuali estensioni future per altre tipologie di Screening di diagnostica per immagini.

Funzionalità relative al teleconsulto e second opinion ‌

La soluzione deve permettere la gestione delle richieste di teleconsulto o second opinion tra Strutture o Aziende diverse, con possibilità di redigere un consulto derivante dalla valutazione dei dati clinici, anamnestici e di imaging. Nella fattispecie di un servizio erogato per Aziende diverse da quella di appartenenza, il sistema deve prevedere la differenziazione tra prestazioni fornite in urgenza o in regime ordinario/programmazione, sia per quanto riguarda la refertazione sia la “second opinion”.

È preferibile la presenza di un sistema di “alert” di segnalazione di arrivo di prestazione urgente. Queste prestazioni devono essere codificate in modo differente da quelle eseguite per il proprio Servizio/Ente e quindi facilmente estratte per rendicontazione e analisi. Il referto di un teleconsulto in urgenza o di una “second opinion”, deve riportare il motivo clinico per cui è stato richiesto il parere terzo e deve prevedere criteri di tracciabilità, come a titolo esemplificativo, l’orario di esecuzione della prestazione e quello della presa in carico da parte della terza parte, in calce il nome del medico e TSRM esecutore e del medico refertante in caso differente.

Nella gestione multidisciplinare di pazienti inseriti all’interno di PDTA regionali (es. rete ictus), è necessaria la possibilità di valutare immagini e visionare esami eseguiti in altra sede e correlati alla specifica patologia, anche nel corso del follow-up.

Deve essere inoltre possibile la collaborazione live tra professionisti ognuno dalla propria postazione (su verticale di reparto o su PACS o modulo di Web-call integrato) il tutto contestualizzato al caso o ai casi oggetto di consulenza in modo da configurare il percorso nel rispetto dei principi e obblighi del GDPR.

Funzionalità relative al sistema di refertazione vocale ‌

- riconoscimento vocale, in grado di gestire il parlato continuo su vocabolario specializzato per il settore radiologico;

- disponibilità di altri vocabolari o vocabolario aggiornabile per estensione ad altre discipline/specialità;

- riconoscimento vocale immediato dal primo utilizzo, ovvero non deve essere prevista

un’attività di addestramento vocale iniziale da parte dell’utilizzatore;

- compilazione di referti strutturati e gestione di comandi vocali.

Funzionalità relative alla firma digitale ‌

Il sistema deve interfacciarsi con i sistemi di firma remota messi a disposizione dal SIO. Inoltre, in particolare deve consentire:

- la gestione di firme multiple dello stesso documento da parte di operatori differenti per la gestione delle seguenti casistiche:

o firma dello stesso documento da parte di operatori diversi;

o firma di parti diverse del documento da parte di differenti operatori;

- la gestione di addenda, ovvero l’aggiunta di postille (dotate anch’esse di firma) a

integrazione/modifica di un documento;

- il versioning, ovvero la gestione di versioni multiple del medesimo documento, da utilizzarsi nel caso sia necessario modificare un documento già firmato (gestione addendum);

- la produzione e firma del referto annullativo, relativo o meno a determinati studi d’imaging;

Funzionalità relative alla somministrazione del mezzo di contrasto ‌

La soluzione offerta deve prevedere la fornitura di uno strumento necessario per recepire le informazioni da parte di una componente annessa, relativa all'iniettore. In questo modo è garantita la possibilità di registrare la gestione dell’infusione (quantità, velocità, istanza, etc.).

Ad esempio non esaustivo si riportano alcune tipologie di iniettori utilizzate negli enti del SSR: MedRad MRXPERION, Bayer Stellant, Ulrich Medical Motion Xxxxxx...

Funzionalità relative alla gestione della somministrazione del radiofarmaco ‌

Nel contesto delle funzionalità previste per la Medicina Nucleare, la soluzione offerta deve prevedere la gestione della prescrizione e della somministrazione del/i radiofarmaco/i associato/i alla prestazione richiesta.

In particolare, si chiede di prevedere:

- l’integrazione bidirezionale con i sistemi di preparazione e somministrazione della dose in uso

presso le Aziende Sanitarie, siano essi applicativi o dispositivi;

- l’integrazione bidirezionale con i sistemi di gestione dello stoccaggio e dello smaltimento dei

radiofarmaci e delle sorgenti di calibrazione radioattive in uso presso le Aziende Sanitarie;

- la gestione tramite RIS della registrazione del radiofarmaco prescritto e/o della relativa

- somministrazione, attività e/o altro dato dosimetrico inclusi;

- il ritorno dell’attività e/o di altro dato dosimetrico al sistema di archiviazione e monitoraggio del dato dosimetrico.

10.3.2 PACS (Componenti di viewer universale, viewer specialistico per radiologia e medicina nucleare, archivio trasversale)‌

Il PACS deve garantire le seguenti funzioni, tutte disponibili senza limitazioni di volume, né di utenza concorrente, né di postazione. È onere dell’aggiudicatario - gestore del sistema – fare in modo che l’offerta di funzionalità sia sempre uguale alla quantità di domanda, indipendentemente dalla variazione di quest’ultima.

Funzionalità generali ‌

- Ove necessario, ad esempio per recuperare casi specifici dall’archivio storico, il PACS – eventualmente di concerto RIS – deve poter attivare il prefetching degli oggetti multimediali di ambito radiologico (incluso lo screening mammografico) e di medicina nucleare, in un tempo definito a sistema, comunque configurabile. Il prefetching deve poter essere effettuato anche sulla base di selezione di diversi parametri (ad es. distretto anatomico, protocollo clinico, etc.), dando comunque evidenza (ad es. tramite un elenco) di quanto è possibile recuperare tramite prefetching. Si intende una funzione attivabile ad hoc per talune tipologie di procedure che richiedono disponibilità di dati a profondità temporale superiore a quanto recuperabile in realtime;

- implementare tutte le misure fondamentali (ad es. linee, angoli, distanze, etc.);

- implementare tutte le funzionalità di elaborazione base quali 3D, MPR anche curved, MIP,

volume rendering immediato all’apertura dello studio e analoghi;

- prevedere la rimozione automatica delle ossa e funzionalità di ritaglio volumetrico (sculpting);

- implementare la riproduzione cine di acquisizioni multifasiche, sia 2D che 3D;

- implementare le key image con commento (IHE KIN con opzioni);

- gestire le volumetrie TC e RM;

- Possibilità di confronti facilitati tra esame attuale e precedente e/o tra diverse fasi (es. centramento sincronizzato, comparazione pre-post di valori quantitativi o semi-quantitativi di ROI/VOI)

- Possibilità di avere evidenza nella GUI, a disposizione dell’utente, della data e ora di arrivo (archiviazione iniziale sul sistema) dell’immagine;

- Effettuare una gestione multi monitor senza agenti tra le funzionalità del viewer

- possibilità di richiamare funzionalità terze specifiche per l’elaborazione di particolari tipologie di studi (ad es. CAD, moduli di rielaborazione per studi funzionali encefalici, cardiaci, etc.) in maniera contestualizzata per utente, paziente, episodio, studio in SSO con autenticazione/autorizzazione federata;

- studio delle formazioni espansive solide ai fini di valutarne l’accrescimento con metodologia

almeno RECIST;

- implementare funzionalità di CAD per l’identificazione dei noduli alla CT del torace;

- possibilità di esportare gli oggetti multimediali, sia con i dati DICOM sia in forma anonimizzata.

- gestire la disposizione automatica delle immagini sui vari monitor a seconda della tipologia dell’esame (hanging protocols), personalizzabile per utente, con possibilità di creazione e modifica direttamente effettuabile dall’operatore tramite interfaccia grafica.

- durante la compilazione di un referto, legato a una o più prestazioni associate a uno o più studi, deve essere sempre possibile interrompere la refertazione, anche per i tool integrati, e riprenderla dallo stesso punto di avanzamento sia a livello di compilazione del referto che di presentazione ed elaborazione. La funzionalità è critica per rispondere al caso d’uso nel quale il professionista refertatore stia refertando esami di ruotine – anche complessi e con grande carico rielaborativo – e deva interrompere tale attività per poter refertare un’urgenza.

- gestire al massimo livello di funzionalità della GUI utente (ad esempio alla pari degli esami DICOMizzati in maniera tradizionale) le acquisizioni di tipo Enhanced, tipo Enhanced CT/MR e al tomosintesi. L’obiettivo è garantire tempi molto ridotti di trasferimento dei dati e minore complessità a livello di registrazione degli oggetti.

Funzionalità relative alla registrazione ‌

- Prevedere strumenti per la sincronizzazione automatica di esami multistrato, che siano essi appartenenti o meno alla stessa tipologia di esame; in particolare almeno coregistrazione su base anatomica automatica e fusione immagini;

- sottrazione di immagini;

- segmentazione automatica (con indicazione dei settori anatomici);

- funzionalità di correzione del movimento,

- registrazione multi modalità rigida e non;

Funzionalità relative all’imaging polmonare ‌

- valutazione quantitativa dei noduli polmonari (volume, VDT);

- valutazioni del contrast enhancement nelle lesioni neoformate degli organi parenchimatosi mediante analisi della perfusione (MTT, time to peak, etc.);

Funzionalità relative all’imaging del Colon ‌

- colonscopia virtuale: disponibilità funzione di flythrough completo del colon, compresa

o la visualizzazione e il caricamento affiancati multi-volume automatici,

o la creazione e la modifica dei percorsi di flythrough

o l’identificazione delle strutture di forma sferica.

o Sottrazione delle strutture ad alta densità, come ossa e metallo

Funzionalità relative all’imaging odontoiatrico ‌

Strumenti clinici per la visualizzazione e la manipolazione delle immagini odontoiatriche a sostegno dell'analisi e della visualizzazione di set di dati provenienti da TC volumetrica della regione maxillo-facciale.

- Applicazione del risultato della ricostruzione curvilinea (CPR) per generare proiezioni "panoramiche" in vari

- piani e di vario spessore. Generazione di ricostruzioni multi-planari trasversali (MPR trasversali) a incrementi predeterminati lungo la curva definita e utilizzarle per ottenere misurazioni chiave di ausilio alla pianificazione chirurgica e implantare.

- Possibilità di visualizzare in sovrimpressione il percorso del solco mandibolare.

Funzionalità relative all’imaging senologico ‌

Le postazioni dedicate alla Senologia Diagnostica e di screening mammografico dovranno essere corredate di visualizzatore DICOM nativamente integrato, funzionalità di visualizzazione dedicate alla mammografia:

- protocolli di visualizzazione mammografici, visualizzazione marker CAD,

- supporto alle immagini di tomosintesi mediante appositi strumenti di navigazione, sincronizzazione speculare;

- protocolli e strumenti dedicati alla lettura dello screening mammografico;

- Gestione dell’RM della mammella (e.g., ADC, curve, densità, AI...);

Funzionalità relative all’imaging addominale ‌

- Analisi e revisione complete degli organi nella regione addominale e pelvica.

- Calcolo del volume degli organi o delle regioni d'interesse ed utilizzo dei valori di misurazione per il confronto in fase di follow-up.

- Possibilità di analizzare dati dinamici per supportare la valutazione del comportamento dipendente dal tempo dell'intensità o densità dell'immagine della struttura anatomica.

- Possibilità di confrontare i reperti in punti temporali multipli;

- Strumenti relativi alla RM della prostata (e.g., ADC, curve, segmentazione, AI...)

Funzionalità relative all’imaging neuroradiologico ‌

- Rimozione dell'osso e del vaso con la modifica avanzata per supportare l'analisi vascolare inclusa la visualizzazione del rapporto di stenosi, dell'area, del diametro, della sezione trasversale minima, massima, media o perimetrale.

- Calcolo del volume degli organi o delle regioni di interesse ed utilizzo valori di misurazione per il confronto di follow-up. Possibilità di analizzare i dati dinamici per supportare la valutazione del comportamento tempo-dipendente dell'intensità o della densità dell'immagine cerebrale, inclusi CBF, CBV, MTT, TTP, TMax, TOT, RT e grafico di assorbimento.

- Sottrazione strutture ad alta densità come ossa e metallo.

- Supporto a mappe di colori personalizzabili.

Funzionalità relative all’imaging vascolare ‌

- Strumenti di calcolo stenosi, analisi aneurismi, pianificazione, estrazione automatica della centerline dei vasi, linearizzazione del vaso, visualizzazione CPR, misurazione di diametri e lunghezza, fly-through per l’analisi interna del vaso, guida alla pianificazione degli interventi per l’introduzione di stent-graft con report specifici per vendor.

Funzionalità relative all’imaging RM corpo ‌

Strumenti clinici per l’analisi di sequenze di immagini RM 2D, 3D e 4D. Analisi completa sia dal

punto di vista anatomico che funzionale, compresa:

- la generazione di linee mediane per l'analisi dei vasi;

- analisi dei dati dinamici per supportare la valutazione del comportamento tempo-dipendente dell'intensità o densità dell'immagine della struttura anatomica;

- misurazione del volume degli organi o le regioni di interesse con il valore di intensità ottenuto e utilizzo dei valori di misurazione per il confronto in fase di follow-up;

- analisi multi-fase e misurazione del tROI (tempo-intensità regione di interesse):

- visualizzazione della mappatura parametrica e grafica.

Funzionalità relative all’imaging in cardioradiologia ‌

Il sistema PACS dovrà essere dotato di strumenti avanzati per l’elaborazione di immagini cardio-TC, garantendo la collaborazione tra radiologi e cardiologi in ambito della diagnostica cardiovascolare e nella pianificazione degli interventi di Cardiologia Interventistica.

- segmentazione automatica dell’albero coronarico;

- vista ‘stretch’ dei vasi e visualizzazione delle sezioni perpendicolari disponibili per l’analisi;

- calcolo delle percentuali di stenosi basato su diametro minimo ed area;

- vista simulata della coronarografia per determinare il ‘foreshortening’ nelle diverse proiezioni;

- misurazione del calcio attraverso Xxxxxxxx score, volume e massa;

- workflow dedicati per interventi TAVI;

- workflow dedicati alla valutazione delle vie di accesso femorale, succlavia, transapicale, transaortico e transettale;

- simulazione della vista angiografica;

- localizzazione automatica dei nadir basata su algoritmi di Intelligenza Artificiale;

- posizionamento di device virtuali per la simulazione degli interventi;

- simulazione della vista ecocardiografica transesofagea;

- ricostruzione del percorso del catetere per gli accessi transettali simulazione completa per gli accessi diretti;

- gestione delle endoprotesi fenestrate con diagramma e segmentazione automatica dei vasi viscerali;

- valutazione automatica del livello di apposizione dello stent a livello di colletto dell’aneurisma;

- tool completo per la misurazione di angoli (tangenziali, di tortuosità e lungo la centerline);

- esportazione per stampa tridimensionale.

Funzionalità relative alla radiologia interventistica ‌

Si richiedono funzionalità di visualizzazione e post-elaborazione delle immagini strettamente integrate con l’area di refertazione, quali:

- moviola digitale con velocità di ripetizione variabile dall’operatore;

- strumenti di base quali ROI, zoom, pan, controllo dinamico della luminosità e del contrasto (W/L);

- post elaborazione angiografica per analisi quantitativa vascolare;

- magazzino integrato con la refertazione.

10.3.3 Funzionalità trasversali per l’implementazione di strumenti di Intelligenza Artificiale per l’utilizzo ‌

in routine clinica

Il sistema RIS-PACS deve essere predisposto per consentire l'impiego di strumenti di AI a supporto della diagnosi del medico ed elaborazione delle immagini. I risultati degli algoritmi di intelligenza artificiale devono essere mostrati sul visualizzatore PACS e importabili direttamente nel RIS, che ne deve correttamente interpretare il significato.

Essi devono contribuire a definire il flusso di lavoro e il percorso diagnostico/terapeutico del paziente, implementando - ad esempio - la prioritizzazione delle liste di lavoro, l'indicazione degli score e del livello di urgenza.

Visto il rapido e costante aumento delle applicazioni di AI in ambito clinico, il sistema RIS- PACS deve prevedere la massima apertura verso nuovi strumenti di AI che dovessero essere introdotti nel mercato.

Pertanto, dovrà essere offerta una PIATTAFORMA di fruizione on demand di moduli di intelligenza artificiale, che possa portare i risultati dei vari algoritmi all’attenzione del radiologo/medico i medicina nucleare sul proprio verticale in modo da integrare in modo configurabile – automatico o no – i risultati dell’AI.

I moduli da fornire all’avviamento del sistema, senza onere aggiuntivo, per i volumi regionali della specifica attività di refertazione, sono:

- Valutazione quantitativa lesioni demielinizzanti

- Valutazione quantitativa volume del cervello

- Individuazione delle fratture

- Valutazione dell’aneurisma dell’aorta

L’offerente dovrà esporre ed aggiornare almeno ogni 6 mesi un CATALOGO aggiornato di moduli elaborativi avanzati da poter scambiare e attivare/riattivare durante il periodo contrattuale, mediante l’attivazione di canoni a tempo e volume.

10.3.4 Funzionalità trasversali per l’implementazione della piattaforma di PACS scientifico ‌

Il sistema RIS-PACS deve implementare funzioni avanzate di PACS Scientifico, che permettano la ricerca di esiti clinici e studi sulla base di una semplice categorizzazione e l’esportazione automatizzata dei conseguenti dataset imaging anonimizzati.

La piattaforma di PACS Scientifico deve operare sull’intero archiviato, indipendentemente dal produttore, secondo procedure a norma e compatibilità con i principi e criteri del GDPR.

Il PACS scientifico dovrà poter definire delle basi dati che costituiscano una predisposizione, in collaborazione con la piattaforma di Intelligenza Artificiale, di piani di studio per lo sviluppo di algoritmi di AI. In tal senso dovrà presentare degli strumenti che automatizzino o semplificano all’operatore la predisposizione della classificazione, delle numerosità casi controllo e cetera, fino al test dell’algoritmo sui casi di routine clinica.

IL sistema deve supportare la classificazione automatica dei casi secondo regole

impostabili e che si avvalgono anche dell’applicazione di algoritmi id AI.

10.3.5 Funzionalità trasversali per l’implementazione della gestione dell’imaging nell’FSE cittadino ‌

Si intende fornire al cittadino un portale in SaaS, anche in versione mobile, integrato con il Fascicolo Sanitario Elettronico Sesamo sia su piattaforma PC che mobile. Tale portale intende permettere la fruizione basica delle immagini - senza tool d’elaborazione - e lo scarico, per tutti gli studi disponibili a sistema, del pacchetto zip con il contenuto dettato dal profilo IHE Portable Data Imaging.

L’applicazione del portale è installata in datacenter INSIEL sulla infrastruttura messa a disposizione dall’aggiudicatario e integrata con l’FSE e resa disponibile internet a cura di INSIEL S.p.A..

10.3.6 Funzionalità trasversali per l’implementazione della produzione e distribuzione di CD Paziente ‌

Si intende incluso tra i servizi anche il servizio di produzione e stampa di CD/DVD paziente. Il servizio prevede la centralizzazione della produzione di CD/DVD paziente in un unico sito per presidio ospedaliero, tipicamente presso il CUP.

La produzione CD/DVD deve essere marginale perché la modalità principale per restituire referto e immagini al paziente ambulatoriale esterno dovrà essere lo scarico dal portale FSE Sesamo, e dunque ci si attende che l’architettura e la produzione massima siano quelle esposte in Allegato A.

La preparazione dei job di stampa è delegata al sistema informativo ospedaliero di Insiel S.p.A. che li invia al sistema di produzione CD/DVD paziente. Il confezionamento, inteso come attività di abbinamento tra referto cartaceo e supporto ottico e successivo imbustamento, è organizzato con risorse proprie di ciascuna Azienda.

Lo schema sottostante descrive il flusso relativo al modello centralizzato per singolo presidio:

Il sistema produce il CD/DVD paziente contenente il referto e le immagini dello studio, o degli studi, associati secondo le indicazioni ricevute dal sistema informativo ospedaliero. Per quanto attiene alle specifiche tecniche fa riferimento al profilo di integrazione PDI‑Portable Data for Imaging di IHE, con inclusa opzione viewer di experience utente coerente con quella del sistema viewer d’ospedale.

Le apparecchiature messe a disposizione dal fornitore del servizio devono essere configurate e caratterizzate da prestazioni di livello tale da garantire la produttività dei singoli siti di produzione, minimizzando l’impatto operativo degli utenti e l’impatto logistico complessivo per singolo sito.

Il sistema di produzione CD/DVD deve operare in modo automatico, senza la presenza fisica dell’operatore, esclusi i momenti di ripristino dei consumabili necessari per il funzionamento e del recupero dei pezzi prodotti.

Il servizio dovrà includere la possibilità di erogare volumi di cd paziente nelle sedi indicate nell’

ALLEGATO A: DIMENSIONAMENTO DELL’IMPIANTO PACS FVG.

Le apparecchiature messe a disposizione saranno configurate secondo le disposizioni

dell’allegato IT.

Per i produttori che operano su RIS e MIS, dovrà essere possibile avere un cruscotto di produzione a disposizione degli operatori che sono interessati al relativo workflow, e attivare la produzione del supporto da tali applicativi.

Il contenuto del CD/DVD deve essere identico a quello prodotto da integrazione, ovvero da

“stampa massiva”.

10.3.7 Funzionalità necessarie all’integrazione con gli applicativi del SISR e con le modalità di ‌

acquisizione

Il sistema è fortemente integrato con il Sistema Informativo Ospedaliero (SIO), realizzato da Insiel S.p.A..

Si rimanda all’allegato B “PRINCIPI DI INTEGRAZIONE NEL SISTEMA INFORMATIVO

OSPEDALIERO FVG” per il dettaglio di come i moduli di visualizzatore, gestore e archivio di immagini,

oltre al verticale di reparto, si possano collocare nel SIO.

Si precisa che a seguito di valutazione, relativamente all’integrazione e alla identificazione univoca di ogni singolo studio inviato al sistema oggetto di fornitura verrà utilizzato lo SUID. In generale, è previsto uno scenario di minima nel quale sono richieste solo transazioni standard DICOM/HL7 già aderenti ad un profilo IHE pubblicato e un modello a tendere basato su FHIR.

FSE 2.0

10.4 Formazione e affiancamento ‌

Nell’ambito dell’assistenza on site dovranno essere svolte attività di formazione e

affiancamento degli operatori sanitari e tecnici delle Aziende, con l’obiettivo di creare le migliori condizioni d’uso dei sistemi e garantirne nel tempo l’uso sicuro, appropriato ed economico.

Si intende nel seguito:

• per formazione, il complesso di attività avente lo scopo di fornire nozioni e competenze sui sistemi agli operatori, comprendendo almeno lezioni frontali e sessioni di addestramento pratico al di fuori dalla abituale attività sanitaria, con la possibilità per gli operatori sanitari di acquisire crediti ECM; tali attività potranno essere filmate da parte delle Aziende Sanitarie e riproposte poi in video via intranet o via FAD anche per personale esterno all’azienda (es. operatori di altre aziende pubbliche o private accreditate del SSR). I docenti dovranno perciò acconsentire alla divulgazione delle registrazioni;

• per affiancamento, il complesso di attività avente lo scopo di consolidare le competenze e nozioni acquisite in fase di formazione dagli operatori, nonché di superare eventuali problematiche di ordine pratico, comprendendo la presenza negli ambienti in cui il sistema è presente del tecnico on site (o di altro personale qualificato incaricato dal Fornitore) nel corso della abituale attività sanitaria.

L’affiancamento degli operatori, principalmente sanitari, dovrà essere un’attività svolta con continuità, come pure la formazione. Dovranno essere prodotti report – inclusi nella reportistica trimestrale - dell’attuazione del piano di formazione e affiancamento in ogni periodo di riferimento. L’assenza di attività specifica documentata (materia e nome del personale formato/affiancato) sul periodo di riferimento costituirà evidenza di non conformità.

Inoltre, dovranno essere previsti specifici corsi di formazione per:

• gli operatori neoassunti o trasferiti (a causa del normale turn over del personale); sarà cura del Fornitore tenere un registro aggiornato delle attività di formazione e affiancamento somministrate che permetta di individuare gli operatori sanitari interessati da tali attività, al fine di verificare costantemente che tutti gli operatori sanitari coinvolti siano stati opportunamente formati e informati sui sistemi;

• agli operatori inerenti al nucleo operativo di ARCS e ai referenti di ogni Azienda Sanitaria. In particolare, per questi ultimi il Fornitore dovrà organizzare corsi di formazione certificata (sia lezioni frontali che sessioni di addestramento pratico), al fine di fornire tutte le nozioni necessarie per svolgere con competenza tutte le attività per la risoluzione dei casi di guasto più frequenti, ovvero per interventi di manutenzione correttiva di primo livello. Nella fattispecie, il piano di formazione e affiancamento degli operatori tecnici delle Aziende dovrà contemplare un calendario di formazione, erogabile anche tramite videolezioni, con almeno due sessioni annue di formazione svolte da uno specialista di prodotto sulle peculiarità dei software e sulle nuove funzionalità implementate nelle nuove versioni. Inoltre, tali eventi formativi, dovranno ripetersi ogni qualvolta muteranno l’architettura e le caratteristiche del sistema o in caso di turn over degli operatori tecnici. In ogni caso, la formazione e

l’affiancamento degli operatori tecnici delle Aziende dovrà essere “certificata”, ovvero il Fornitore dovrà rilasciare un certificato individuale che attesti la somministrazione di quanto necessario per acquisire le competenze tecniche e le nozioni sufficienti ad eseguire quanto oggetto di formazione, esplicitando l’impegno orario erogato. Tali certificati vanno perciò intesi come documenti redatti in forma scritta, esplicita e sottoscritta, in cui il fabbricante

dichiara che all’operatore tecnico è stato somministrato un corso di formazione qualificante

per lo svolgimento sui sistemi le attività oggetto di formazione.

Le attività di formazione e affiancamento sono richieste per tutte le Aziende Sanitarie a partire dalla data di attivazione del servizio. Il servizio di affiancamento e assistenza tecnico/funzionale agli utenti dovrà essere fornito per il tramite, in primis, di una squadra di personale on-site adeguatamente formata.

Le ditte offerenti dovranno redigere un elaborato che descriva contenuti, tempistica e modalità del programma di formazione al personale utilizzatore del sistema RIS-PACS, dettagliato per ogni presidio di erogazione. La logistica verrà invece concordata successivamente tra la ditta aggiudicataria, le singole Aziende e il Gruppo centrale di gestione PACS.

La proposta dovrà differenziarsi per le diverse figure professionali (medici, tecnico sanitario, tecnico professionale dei servizi di ingegneria clinica e dei servizi dei sistemi informatici/informativi, fisici sanitari) coinvolti nell’utilizzo del sistema. Specificatamente per i profili sanitari, l’offerta formativa dovrà tener conto, oltre che dei contenuti strettamente legati all’utilizzo di tipo clinico delle attrezzature, anche delle conoscenze utili a risolvere eventuali disfunzioni del sistema in maniera autonoma o collaborando con altre figure.

La ditta dovrà differenziare le proposte di formazione da effettuarsi prima e ad installazione avvenuta.

La ditta aggiudicataria dovrà nominare un suo responsabile per la formazione che, qualora richiesto dalle singole Aziende o dalla struttura di coordinamento regionale, dovrà collaborare alla produzione della documentazione necessaria ad accreditare gli eventi di formazione precedenti la fase di installazione e quelli successivi ed inerenti alla formazione sul campo (ulteriori informazioni sulla formazione ECM in Friuli Venezia Giulia possono essere desunte dal sito internet dell’Agenzia Regionale della Sanità).

Il responsabile della formazione inoltre produrrà successivi piani formativi, che dovranno essere sottoposti all’attenzione del gruppo regionale, ogni volta siano previsti degli aggiornamenti di sistema (le metodologie di intervento verranno di volta in volta concordate).

La ditta aggiudicataria si impegna inoltre, qualora richiesto dalle singole Aziende o dal Gruppo regionale, ad organizzare eventi di Formazione sul campo per personale neoassunto o per nuovi centri di produzione di bioimmagini che potrebbero essere inseriti successivamente nell’impianto PACS.

10.5 Documentazione, reportistica, monitoraggio ‌

Il servizio dovrà essere corredato dalla seguente documentazione: elenco dei CV e documenti di tutte le figure tecniche operative impiegate sul campo – onsite – e che si interfacciano col team di progetto.

Per tutto il periodo di vigenza contrattuale, l’Aggiudicatario dovrà provvedere alla stesura e all’aggiornamento di tutta la documentazione necessaria per valutare e monitorare costantemente il servizio, nonché al fine di adempiere a tutte le esigenze di carattere tecnico-amministrativo.

La documentazione e la reportistica manutentiva dovranno rispecchiare esattamente lo stato di consistenza corrente del sistema, e contemporaneamente consentire di ricostruire nel dettaglio i processi e le attività tecnico-amministrative di cui è stato oggetto nel tempo

L’Aggiudicatario dovrà rendere disponibile e consultabile in ogni momento alle Aziende del SSR un elenco dettagliato e completo degli elementi in manutenzione (non esaustivamente, si chiede il mantenimento di un completo inventario) inclusivo delle date di scadenza delle garanzie e dell’inventario delle licenze con relative tipologie, numerosità, estensione ed eventuali scadenze e

delle apparecchiature in gestione e in magazzino (es. schede video, monitor medicali e workstation in fase di installazione o transito).

Tale inventario dovrà avere una forma informatica di database (almeno Access), dovrà essere aggiornato quotidianamente e interrogabile dai sistemi di business intelligence aziendali.

Inoltre, è da intendersi parte integrante della fornitura tutta la documentazione degli interventi eseguiti riguardanti attività tecniche o progettuali.

Tutta la documentazione e reportistica dovrà essere in lingua italiana ed in formato almeno elettronico ufficialmente inviato; in ogni caso tutte le copie dovranno essere costantemente allineate tra loro (elettronica/cartacea e Aziende/aggiudicatario).

Con cadenza trimestrale (previamente alla emissione della fattura e preferibilmente allegandolo ad essa) la ditta aggiudicataria dovrà produrre almeno un report complessivo e dettagliato sull’attività svolta, con dettaglio almeno:

- dell’attività e risoluzioni di problemi, con indicazione del numero di segnalazione dei tempi di presa in carico e risoluzione e della tipologia di guasto (bloccante, non bloccante) e una breve descrizione/categoria del merito

- degli eventi e rilievi occorsi in materia di sicurezza informatica del servizio

- elle misurazioni delle SLA di performance

- delle segnalazioni emerse dalla manutenzione ordinaria preventiva

- delle versioni installate degli applicativi e di tutti gli aggiornamenti effettuati

- dell’attività di manutenzione dei dispositivi medici in carico (es. verifiche di sicurezza elettrica)

- dell’attività di IMAC svolta

- dell’attività di conduzione con l’evidenza delle ore impiegate e della differenza tra

programmato ed effettuato

- della presenza dei tecnici e dei tecnici intervenuti, sia di presidio che non, o avvicendatosi nel periodo con le motivazioni

- della corretta funzionalità e performance tecnica del sistema sulle linee specifiche:

o rispondenza al GDPR ed alla circolare n.2 2017 di AGID sulle misure minime di sicurezza

o produzione cd paziente: numero di cd prodotti

o sistema: numero di visualizzazioni per workstation per giorno della settimana nel periodo, numero di visualizzazione dai reparti: da workstation, da FSE, da DSE per reparto;

o conservazione legale, evidenza della % di casi correttamente presi in carico dalla conservazione

o della formazione e affiancamento eseguito con nominativi – data e materia e contenente anche una relazione di valutazione del servizio, indicazioni sui corsi di aggiornamento frequentati dal personale, certificazioni eventualmente acquisite, ed ogni altro elemento ritenesse utile.

L’aggiudicatario renderà disponibile alle aziende e all’Ente appaltante, un portale web ove interrogare (sezionando i dati per Azienda di competenza su base utente configurato) un database che dovrà rendere disponibili delle viste di consultazione e monitoraggio:

Tali viste, con dati puntuali e esportabili almeno in CSV, e con aggiornamento giornaliero, dovranno includere:

- Attività delle modalità, esponendo in particolare la lista degli studi eseguiti in tutto il periodo contrattuale dalle singole modalità, inclusi gli orari di produzione;

- la produzione di cd paziente, dettagliata per sito e tipologia d’esame;

- l'uso del portale FSE Cittadino, inclusivo di pacchetti scaricati e studi visualizzati

- presenza del personale on site, dettagliata per sede e giornata

- evidenza di SLA chiave concordate

- evidenza della disponibilità dei servizi sulle zone di fornitura previste

- numero di visualizzazioni per workstation per giorno della settimana nel periodo, numero di visualizzazione dai reparti: da workstation, da FSE, da DSE per reparto;

- conservazione legale, evidenza della % di casi correttamente presi in carico dalla conservazione

Resta comunque intesa la facoltà del gruppo centrale di gestione PACS, d’intesa con l’Ente appaltante, di richiedere la modifica dei contenuti e la periodicità della reportistica nonché dei dati di monitoraggio esposti nel database.

La disponibilità del portale web s’intende inclusa nell’avviamento del singolo sito/Azienda

previsto nel piano di avviamento.

11 Modalità di attivazione del servizio ‌

11.1 Subentro e Gestione del transitorio ‌

Si intende come periodo di subentro il periodo dall’aggiudicazione all’effettiva entrata in

servizio del sistema dell’aggiudicatario, a piena funzionalità e in sostituzione del precedente sistema.

Durante il periodo di subentro l’aggiudicatario provvederà ad attuare tutte le attività

necessarie e propedeutiche all’attivazione del nuovo servizio e dismissione del vecchio. A titolo non

esaustivo, si elencano le seguenti attività:

1. il trasferimento dei dati pre-esistenti, sia come archivio imaging che gestionale;

2. presa in carico del parco applicativo esistente, comprensivo di tutti gli strumenti e della documentazione di supporto. Conseguenti azioni di sostituzione o manutenzione in continuità;

3. configurazione delle modalità di acquisizione per il nuovo sistema;

4. installazione e messa in funzione dell’infrastruttura;

5. esecuzione della formazione sul nuovo sistema.

Trasferimento dati ‌

Per fare ciò, l’ente appaltante, per mezzo dell’attuale fornitore del servizio, metterà a disposizione adeguate misure d’esportazione con performance adeguate al rispetto dei tempi concessi per l’attivazione. Per l’imaging, il quantitativo di dati da trasferire è di circa 5 anni di produzione dell’intero sistema.

Formazione ‌

Dovrà essere erogata l’adeguata formazione, per tutte le nuove componenti applicative

introdotte, secondo un piano condiviso con l’Ente appaltante e finalizzato al rispetto della data di attivazione. La formazione deve essere documentata e dimostrata.

Configurazione delle modalità d’acquisizione ‌

Tra le attività di subentro dovrà rientrare inoltre il servizio di configurazione delle modalità secondo quanto di seguito dettagliato.

Le Aziende del SSR provvederanno a fornire all’aggiudicatario le sottoreti e corrispondenti VLAN per la realizzazione delle reti isolate – caratteristiche della propria rete segmentata nello spirito della norma ISO 27000 applicata alla sanità e ai sistemi non in controllo aziendale – per ospitare e includere nella LAN aziendale gli host messi a disposizione dal fornitore aggiudicatario e necessari per l’erogazione del servizio.

A quel punto, tutto il parco macchine d’acquisizione risulta ancora configurato – nell'ambito di una configurazione standard IHE SWF – con indirizzi di rete e endpoint di storage e worklist propri del sistema precedente, così come configurazioni di dettaglio da controllare.

L’aggiudicatario dovrà pertanto farsi carico di tutte le attività per:

1. le modalità di acquisizione nelle nuove reti fornite dalle Azienda, interfacciandosi con le ingegnerie cliniche aziendali e i produttori/manutentori in funzione delle modalità operative in essere in ogni azienda;

2. determinare i traffici necessari verso la propria infrastruttura per configurare i firewall aziendali di interconnessione tra le VLAN e i propri dispositivi di storage e worklist

3. modificare i nodi di storage, inclusivi di tutti i servizi SWF (storage committment e MPPS in primis) per puntare agli endpoint del servizio in avvio. Per garantire la continuità di servizio, le modalità dovranno essere configurare con due endpoint nella nuova infrastruttura, a titolo d’esempio il sistema on premise e il sistema in datacenter Insiel;

4. modificare gli indirizzi degli endpoint di accesso ai servizi di worklist (sempre secondo IHE SWF) verso gli IP che li implementeranno. Quest’ultimi saranno identificabili

dall’aggiudicatario per i servizi di gestione diretta (es. Radiologia) o comunicati dalla stazione appaltante per gli altri servizi.

5. controllare e settare la configurazione dei servizi di storage per

a. compressione nativa sulla modalità

b. uso di storage class ottimali quali le classi enhanced

La configurazione delle modalità dovrà essere funzionale all’interfacciamento con

l’architettura applicativa offerta e il sistema di business continuity e aggiornamento a caldo offerto, tra installazione on premise e in datacenter Insiel.

È richiesto che, per i sistemi onpremise messi a disposizione, sia incluso un sistema di

bilanciamento in alta affidabilità che possa permettere all’infrastruttura installata presso il datacenter Insiel, di dare servizio in caso di fault – accidentale o programmato – dell'infrastruttura onpremise.

Si intende che tutte le attività di transizione siano completate, a cura dell’aggiudicatario che è l’owner delle stesse e dunque l’unico referente per il loro completamento, prima dell’effettiva attivazione del nuovo servizio.

11.2 Conclusione delle attività di subentro ‌

Al termine delle attività di subentro l’aggiudicatario dovrà produrre un verbale attestante il completamento del passaggio di consegne che dovrà essere sottoscritto dal Fornitore subentrante. Tale verbale dovrà indicare eventuali carenze della documentazione fornita a supporto del subentro, in termini di obsolescenza o incompletezza.

Tutte le attività di subentro sono senza oneri aggiuntivi per l’Amministrazione.

Durante le attività di subentro e sino alla data di attivazione definita nel Contratto esecutivo, la responsabilità dei servizi e di tutte le attività continuerà ad essere in capo al Fornitore uscente; in tale periodo, il Fornitore aggiudicatario non percepirà alcun corrispettivo. Per tutte le attività di

subentro, l’Amministrazione si riserva di indicare ulteriori requisiti minimi in funzione dell’evoluzione

del contesto applicativo e di esigenze attualmente non pianificabili o non prevedibili.

11.3 Termini di attivazione ‌

12 mesi per la completa attivazione del sistema su tutti i presidi regionali. L’attivazione è conseguente al completamento dell’installazione, configurazione, formazione, interfacciamento a tutte le modalità di acquisizione.

11.4 Procedure di collaudo e accettazione ‌

Il Piano di Collaudo dovrà essere predisposto e proposto dall’aggiudicatario e dovrà essere eseguito anche sul sistema in produzione.

Le prove verranno eseguite secondo le modalità descritte nel Piano di Xxxxxxxx proposto dalla Ditta aggiudicataria, una volta sottoposto alla valutazione preliminare da parte della Commissione di collaudo, nominata dall’Ente appaltante, ed eventualmente modificato in relazione agli esiti della valutazione stessa.

Il collaudo dovrà essere eseguito solo al termine della fase di attivazione del sistema stesso e quindi dopo la data di completamento della formazione per ogni Azienda.

Il collaudo dovrà evidenziare il rispetto – nella fase di attivazione – delle SLA attese.

Nel caso in cui alla conclusione della fase di attivazione, dovessero presentarsi della cause di forza maggiore indipendenti dalla responsabilità della ditta aggiudicataria e tali da non consentire il rispetto dei termini sopra riportati, saranno ricercate e condivise tra l’Ente appaltante e la ditta aggiudicataria eventuali soluzioni transitorie che possano consentire comunque l’avvio, seppur parziale, dell’utilizzo del sistema RIS - PACS oggetto della fornitura, nel rispetto degli interessi sia della ditta aggiudicataria che dell’Azienda utilizzatrice finale.

Il collaudo del sistema e dei servizi descritti nel presente Capitolato sarà effettuato dal personale tecnico e specializzato della Ditta aggiudicataria alla presenza della Commissione di collaudo, la quale sarà composta dalle principali competenze coinvolte nell’utilizzo delle apparecchiature e degli applicativi, nonché nella gestione dell’impianto RIS-PACS aziendale.

Le fasi di collaudo saranno organizzate:

- per singola Azienda (Collaudo Aziendale) e consisterà di minima nella verifica della corretta esecuzione di tutte le attività previste per l’attivazione, al fine di riscontrare la funzionalità del sistema, dei servizi e delle interfacce di integrazione, in modo tale da consentire il pieno e completo utilizzo clinico del sistema;

- sull’intera fornitura (Collaudo Finale) e consisterà di minima nella presa d’atto dei collaudi eseguiti con esito positivo per le singole aziende, nella verifica delle funzionalità e delle integrazioni sul sistema nella sua totalità e nella verifica della corretta e completa esecuzione della formazione al personale.

La Ditta dovrà provvedere a rimuovere a proprio carico eventuali anomalie riscontrate nel corso del collaudo. Il collaudo si riterrà concluso con esito positivo al termine del superamento delle prove previste dal Piano di Xxxxxxxx.

Resta inteso che il Collaudo Finale dovrà essere eseguito entro i termini di attivazione indicati nel capitolo dedicato.

Si precisa che l’appalto è concepito come obbligazione di risultato: la fornitura dovrà, pertanto,

includere ogni prestazione necessaria a tale scopo, anche se non espressamente prevista in atti di gara

ed in offerta. Il risultato atteso è la fornitura in opera perfettamente funzionante del sistema nella sua totalità.

Le commissioni di collaudo saranno composte con personale aziendale e con il supporto del gruppo centrale per la gestione del sistema PACS.

12. Livelli di servizio attesi (SLA)‌

L’Amministrazione intende avvalersi degli indicatori di qualità, di performance e di evidenza di non adeguato livello di funzionamento del sistema riportati nel presente paragrafo.

Il Fornitore del servizio è tenuto a mantenere il sistema e a eseguire le attività attese da questo capitolato nel rispetto di tali livelli. Le azioni contrattuali previste in caso di mancato rispetto dei livelli di servizio vengono definite nel capitolo “Penali”.

Le rilevazioni, sia condotte a titolo esemplificativo mediante sopralluoghi che via esecuzione di misure strumentali, saranno effettuate a sorpresa e a campione da parte del committente, che ne contesterà l’esito al fornitore trimestralmente e in ogni caso all’insorgere di situazioni di particolare disagio operativo.

Codice	Parametro	Metodo di calcolo e rilievo	Valore di riferimento
SLA 1	Prestazioni archivio	Esecuzione di Query Study Level by date con Probe DICOM da un host della LAN in cui è ospitato l’archivio	4.000 millisecondi
		Esecuzione di Query Instance Level by Study Instance UID da un host della LAN in cui è ospitato l’archivio	4.000 millisecondi
		Esecuzione di Query Instance Level by InstanceUID e move di immagine di riferimento 30 Mb da un host della LAN in cui è ospitato l’archivio	8.500 millisecondi
	Uptime archivio	Attivazione della rilevazione un probe DICOM con un numero di rilevazioni rappresentanti il periodo di analisi	Sistema disponibile
SLA 2	Manutenzione	Tempo di intervento in teleassistenza su guasti BLOCCANTI	0,5 ore solari dalla generazione della chiamata
		Tempo di intervento in teleassistenza su guasti NON BLOCCANTI	4 ore lavorative dalla generazione della chiamata
		Tempo di intervento on site su guasti BLOCCANTI	1 ora solare dalla generazione della chiamata
		Tempo di intervento on site su guasti NON BLOCCANTI	8 ore lavorative dalla generazione della chiamata
		Tempo di risoluzione guasti BLOCCANTI	4 ore solari dalla generazione della chiamata
		Tempo di risoluzione guasti NON BLOCCANTI	16 ore lavorative dalla generazione della chiamata
SLA 3	Rilascio ed applicazione patch gravi applicative o di sicurezza	Rilevazione della persistenza o risoluzione del problema	Numero di giorni naturali consecutivi a partire dal decimo dalla segnalazione del malfunzionamento
SLA 4	Continuità di servizio e	Rilevazione della persistenza o risoluzione del problema. Il disastro è definito anche per il fault di un singolo	RPO < 2 ore e RTO < 4 ore

	Disaster Recovery	servizio aziendale tra archiviazione, refertazione e distribuzione
SLA 5	Performance di archiviazione	Rilevazione del comportamento del sistema	Velocità di immagini archiviate di almeno 15 immagini/secondo per ciascuna thread/modality (per immagine s’intende un’immagine DICOM di SopClass CT da 512x512 pixel compressa JPEGLossLess dall’acquisition modality in condizioni di carico standard)
SLA 6	Disponibilità prima immagine	Rilevazione del comportamento del sistema	Disponibilità alla prima immagine < 2 secondi, già dalla prima immagine archiviata entro 2 anni di anzianità per tutti gli studi, 5 secondi per lo studio completo di RX tradizionale
SLA 6	Disponibilità prima immagine	Rilevazione del comportamento del sistema	Disponibilità alla prima immagine < 5 secondi, già dalla prima immagine archiviata entro 4 anni di anzianità
SLA 7	Possibilità di elaborazione di studi precedenti	Rilevazione del comportamento del sistema	10 anni, per tutte le fonti disponibili e con tutti gli strumenti d’elaborazione disponibili a sistema incluso scarico da portale quando attivo
SLA 8	Consistenza e profondità dell’archivio contrattuale	Rilevazione del comportamento del sistema	5 anni
SLA 9	Personale	(1) Rilievo, del numero di giorni coperti da un minor numero di figure richieste per Azienda o per sito sul totale di 365 giorni	0, a meno dei giorni necessari alle sostituzioni next business day in caso di assenza improvvisa
		(2) Rilievo delle caratteristiche del personale utilizzato e della relativa formazione e competenza richiesta	Rispetto dei requisiti contrattualizzati
		(3) Rilievo, della disponibilità di una comunicazione in merito a assenza/sostituzione personale	Presente/non presente
SLA 10	Mantenimento e disponibilità dei dati del servizio e della reportistica	Rilevazione periodica	L’inventario del sistema e i dati di funzionamento previsti nella reportistica sono sempre disponibili su richiesta e aggiornati al mese corrente
SLA 10		Rilevazione periodica	Disponibilità della reportistica contestualmente alla fatturazione


SLA 11	Tempistiche di fornitura	Rilevazione della disponibilità secondo i termini indicati in offerta tecnica	Disponibile
SLA 12	Conformità e qualità della fornitura	Rilevazione di non conformità e/o di mancata qualità della fornitura afferenti ad obbligazioni contrattuali non adempiute nei tempi e/o nelle modalità stabilite	Conforme/non conforme

Adeguamento del canone di servizio

In ragione del livello di complessità della fornitura oggetto della presente gara e del conseguente grado di impatto sulle situazioni organizzative aziendali e relativi flussi operativi, resta inteso che l’Ente appaltante, a seguito di mutate condizioni organizzative o gestionali o produttive nelle singole Aziende, avrà facoltà di variare la dotazione tecnologica complessiva aggiudicata (Dotazione base) anche in termini di dimensioni dei sistemi di archiviazione previsti o moduli d’elaborazione previste.

13. Penali ‌

L’Amministrazione si riserva di diritto di applicare delle penali nel caso il servizio non sia svolto secondo i requisiti contrattualizzati e secondo i livelli di servizio attesi e in particolare per quelli definiti puntualmente al paragrafo “Livelli di Servizio attesi” di questo documento.

Qualora la ditta appaltatrice venga meno ad uno qualsiasi degli obblighi assunti con l’aggiudicazione dell’appalto ed assoggettati al presente capitolato, incluse le eventuali estensioni ed opzioni di fornitura, potrà essere applicata a suo carico, per ogni infrazione contestata, una penale stabilita in base alla gravità della carenza rilevata o al danno subito e/o al disservizio provocato.

In ogni caso è fatta salva la facoltà dell’Ente appaltante di agire giudizialmente per il risarcimento dell’eventuale ulteriore danno subito e/o delle spese sostenute a seguito dell’inadempimento.

Con riferimento ai livelli di servizio attesi definiti al paragrafo precedente, l'entità della penale è comminata in due gradazioni: una per il primo rilievo e una per ogni successivo rilievo condotto entro 5 giorni lavorativi dal precedente.

Per ogni giorno naturale consecutivo di ritardo nel Collaudo Finale è applicata una penale in misura dello 0,2% del canone trimestrale.

Nella tabella sottostante si riportano i valori massimi delle penali:

SLA	primo rilievo	rilievi successivi	note/variazioni
SLA 1	1.000,00€	2.000,00€
SLA 2 - guasti bloccanti	1.000,00€	3.000,00€	fino a 1.000,00€ il primo giorno di sussistenza della non conformità e fino a 3000,00€ per ognuno dei giorni successivi
SLA 2 - guasti non bloccanti	500,00€	1.500,00€	fino a 500,00€ il primo giorno di sussistenza della non conformità e fino a 1.500,00€ per ognuno dei giorni successivi

SLA 3	1.000,00€	2.000,00€	fino a 1000€ il primo giorno di sussistenza della non conformità e fino a 2.000,00€ per ognuno dei giorni successivi
SLA 4	2.000,00€	3.000,00€
SLA 5	1.000,00€	2.000,00€
SLA 6 - immagini entro 2 anni	1.000,00€	3.000,00€
SLA 6 - immagini entro 4 anni	500€	2.000,00€
SLA 7	500€	2.000,00€
SLA 8	500€	2.000,00€
SLA 9 – 1 e 2 - giorni di copertura e formazione	1.000,00€	1.000,00€	fino a 1.000,00€ per ogni giornata di non conformità per Azienda o per sito, anche suddivisibili in ore lavorative. Stessa valorizzazione per ogni risorsa rilevata come non rispondente ai requisiti richiesti.
SLA 9 - 3 - comunicazioni	1.000,00€	1.000,00€
SLA 10	1.000,00€	3.000,00€
SLA 11	− fino a 4.000 € mensili per i servizi attivabili da t0 − fino a 2.650 € mensili per i servizi attivabili da t0+6 − fino a 2.000 € mensili per i servizi attivabili da t0+9 anche frazionabili in giornate di ritardo. Per i soli servizi con attivazione al tempo t0, si attiverà la penale a partire da ritardi successivi al primo mese
SLA 12	fino a 2.000,00€ per ogni non conformità rilevata

La rilevazione delle SLA sarà gestita dal gruppo di coordinamento centrale di ARCS con opportuno coinvolgimento dei referenti aziendali che verranno nominati.

Le evidenze derivanti dalle rilevazioni avranno effetto probante a fronte delle quali è richiesta una controdeduzione al fornitore del servizio da consegnare ad ARCS entro 15 gg.

Qualora le controdeduzioni non venissero trasmesse all’Amministrazione nel termine indicato, o seppur pervenute tempestivamente, non risultassero a giudizio dell’Amministrazione idonee a

giustificare l’inadempienza, potranno essere applicate le penali stabilite.

Tutte le penali verranno comunicate periodicamente mediante emissione di note di addebito da parte dell’ente e scontate mediante decurtazione del corrispettivo. Qualora i corrispettivi liquidabili al Fornitore non fossero sufficienti a coprire l’ammontare delle penali allo stesso applicate a qualsiasi titolo, nonché quello dei danni dallo stesso arrecati alle Aziende per qualsiasi motivo, le stesse si rivarranno sul deposito cauzionale.

14. Fatturazioni e pagamenti ‌

La fattura relativa ai corrispettivi maturati viene emessa e inviata dal Fornitore con cadenza trimestrale posticipata. La decorrenza del periodo trimestrale di canone viene calcolata a partire dalla Data Convenzionale di Avvio del sistema, definita come il primo giorno del mese successivo a quello in cui viene effettuato il Collaudo Finale con esito positivo

In particolare, nel presente contratto, per i servizi continuativi, la fattura dovrà riportare il CIG e il periodo di riferimento.

Il pagamento di ogni fattura sarà subordinato all’approvazione della reportistica prodotta dal Fornitore per il medesimo periodo di riferimento. La reportistica dovrà essere fornita anticipatamente o contestualmente rispetto alla trasmissione delle fatture.

Il canone sarà soggetto alla modulazione ed eventualmente alla dichiarazione delle penali.

15. Obbligo alla riservatezza ‌

Il Fornitore dovrà considerare tutti i dati e le informazioni dei quali viene a conoscenza nel corso del servizio con la più assoluta riservatezza in osservanza di quanto disposto dalla vigente normativa, in particolare con quanto disposto dal D.L. n. 196/03 e s.m.i. (c.d. Testo Unico della Privacy) e del GDPR

– General Data Protection Regulation – regolamento generale sulla protezione dei dati (regolamento UE 2016/679 del parlamento europeo e del consiglio del 27 aprile 2016) in vigore dal 25 maggio 2018.

In particolare, il personale impiegato è tenuto agli obblighi di riservatezza su fatti e circostanze concernenti i dati personali riguardanti gli utenti, con particolare riguardo verso i dati sensibili, dei quali abbia avuto notizia durante l’espletamento delle proprie mansioni, con l’obbligo di riferire alle Aziende ogni caso rilevante attraverso “Responsabile del servizio”.

Dovrà essere data evidenza all’Azienda delle procedure poste in atto in ottemperanza della legge sopraccitata. Ai sensi del GDPR, le Aziende titolari del trattamento dei dati personali, designa contrattualmente il Fornitore quale responsabile del trattamento dei dati secondo l’art.28 del GDPR che il Fornitore si obbliga ad accettare.

16. Documentazione tecnico qualitativa ‌

Dovrà essere presente la seguente documentazione:

1) Allegato dal titolo “Impegni per il Fornitore” compilato in tutte le sue parti, timbrato e firmato dal legale rappresentante della ditta;

2) Copia dell’OFFERTA ECONOMICA senza indicazione alcuna dei prezzi o di ogni altro elemento che possa determinarlo, tale da permettere una corretta e dettagliata identificazione della configurazione offerta riportante il dettaglio della descrizione e codice dei prodotti offerti;

3) Una relazione dal titolo “RELAZIONE TECNICA” tecnica (max. XX facciate) completa di dati tecnici dei software e dei dispositivi che descrivano in modo chiaro e sintetico le caratteristiche delle componenti del sistema offerto nonché ogni altra informazione utile e documentazione che possa consentire una completa valutazione delle stesse;

Si precisa che nella documentazione presentata dovranno essere espressamente indicati tutti i dettagli che evidenziano come l’offerta possa proporre in essere un servizio che risponda alle richieste espresse nel capitolato di gara.

In particolare, la relazione dovrà essere organizzata secondo i seguenti capitoli e paragrafi:

1) Descrizione della modalità scelta per fornire il servizio.

In particolare, l’offerente indicherà come intenderà gestire il parco applicativo e garantire le funzionalità richieste, declinando le componenti applicative sostituite o manutenute e il dettaglio di come intende procedere.

2) Descrizione dell’architettura

In particolare, l’offerente indicherà l’architettura applicativa che intende metter in produzione per garantire le SLA richieste. Di conseguenza descriverà nel dettaglio l’infrastruttura messa a disposizione e di come questa sia funzionale e necessaria per soddisfare le SLA.

3) Modalità di attivazione del servizio

In particolare, l’offerente, per tutte le funzionalità e applicazioni proposte, dettaglierà le modalità di messa in produzione, inclusa installazione, messa a disposizione, formazione e avviamento.

Nel caso di sostituzione, dettaglierà il piano per arrivare alla messa in produzione complessiva del sistema.

4) Modalità di esecuzione dei servizi di gestione

In particolare, l'offerente dettaglierà le modalità con cui intende eseguire i servizi di gestione, a partire dal personale, le risorse etc.

5) Caratteristiche funzionali

In particolare, l’offerente descriverà le caratteristiche funzionalità sistema offerto, indicato esplicitamente quelle che ritiene migliorative rispetto all’elenco richiesto;

6) Una raccolta di tutte le dichiarazioni di conformità, per tutti gli applicativi mantenuti, sostituiti o messi a dispostone, inclusi

1) MDS2 compilato e firmato

2) Marcatura CE ai sensi dell’MDR di tutte le componenti per le quali è stata prodotta;

3) IHE integration statements per le componenti messe a disposizione

7) Nella relazione d’offerta, l’offerente dovrà supportata da eventuale materiale informativo e tecnico, in cui si descrive come la fornitura e il servizio offerto rispondono a quanto previsto dalla normativa vigente sulla privacy – ove del caso – con dettaglio sugli aspetti peculiari del Regolamento quali privacy by design, privacy by default, e in generale quanto messo in atto per ridurre e minimizzare i rischi in termini di impatto sui dati degli interessati e ogni misura tecnica, giuridica ed organizzativa adottata, tenuto conto dello stato dell’arte. Nel dettaglio dovrà essere descritto,

nell’ottica del GDPR e della sicurezza dei dati, come vengono effettuati i trattamenti di dati all’interno del sistema fornito e nell’ambito delle attività manutentive, compresi eventuali

collegamenti da remoto. Inoltre, dovrà essere dettagliatamente indicato se l’offerente prevede di effettuare trattamenti di dati in sedi diverse da quelle operative e, eventualmente, con quali modalità e sicurezze.

Inoltre, dovrà essere dichiarata la totale assenza di trasferimenti di dati personali al di fuori dello SEE.

Sarà inoltre inclusa una motivata e comprovata dichiarazione, nella quale siano individuate le

informazioni che, nell’ambito delle offerte o delle giustificazioni poste a base delle medesime,

costituiscano segreti tecnici o commerciali (si rimanda a quanto previsto in merito nel dettaglio

dall’art. “Accesso agli atti” del Disciplinare di gara).

La dichiarazione dovrà contenere congrua motivazione circa l’effettiva sussistenza del segreto tecnico o commerciale, con indicazione dell’istituto giuridico posto a tutela della

documentazione secretata (marchio, brevetto, privativa industriale, diritto d’autore o altro diritto

di proprietà intellettuale) e dovrà essere accompagnata dalla documentazione comprovante

l’effettiva sussistenza del segreto tecnico o commerciale dichiarato.

La Commissione Giudicatrice si riserva la possibilità di chiedere ulteriori informazioni di

carattere tecnico che dovessero risultare necessarie per effettuare un’adeguata valutazione.

17. Modalità di attribuzione dei punteggi ‌

La valutazione della Commissione Giudicatrice avverrà sulla base di quanto di seguito indicato.

Il servizio oggetto della procedura è aggiudicato in base al criterio dell’offerta economicamente più vantaggiosa individuata sulla base del miglior rapporto qualità/prezzo, ai sensi dell’art. 108, comma 1 del Codice. La valutazione dell’offerta tecnica e dell’offerta economica sarà effettuata in base ai seguenti punteggi:

Offerta tecnica	Max punti 70
Offerta economica	Max punti 30
TOTALE	Max punti 100

Il servizio offerto dalle ditte concorrenti dovrà avere le caratteristiche prescritte nel Capitolato tecnico. Saranno effettuate le verifiche dell’ammissibilità/non ammissibilità delle componenti offerte in relazione alla corrispondenza o meno a quanto prescritto nel Capitolato.

Nel caso in cui la descrizione delle specifiche tecniche indicate si riferisse casualmente, in tutto o in parte, a caratteristiche possedute da prodotti distribuiti da una sola ditta, si deve intendere inserita la clausola “o equivalenti”. L’eventuale equivalenza tecnica verrà valutata ai sensi di quanto previsto dall’art. 79 del D.Lgs. 36/2023.

La Commissione Giudicatrice appositamente nominata dall’ARCS, laddove lo riterrà necessario, potrà in sede di valutazione richiedere alle ditte partecipanti eventuali chiarimenti in merito all’offerta presentata ritenuti necessari per una più precisa valutazione della stessa.

Si precisa, infine, che tutti i calcoli relativi all’attribuzione dei punteggi (qualitativi, economici e complessivi) e all’eventuale riparametrazione del punteggio qualitativo, verranno eseguiti computando fino alla seconda cifra decimale.

Il punteggio dell’offerta tecnica è attribuito sulla base dei criteri di valutazione elencati nella

sottostante tabella con la relativa ripartizione dei punteggi.

Nella colonna identificata “discrezionale” (D) - il coefficiente è attribuito in ragione dell’esercizio della discrezionalità spettante alla commissione giudicatrice, per ogni sub-criterio di valutazione verrà attribuito un giudizio sintetico a cui corrisponde un coefficiente compreso tra 0 ed 1 (vedi prospetto sotto riportato). Quindi la Commissione giudicatrice moltiplica tale coefficiente per il punteggio massimo disponibile per ogni elemento qualitativo.

Tabella di riferimento per il criterio Discrezionale

Voce di giudizio	Coefficiente
Ottimo	1
Buono	0,8
Discreto	0,7
Sufficiente	0,6
Mediocre	0,4
Scarso	0,2
Non valutabile/non significativo	0

Nella colonna identificata con criterio “Quantitativo Lineare” (sigla Q): punteggi il cui coefficiente è

attribuito mediante applicazione della formula matematica (lineare):

Pi = Pmax * Ci

dove:

- Pi è il punteggio del concorrente i-esimo,

- Pmax è il punteggio massimo attribuibile al criterio,

- Ci è un coefficiente compreso tra 0 e 1 calcolato secondo le formule indicate nelle tabelle di assegnazione punteggi.

Nella colonna identificata con criterio “Tabellare” (sigla T): punteggi fissi e predefiniti che saranno attribuiti o non attribuiti in ragione dell’offerta o mancata offerta di quanto specificamente richiesto. Nella colonna identificata con criterio “On/Off” (sigla O): punteggi fissi e predefiniti che saranno attribuiti o non attribuiti in ragione dell’offerta o mancata offerta di quanto specificamente richiesto.

Criteri di valutazione:

CRITERIO 1

Caratteristiche

tecniche

PUNTEGGIO MASSIMO

CRITERIO 2

Prova pratica

PUNTEGGIO MASSIMO

TOTALE

SOGLIA DI

SBARRAMENTO:

Ai sensi dell’art. dell’art. 108, comma 7 del Codice:

o le offerte che non avranno ottenuto complessivamente almeno 42 punti, saranno escluse dalla successiva fase di valutazione economica.

o Per ogni singolo criterio sono stati previsti dei sub-criteri, dettagliati nelle tabelle successive.

Tabella assegnazione dei punteggi (dettaglio sub-criteri)

CRITERIO 1: CARATTERISTICHE TECNICHE

Sub-criterio	Descrizione	Rif. questionario	PUNT I MAX
Descrizione della modalità scelta per fornire il servizio.	In particolare, l’offerente indicherà come intenderà gestire il parco applicativo e garantire le funzionalità richieste, declinando le componenti applicative sostituite o manutenute e il dettaglio di come intende procedere.
Descrizione dell’architettura	In particolare, l’offerente indicherà l’architettura applicativa che intende metter in produzione per garantire le SLA richieste. Di conseguenza descriverà nel dettaglio l’infrastruttura messa a disposizione e di come questa sia funzionale e necessaria per soddisfare le SLA.
Modalità di attivazione del servizio	In particolare, l’offerente, per tutte le funzionalità e applicazioni proposte, dettaglierà le modalità di messa in produzione, inclusa installazione, messa a disposizione, formazione e avviamento.
Modalità di esecuzione dei servizi di gestione con particolare riferimento all’organizzazione	In particolare, l'offerente dettaglierà le modalità con cui intende eseguire i servizi di gestione, a partire dal personale, le risorse etc
Caratteristiche funzionali	In particolare, l’offerente descriverà le caratteristiche funzionalità sistema offerto, indicato esplicitamente quelle che ritiene migliorative rispetto all’elenco richiesto;
Una raccolta di tutte le dichiarazioni di conformità, per tutti gli applicativi mantenuti, sostituiti o messi a dispostone, inclusi	MDS2 compilato e firmato Marcatura CE ai sensi dell’MDR di tutte le componenti per le quali è stata prodotta; IHE integration statements per le componenti messe a disposizione
CRITERIO 2: PROVA PRATICA

Sub-criterio	Descrizione	Rif. questionario	PUNT I MAX

Al fine di effettuare un’adeguata valutazione del sistema offerto ed in particolare la sua rispondenza alle specifiche esigenze degli utilizzatori, verrà richiesta una prova pratica o una visione dello stesso con almeno 15 giorni di preavviso, secondo modalità che saranno successivamente indicate a mezzo comunicazione scritta.

La prova pratica sarà effettuata presso una o più Strutture Operative delle Aziende coinvolte. I concorrenti dovranno presentarsi nel giorno e luogo fissati in possesso delle apparecchiature e degli accessori e di tutti i materiali in quantità congrua ai fini di una completa valutazione del servizio oggetto di fornitura.

I concorrenti si impegnano a:

• prendersi in carico tutti i rischi derivanti dall’uso dei dispositivi, ivi compreso il furto,

l’incendio e la rottura, nonché la responsabilità per eventuali danni a pazienti e/o operatori.

• al rispetto di quanto previsto dal nuovo Regolamento Generale sulla Protezione dei dati personali (UE) 2016/679 in merito alla tutela dei dati personali, qualora, nell’espletamento della visione in prova, dovesse entrare in contatto con dati personali sensibili, in qualunque forma siano trattati;

• ad eliminare tutti i dati personali sensibili eventualmente archiviati nel dispositivo in visione prima del ritiro alla fine del periodo della prova.

Nel corso della visione la Commissione potrà richiedere la misura dei parametri caratteristici delle

componenti del sistema e la visione dei manuali d’uso e degli eventuali manuali di service.

Resta inteso che la prova dovrà svolgersi nel rispetto degli eventuali protocolli di visione, in vigore

presso l’Azienda.

Sarà facoltà della Stazione appaltante, se ritenuto necessario dalla Commissione Giudicatrice ai fini della valutazione tecnica, richiedere la visione di quanto offerto offerte e/o di alcuni o tutti i moduli/pacchetti software offerti anche solo in modalità demo, mediante presentazione dimostrativa di immagini e filmati su CD/DVD (criterio 2).

La mancata visione dei prodotti proposti, qualora richiesta dall’amministrazione, determinerà l’automatica esclusione dalla gara.

La Commissione Giudicatrice redigerà apposito verbale dei lavori evidenziando tra l’altro le attribuzioni dei punteggi tecnici intermedi relativi a ciascuna offerta, procedendo poi nel seguente modo ed ordine:

- alla dichiarazione di non ammissibilità per le offerte che non abbiano conseguito per il punteggio MINIMO (vedere soglia di sbarramento) previsto per i criteri di valutazione qualità;

- alla riparametrizzazione dei punteggi delle offerte ammissibili, qualora nessuna delle proposte oggetto di esame da parte della Commissione dovesse aver conseguito, a seguito dell'attribuzione del punteggio tecnico complessivo, un totale di punti 70; la Commissione assegnerà in tal caso punti 70 all'offerta che risulti aver conseguito la somma di punti più elevata e alle altre offerte il punteggio definitivo sarà assegnato secondo la seguente formula:

Pt = Pmax * Poc

Poe

In cui

Pt - punteggio tecnico da attribuire all’offerta presa in considerazione

Pmax - punteggio massimo attribuibile (punti 70) Poc - valore dell’offerta considerata

Poe - valore dell’offerta con punteggio più elevato

18. Determinazione dei corrispettivi, modulazione del canone ‌

Coerentemente con l’evidenza che la fase di procurement è una fase cruciale per il controllo del rischio cibernetico – si cita ad esempio la linea guida sul procurement in healthcare dell’Agenzia per la Sicurezza Informatica Europea (ENISA) - l’ente appaltatore intende inserire nel contratto delle leve premianti in grado di spingere il mercato verso l’adozione di funzionalità e tecnologie atte a ridurre il rischio cybernetico e la sostenibilità di gestione delle applicazioni e sistemi IT. Il tutto si intende inoltre come funzionale al risparmio di risorse, umane ed economiche, che potranno essere impiegate nello sviluppo delle funzionalità applicative cliniche quali, ad esempio, l’applicazione

dell’IA.

Il canone di remunerazione del servizio richiesto verrà rimodulato in funzione delle componenti non adeguate al servizio erogato in modalità SaaS ovvero non rispondenti al paradigma zero footprint e con funzionalità di autenticazione/autorizzazione delegata.

La misura di calcolo delle componenti e la valorizzazione della modulazione verranno

determinate in tempo per l’avvio della procedura di gara.

Ad ogni componente da avviare verrà attribuito un peso che contribuirà alla modulazione del canone fino al pieno riconoscimento del canone dovuto.

19. Normativa di riferimento ‌

19.1 Regolamento dei dispositivi medici ‌

l Nuovo Regolamento (UE) 2017/745 e alle successive modifiche introdotte dal Regolamento UE 2020/561 e dal Regolamento UE 2023/607.

Inoltre, al momento dell’Ordinativi di Fornitura nonché al momento della consegna, tutti i dispositivi medici offerti dovranno essere in regola con gli obblighi di registrazione presso la Banca dati dei Dispositivi Medici costituita presso il Ministero della Salute e quanto previsto dal Regolamento (UE) 2017/745.

È richiesto inoltre il rispetto di quanto previsto dalle normative e linee guida emanate da AgID e ACN nonché dalla direttiva NIS. Il Fornitore dovrà pertanto presentare la documentazione attestante la conformità del servizio offerto a quanto previsto dalle “Linee guida - La sicurezza nel

procurement ICT” emanate da AgID nel maggio 2020. In particolare, in riferimento all’Appendice A – Requisiti di sicurezza eleggibili, contenuto all’interno delle “Linee guida - Sicurezza nel Procurement ICT”.

19.2 Protezione dei dati (Privacy)‌

19.2.1 PRIVACY RELATIVAMENTE ALLA PRESENTE PROCEDURA‌

Relativamente alla presente procedura di gara si specifica a tutti gli offerenti che i dati richiesti verranno trattati, nel rispetto della normativa vigente (Regolamento Europeo sulla Protezione dei Dati – GDPR del 14.04.2016

(xxxxx://xxx.xxxxxx.xxx/) e al D. Lgs. 196/2003, cosiddetto Codice Privacy), unicamente ai fini della procedura di individuazione del miglior offerente e della successiva stipula e regolazione del contratto.

Si evidenzia altresì che i dati di cui trattasi non saranno diffusi, fatto salvo il diritto di accesso dei "soggetti interessati" ex L. 241/90, che potrebbe comportare l’eventuale doverosa comunicazione dei dati suddetti ad altri concorrenti alla gara, così come pure l’esigenza dell’Amministrazione di accertamento dei dati dichiarati in sede di gara o comunque previsti ex lege.

19.2.2 PRIVACY RELATIVAMENTE ALL’OGGETTO DI FORNITURA ‌

Relativamente all’oggetto della fornitura, e per tutto il periodo contrattuale, l’aggiudicatario si intende impegnato a rispettare la regolamentazione in vigore applicabile al trattamento dei dati a carattere personale e, in particolare, il regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio del 27 aprile 2016, nonché le disposizioni Aziendali qui definite ed eventuali altri impartite in seguito.

Al termine del contratto, l’aggiudicatario si intende impegnato a distruggere tutti i dati a carattere personale

oggetto del presente contratto sia da ciascun sistema presso le Aziende che, ove del caso, da qualunque

sistema presso l’aggiudicatario stesso, in modo che non siano più recuperabili e si impegna a riconsegnare tutti i dati a carattere personale al singolo Titolare. La trasmissione dei dati deve essere accompagnata dalla

contestuale consegna all’Azienda della documentazione scritta relativa alla distruzione di tutte le altre copie esistenti dei dati nei sistemi dell’aggiudicatario.

19.2.3 DESIGNAZIONE A RESPONSABILE DELL’AGGIUDICATARIO ‌

Le Aziende designeranno l’aggiudicatario quale Responsabile del trattamento dei dati secondo quanto previsto dall’art. 28 del Regolamento Generale Europeo sulla protezione dei dati (UE) 2016/679 (di seguito GDPR), pubblicato in Gazzetta Ufficiale dell’Unione Europea il 27 aprile 2016 e dalla normativa vigente in materia, qualora lo stesso preveda di effettuare trattamenti di dati personali di provenienza delle Aziende del SSR anche al di fuori delle loro sedi.

19.2.4 ANAC ‌

Si intendono inclusi tutti i costi per mettere a disposizione, in formato aperto, tutti i dati dei gestionali e i dati immagine (o in generale DICOM) di modo che il prossimo aggiudicatario del servizio possa usufruirne.

ALLEGATO A: DIMENSIONAMENTO DELL’IMPIANTO PACS FVG ‌

1. Dimensionamento sedi e attività‌

Di seguito si riporta quello che è il dimensionamento attuale per le aziende relativamente a:

• Bacino di popolazione;

• Storage per le funzionalità PACS;

• Produttività giornaliera in termini di spazio occupato.

In giallo sono evidenziati i siti ad alta produttività propri di ogni azienda, oltre ai presidi HUB.

Architettura Aziendale del sistema PACS

1. 3 aziende, di cui 2 integrate con università

2. 2 IRCCS

Circa 1.500.000 esami/anno

ASUFC - Azienda Sanitaria Universitaria Friuli Centrale Bacino popolazione: 530 mila abitanti

Spazio storage occupato: 124 TB

Produttività: 80 GB/g (ultimo anno) su diversi siti:

1. HUB: Udine

2. Spoke: Xxxxxxxxx, Xxxxxxxx, Xxxxxxxx, Xxx Xxxxxxx xxx Xxxxxx, Xxxxxx

0. Altri siti territoriali: Tarcento, Cividale, Codroipo, Gervasutta, Udine San Valentino

ASUGI - Azienda Sanitaria Universitaria Xxxxxxxx Xxxxxxxx Bacino popolazione: 375 mila abitanti

Spazio storage occupato: 220 TB per 10 anni Produttività: 60 GB/g su diversi siti:

1. HUB: Xxxxxxx Xxxxxxxx xx Xxxxxxxxx

0. Spoke: Xxxxxxx Xxxxxxxx Xxxxxxxx

0. Spoke: Gorizia

4. Spoke: Monfalcone

ASFO - Azienda Sanitaria Friuli Occidentale Bacino popolazione: 313 mila abitanti Spazio storage occupato: 95 TB

Produttività: 59 GB/g (ultimo anno) su diversi siti:

1. HUB: Pordenone

2. Spoke: San Xxxx al Tagliamento, Spilimbergo

3. Spoke: Sacile, Maniago, Aviano (cardiologia)

IRCCS CRO Aviano

Spoke senza cache: Pordenone (medicina nucleare) Spazio storage occupato: 23 TB

Produttività: 16 GB/g (ultimo anno)

IRCCS Burlo Trieste

Spazio storage occupato: 12 TB Produttività: 3 GB/g (ultimo anno)

2. Dimensionamento erogazione CD Paziente‌

Soluzione da consolidare in un centro per sede.

Azienda	Presidio	Produzione annua media CD/DVD	N. unità di masterizzazione
ASUGI	Gorizia	26.200	2
ASUGI	Xxxxxxxxxx	00.000	2
	Pordenone	35.000	4
ASFO	San Xxxx	16.000	2
	Spilimbergo	15.400	2
ASUFC	Codroipo	6.000	2
	Gemona	15.400	2
	San Xxxxxxx	19.000	2

	Xxxxxxxx	00.000	2
	Gervasutta	8.200	2
	Udine	55.600	(da suddividere in 3 padiglioni) 8
	Latisana	24.200	2
	Palmanova	18.000	2
	Cividale	Inclusa in Udine	2
BURLO	Burlo	6.700	2
CRO	CRO	14.300	2
TOT		300.000	40

Azienda	Gruppo Erogatore	LUN	MAR	MER	GIO	VEN	SAB	DOM
	Cattinara Gastro	12	12	13	13	12	1
	Cattinara Gastro2	11	15	13	13	10
ASUGI		104	108	111	107	108	2	2
	Cattinara Radiologia	4	4	4	4	4	3	2
	CCV	1	2	2	4	2
	CCV	3	2	3	3	2
	CIEU	5	3	6	6	3
	CIEU	1		2	1	2
	Ecocardiografia	1	2	2	1	1
	Ecocardiografia	2	2	2	5	3		1
	EMODINAMICA	18	19	18	16	16	3
		122	120	120	120	113	2	2
	Maggiore Radiologia	4	4	6	4	4	2	1
	Medicina Nucleare	26	24	22	27	21	1	2
	Medicina Nucleare	2	3	2	2	1
	Odonto	2	2	2	2	1	1
	PNEUMOLOGIA	1
I valori si riferiscono alla produzione media giornaliera di CD/DVD per sito di stampa dell’Area Giuliana

3. Dimensionamento hardware in gestione ‌

Dal punto di vista logistico, l’hardware specialistico oggetto dei servizi è distribuito sulle diverse postazioni di lavoro, che possono essere riassunto secondo la presente tabella:

Asset	ASFO	ASUFC	BURLO	CRO	ASUGI ISONTINA	ASUGI GIULIANA	Totale
WSD-ELA/CONS-A - Stazioni di valutazione clinica o terapeutica	3	6			2	66	77
WSD-REF-A1 - Stazioni di refertazione mammografica	3	6		2	2	3	16
WSD-REF-A3 - Stazioni di refertazione diagnostica	39	77	6	16	18	53	209
WSD-TECNICI - Stazioni clinico/amministrative	2	18		3	3	3	29

Mentre dal punto di vista del dettaglio, gli asset trovano rappresentazione nella seguente tabella:

Xxxxxx	ASFO	XXXXX	XXXXX	XXX	ASUGI ISONTINA	ASUGI XXXXXXXX	Totale complessivo
Comped Client	4	4	13	12	18	150	201
Estensa 3Mensio Radiology	31	80	10	16	16	35	188
Estensa 3Mensio Vessel Analysis			3			3	6
Estensa Cardio Client CATHLAB	4	6				25	35
Estensa Cardio Client US	11		2		4	12	39
Estensa Clinical	2	18		3	3	52	78
Estensa OR	10	37	1	4	11	21	84
Estensa Radio Client	31	80	16	16	16	61	220
Estensa Radio MG Client	3	6		2	2	4	17
Hermes Client		4		4		3	11
Orthoview Client	3	6			2	2	13
Terarecon Intuition Client	1	1		1	1	3	7
Circle CVI subscription						2	2

Server SUITESTENSA Cache	5	11		1	1	4	22
Server SUITESTENSA DPA	1	1	1	1	1	1	6
Server SUITESTENSA Mobile	0	0	0	0	0	0	0
Server SUITESTENSA modulo CIS	1	1				1	3
Server SUITESTENSA modulo RIS			1	1	1	1	4
Server SUITESTENSA PACS Centrale	1	1	1	1	1	1	6
Terarecon Intuition Server	1	1		1	1	1	5

Eizo Radiforce GX550					2		2
Eizo Radiforce GX560	6	12		4	2		24
Eizo Radiforce RX350		18	2		5		25
Eizo Radiforce RX360	84	145	13	32	35		309
Barco Coronis Fusion MDCC-6430						1	1
Barco Coronis MDMG-5121						2	2
Barco Nio Color MDNC-2221						20	20
Barco Nio Color MDNC-3421						25	25
Barco Nio MDNG-5221						4	4

Barco Eonis MDRC-2324

Barco Eonis MDRC-2224

Monitor da visualizzazione per S.O.

ACL OR MD 27

ACL OR MD 42

FSB600HD 42"

NDS RADIANCE 26"

WSD-VISU-C-Fissa

WSD-VISU-C-Mobile

Stazioni di sala operatoria 42'' FISSE

4. Indicazioni sulle funzionalità esistenti ‌

Nella tabella seguente si indicano le principali funzionalità presenti nel sistema PACS oggi in essere, così come implementate attraverso gli asset di proprietà già indicati.

Esempio delle principali funzionalità del sistema in essere

Prodotto

Sintesi esemplificativa delle funzionalità in essere, tutte integrate con il SIO

Hermes

• Elaborazione quantitativa dei dati/immagini di Medicina Nucleare

Estensa Radio

• visualizzazione ed elaborazione delle immagini US, RX, TAC, RM, Mammografiche, Ecografiche e in generale degli oggetti DICOM

• integrazione di front end con il sistema G2

• visualizzazione simultanea di più esami e confronto con i precedenti

• regolazione dinamica e in tempo reale dei parametri soglia/finestra

• regolazione dinamica dello zoom

• strumenti di rotazione, pan e flip delle immagini

• definizione di profili utente personalizzabili

• strumenti di composizione dell’area e del formato di stampa

• strumenti di annotazione

• misurazione avanzata delle immagini, compresa calibrazione, distanze e angoli

• funzionalità dedicate per mammografia

Estensa in versione Operating Room

• gestione e visualizzazione delle immagini radiologiche in sala operatoria

• Hanging protocol specializzati per la visualizzazione in sala operatoria

Gestione imaging 3D integrata al viewer PACS

- 3Mensio radio

- 3Mensio vascular

• 3D MIP/MPR lineare e curva con 3D e segmentazione integrata con il viewer PACS base

• Funzionalità di gestione 3D vascolare

• Funzionalità di pianificazione preoperatoria vascolare

• Individuazione dello stent dal catalogo

• Simulazione dell’applicazione

• Rendicontazione

Terarecon Intuition

• Vedi nota a fine tabella

Gestione magazzino Radiologia

Interventistica

• Gestione del magazzino integrata con la refertazione radiologica della procedura

Refertazione Radiologica

• modulo di refertazione documentale radiologica/medicina nucleare integrato con il viewer Estensa Review con funzionalità di report manager integrato al RIS G2

• implementa funzionalità di refertazione dettata e strutturata

Orthoview (preoperatorio)

• Pianificazione preoperatoria ortopedica:

• Individuazione protesi corretta dal catalogo

• Simulazione dell’applicazione

• Simulazione della riduzione di frattura

Circle CVI

• Valutazione automatica della funzionalità cardiaca da RM

• Evolve 2 seat 1 Cardiac MR + 1 Strain, modificabili fino a 15/11/2025

Server PACS Image Manager/Archive

• Archiviazione di ogni classe DICOM

• Applicazione profilo IOCM

• Applicazione della modifica dato imaging alla riconciliazione dello studio fuori flusso alla corretta prestazione

• Autorouting verso destinazioni multiple

• QIDO-RS e WADO-RS compatibili con IHE MobileAccessToImaging,

• Implementazione profili SWF.v2, EBIW, ATNA

Server Estensa	• ospita i servizi centralizzati di configurazione e integrazione al servizio degli applicativi verticali sopra citati
Server PACS Scientifico	• Possibilità di esportazione in DICOM e JPEG di immagini, video o studio anonimizzati
Server Estensa Web	• Distribuzione ai reparti con 3D e collaborazione
Server per controllo qualità monitor medicali	• Applicazione software in grado di verificare l’operatività dei display in manutenzione, eseguire l’inventario, alcuni test e valutare l’invecchiamento dei singoli device
Estensa web FSEO	• Accesso alle immagini dei repository aziendali dall’istanza di FSE Operatore regionale, da fruirsi sull’applicazione in uso dal professionista (Diagnostica piuttosto che di valutazione clinica – Estensa Review piuttosto che Estensa Web)
Licenza server Suite Estensa Portal	• applicativo per la distribuzione al cittadino, online, del CD Paziente, integrato al FSE Cittadino. Permette lo scarico delle immagini ISO del CD paziente per tutti i casi regionali nei 35 giorni successivi all’esecuzione dell’esame
Visore cd paziente	• È disponibile un viewer dicom medicale installabile, senza limitazioni di numerosità sui PC aziendali del SSR (circa 20K), in maniera automatizzata e massiva allo scopo di visualizzare con uno strumento unico di cd paziente esterni in ogni PC dell’Azienda sanitaria

** per i moduli terarecon:

Area Giuliana:

Elenco moduli

1. Analisi vascolare

2. Valutazione calcio coronarico

3. Perfusione cerebrale TAC e RM

4. Analisi funzionale cardio TAC

5. Analisi e monitoraggio polmonare con identificazione automatica lesioni

6. Sottrazione TAC/CTA

7. Analisi dentaria

8. Navigazione virtuale colon con identificazione automatica delle lesioni

9. Fusione studi funzionali e anatomici

10. Analisi RM mammo Tutte licenze CUDA

Numerosità: 3 utenti concorrenti per 6000 slice. FVG oltre Area Giuliana

Numerosità:

Terarecon in FVG utilizza un licensing per slice contemporaneamente dagli utenti su ogni sistema server, con una logica sistema master\slave.

I server slave sono presenti presso i principali presidi e gestiscono i client asserenti la stessa

azienda. Quando un server SLAVE “termina” le slice a disposizione le “ruba” dal server MASTER

MASTER centrale FVG in housing Insiel	9000
SLAVE ASUFC	15000
SLAVE ASUGI GO	6000
SLAVE ASFO	12000
SLAVE CRO	3000
Elenco moduli:

1. Analisi vascolare

2. Analisi e monitoraggio polmonare con identificazione automatica lesioni

3. Analisi RM mammo

4. Navigazione virtuale colon con identificazione automatica delle lesioni

5. Fusione studi funzionali e anatomici

6. Analisi funzionale cardio TAC

Il sistema dispone poi di uno strumento (oggi una versione di Estensa ‘light’, senza necessità di configurazione per l’installazione) che permette – su richiesta dello specialista ai sistemi informativi aziendali – di ottenere sul proprio PC un viewer DICOM, dispositivo medico adatto dalla

decisione clinica e distribuito via Microsoft Intune, con esperienza utente coerente con l’Universal VIewer del sistema PACS REgionale e funzionale a soddisfare il bisogno di visualizzare il contenuto DICOM della moltitudine di CD Paziente portati dai pazienti in visione. Il viewer non ha integrazioni con il resto del sistema, ma è gestito alla stessa maniera, ovvero ne viene mantenuta la sicurezza, la funzionalità e l’appropriatezza al caso d’uso da parte dell’aggiudicatario. Il numero di installazioni possibili è illimitato.

ALLEGATO B: PRINCIPI DI INTEGRAZIONE NEL SISTEMA INFORMATIVO OSPEDALIERO FVG ‌

Il sistema PACS FVG, dal punto di vista dell’integrazione delle proprie componenti software con il Sistema Informativo Sanitario della Regione FVG - gestito per suo conto da Insiel S.p.A. - è e sarà orientato alla massima aderenza agli standard internazionali e alle best practice.

Il sistema è order e document driven, per l’accesso alle immagini, e utilizza un unico image archive logico per ogni disciplina clinica all’interno dell’Azienda Sanitaria.

Sono previsti tre scenari:

● verticale su reparto produttore di immagini;

● verticale su reparto che aggiunge immagini fatte da altro reparto (caso d’uso terapeutico);

● visualizzazione immagini da reparto.

Il documento prodotto nei primi due scenari previsti deve necessariamente rispettare quanto disposto con le linee guida nazionali Fascicolo Sanitario Elettronico 2.0, nello specifico nelle modalità e metodiche utilizzate per la creazione dei referti, controllo e validazione. Il tutto tenendo in considerazione quanto indicato nelle specifiche di HL7 Italia, consultabili al link xxxx://xxx.xx0xxxxxx.xx/xx0xxxxxx_X0/xxxx/0000 .

Di seguito gli schemi relativi agli scenari con le indicazioni delle transazioni previste.

Quasi tutte le transazioni sono standard, tranne alcune che utilizzano metodologie standard, ma con parametri particolari.

‌

4. Transazioni‌

Di seguito l’elenco delle transazioni riportate negli schemi:

ORDINE (1):

Transaction:

Transaction RAD-2 (Placer Order Management) of the IHE Technical Framework.

Protocol:

HL7 ORM message v. 2.3.1.

PROCEDURE SCHEDULED/UPDATE/CANCEL (2)

Transaction:

Transaction RAD-4 (Procedure Scheduled) of the IHE Technical Framework. Transaction RAD-13 (Procedure Update) of the IHE Technical Framework.

Protocol:

HL7 ORM message v. 2.3.1.

WORKLIST (3)

Transaction:

Transaction RAD-5 (Query Modality Worklist) of the IHE Technical Framework.

Protocol:

DICOM PS 3.4: Modality Worklist SOP Class.

STORE/S.C (4)

Transaction:

Transaction RAD-10 (Storage Commitment) of the IHE Technical Framework.

Protocol:

DICOM PS 3.4: Storage Commitment Push Model SOP Class.

MPPS (5)

Transaction:

Transaction RAD-6 (Modality Procedure Step In Progress) of the IHE Technical Framework.

Transaction RAD-7 (Modality Procedure Step Completed/Discontinued) of the IHE Technical Framework.

Protocol:

DICOM PS 3.4: Modality Performed Procedure Step SOP Class.

XXX (6)

Transaction:

Transaction RAD-49 (Instance Availability Notification) of the IHE Technical Framework.

Protocol:

DICOM PS 3.4: Instance Availability Notification Service Class.

EROGATO (7)

Transaction:

Transaction RAD-3 (Filler Order Management) of the IHE Technical Framework.

Protocol:

HL7 ORM message v. 2.3.1.

WORK STATUS UPDATE (8)

Transaction:

Transaction RAD-42 (Performed Work Status Update) of the IHE Technical Framework.

Protocol:

DICOM PS 3.4: Modality Performed Procedure Step SOP Class.

DATI CLINICI (9)

Transaction:

Non IHE.

Trigger:

Richiesta da parte di un sistema esterno di registrare dei dati clinici (es. dati endoscopici,

dati di ecocardio o testo del referto) nella piattaforma d’integrazione SIO.

Expected:

I dati clinici provenienti dal sistema esterno vengono correttamente registrati nella

piattaforma d’integrazione SI.

Protocol:

HL7 ORU message v. 2.5 (dati endoscopici o testo del referto).

DICOM PS 3.3: Structured Report Document Information Object Definitions (dati di ecocardio).

MDM DOCUMENTO e KOS (10)

Transaction:

Non IHE.

Trigger:

Richiesta da parte di un sistema esterno di registrare un documento nel repository

documentale.

Expected:

Il documento viene correttamente registrato nel repository documentale.

Protocol:

HL7 MDM message v. 2.5.

ATTIVAZIONE CUP (11)

Transaction:

Non standard.

Trigger:

Richiesta di accesso all’applicativo CUP per modifica dell’ordine.

Expected:

Attivazione dell’applicativo in contesto.

Protocol:

Chiamata HTTP. PRECEDENTI (12)

Transaction:

Non standard.

Trigger:

Richiesta di visualizzazione dei precedenti per un paziente.

Expected:

Attivazione dell’applicativo Visore Referti e visualizzazione dei referti per un paziente.

Protocol:

Chiamata HTTP.

WADO (13)

Transaction:

Transaction RAD-55 (Wado Retrieve) of the IHE Technical Framework.

Protocol:

DICOM PS 3.18: Web Access to DICOM Persistent Objects (WADO).

IMG (14)

Transaction:

Non standard.

Trigger:

Richiesta di visualizzazione delle immagini.

Expected:

Apertura dell’applicativo di visualizzazione immagini.

Protocol:

Chiamata HTTP di applicazione locale e/o remota.

IMMAGINI (15)

Transaction:

Non standard.

Trigger:

Invio in conservazione dello studio, dopo un mese dalla sua produzione.

Expected:

L’Image Manager crea il pacchetto di versamento dello studio e lo invia alla Conservazione. La Conservazione verifica la correttezza dei dati ricevuti:

- Se sono corretti, conserva il pacchetto e restituisce un esito SUCCESS.

- Se sono errati, restituisce esito FAILED e non conserva il pacchetto.

Protocol:

Utilizzo di Web Services messi a disposizione dalla Conservazione. Il pacchetto viene salvato su un file system predefinito.

PIR (17)

Transaction:

Transaction ITI-30 (Patient Identity Management) of the IHE Technical Framework.

Protocol:

HL7 ADT message v. 2.5.

5. Servizio di conservazione legale ‌

Conservazione ‌

Il sistema di conservazione fornito nell’ambito dei servizi SIO è gestito da Insiel S.p.A. in-house della Regione FVG.

Il sistema di conservazione, con il quale l'impianto PACS e le sue funzionalità dovranno integrarsi garantisce la conservazione legale sostitutiva di quanto prodotto durante l’attività clinica nei due scenari descritti in precedenza (normale e terapeutico).

L’integrazione con il servizio verrà utilizzata sia per l’invio di quanto prodotto in conservazione, sia per attività di recupero di documentazione pregressa che ha superato il limite temporale di residenza nel sistema LTA.

Il servizio di conservazione prevede che l’attore Image manager, il PACS, mandi in conservazione gli studi (tutte le evidenze all’interno dello studio, anche successive all’attività di refertazione).

Il sistema richiede l’utilizzo di una coppia di credenziali per il sistema PACS, fornita dal sistema di conservazione, che potrà accedere all’area di interscambio, tramite protocollo SFTP.

Il processo si articola indicativamente nelle seguenti fasi:

− preparazione del pacchetto di versamento, fase in cui il servizio produttore deve creare l’insieme

dei documenti informatici da inviare al sistema di conservazione;

− invio del pacchetto di versamento, fase in cui il produttore si connette all’area SFTP nella quale deposita i documenti secondo modalità che verranno dettagliate in seguito, invocando il servizio di richiesta di conservazione;

− presa in carico del pacchetto di versamento, fase in cui il fornitore del servizio di conservazione

prende in carico i documenti e fornisce al produttore l’esito della richiesta;

− verifica dello stato di conservazione, il produttore tramite dei servizi può verificare lo stato di conservazione.

Restore ‌

Questa descrizione di massima del servizio prevede che il PACS (image manager) è il servizio che invia gli studi alla conservazione e che richiama il servizio di conservazione per effettuare il restore degli stessi.

Si considera che le richieste saranno di tipo asincrono e che dal momento della richiesta al restore effettivo dello studio possono essere necessarie alcune ore.

Sono previste una decina di richieste all’anno in media.

Descrizione del servizio

Il PACS contatterà un endpoint presente sullo stesso ambiente già utilizzato per l’invio delle immagini

in conservazione, utilizzando quindi le stesse credenziali che già dispone.

Il nuovo endpoint verrà utilizzato in due modalità:

1. Inserimento nuova richiesta di restore

2. Verifica stato richiesta di restore

La chiamata verrà elaborata differentemente in base alla presenza o meno del parametro idRichiesta, se presente si tratta di una richiesta di verifica dello stato.

Se si tratta di una nuova richiesta e se lo studio è effettivamente conservato verrà restituito il parametro idRichiesta utilizzabile per verificare lo stato della richiesta di restore.

Una volta che lo stato si troverà in una situazione di elaborato con successo il PACS accederà alla sua area su server SFTP, con le credenziali di cui già dispone e all’interno della cartella restore potrà recuperare lo studio richiesto. Sarà onere del PACS cancellare lo studio dal server SFTP una volta scaricato e riportato all’archivio corrente.

6. Adesione ai profili dell’iniziativa Integrating the Healthcare Enterprise ‌

Il sistema implementa i seguenti profili/attori:

PROFILO	ATTORE	Note
Patient Information Reconciliation	Image Manager/Archive Performed Procedure Step Manager Report Manager
Scheduled Workflow(.b)	Image Manager/Archive Performed Procedure Step Manager Order filler Image Display Evidence Creator	Evidence creator per il terapeutico
Mammography Acquisition Workflow	Image Manager/Archive Performed Procedure Step Manager
Cath Workflow	Image Manager/Archive Performed Procedure Step Manager
Echo Workflow	Image Manager/Archive Performed Procedure Step Manager
Stress Testing Workflow	Image Manager/Archive Performed Procedure Step Manager
Post-Processing Workflow	Image Manager/Archive Post-Processing Manager
Reporting Workflow	Image Manager/Archive Report Manager
Mammography Image	Image Manager/Archive
NM Image	Image Manager/Archive
Consistent Presentation of Images	Image Manager/Archive
Image Fusion	Image Manager/Archive
Evidence Documents	Image Manager/Archive
Cardiology Evidence Documents	Image Manager/Archive
Key Image Note	Image Manager/Archive Evidence Creator

Simple Image and Numeric Report	Report Repository
Access to Radiology Information	Report Repository Image Manager/Archive
Cross-Enterprise Document Sharing (XDS.b)	Document Repository Document Source
Cross-enterprise Document Sharing for Imaging (XDS-I.b)	Imaging Document Source Imaging Document Consumer
Audit Trail and Node Authentication	Secure Application AR repository AR Forwarder
Consistent Time	Time Server Time Client
Mobile access to health documents	Document Source Document Recipient Document Consumer Document Responder	Oggetto di manutenzione adeguativa
Imaging Object Change Management (IOCM)	Image Manager
Import Reconciliation Workflow (IRWF)	Image Manager/Archive Importer Order Filler Performed Procedure Step Manager
Teaching File and Clinical Trial Export (TCE)	Group actors Export Selector Group actors Export Manager Group actors Receiver	Oggetto di manutenzione adeguativa
Presentation of Grouped Procedures (PGP)	Image Manager/Archive	Registrazione

ALLEGATO C: SPECIFICHE IT DI DETTAGLIO PER L’EROGAZIONE DEL DEL SERVIZIO ‌

Di seguito vengono definite le specifiche che i sistemi forniti dovranno rispettare relativamente ad aspetti della sfera dell’IT (Information Technology). Qualunque elemento riportato in offerta tecnica dai partecipanti in contrasto o non in coerenza con i principi ed i contenuti di seguito riportati non avrà alcun valore contrattuale.

Il sistema nel suo complesso dovrà essere coerente con le politiche di sicurezza e di privacy della singola Azienda del SSR (di seguito Azienda) e più in generale dovrà funzionare nel rispetto delle norme di buona tecnica, delle “best practice”, dei regolamenti, delle norme tecniche e della legislazione vigente, in particolar modo in materia di sicurezza e privacy.

I sistemi forniti dovranno permettere all’Azienda di rispondere, per lo specifico dei sistemi offerti, a tutte le prescrizioni del complesso quadro normativo vigente.

Dal punto di vista della sicurezza, in primis dovrà rispondere a quanto richiesto:

- dal Regolamento Europeo sulla Protezione dei Dati – GDPR del 14.04.2016 (xxxxx://xxx- xxx.xxxxxx.xx/) e al D. Lgs. 196/2003 s.m.i., cosiddetto Codice Privacy, così come novellato dal D.Lgs. 101/2018; l’aggiudicatario verrà designato responsabile ex art.28 del GDPR e dovrà produrre ed attuare tutto quanto richiesto, per quanto pertinente prima del collaudo e per tutta la durata del contratto. Il modulo fac simile di designazione è riportato in allegato ed è parte integrante della documentazione di gara.

- dalla Circolare AGID 18 aprile 2017, n. 2/2017, recante “Misure minime di sicurezza ICT per le pubbliche amministrazioni”, con livello ALTO; inoltre l’aggiudicatario dovrà collaborare attivamente per quanto oggetto di fornitura alla produzione di documentazione che l’Azienda è chiamata a redigere in ottemperanza alla suddetta circolare AGID.

- dalla Determinazione AGID n. 220/2020 del 17/05/2020 “Adozione delle Linee Guida - La

sicurezza nel procurement ICT” e dalle Linee Guida allegate.

Dovranno, inoltre, rispettare le indicazioni AgID inerenti lo sviluppo e l’acquisizione di software e, in

particolare:

- il rispetto di quanto prescritto nelle “linee guida di sicurezza nello sviluppo delle applicazioni” AgID, anche dette “linee guida AgID per lo sviluppo sicuro del software”;

- la conformità alle regole sull’interoperabilità prescritte dalle linee guida emanate in attuazione dell’articolo 73 del CAD;

- la possibilità di esportare l’intera base di dati (inclusi di ogni tipo di indice o metadato utilizzato per implementare le funzionalità del software stesso) in formato standard e aperto, per scongiurare la possibilità di lock-in, come meglio specificato nelle linee guida n.8 di ANAC.

Qualora i sistemi forniti intendano essere collegati nella rete aziendale, essendo quest’ultima intrinsecamente una rete IT medicale secondo la norma IEC 80001-1, s’intende che il collaudo dell’intero sistema sarà condizionato alla redazione e sottoscrizione da parte del fornitore di un accordo di responsabilità (responsibility agreement) redatto secondo i dettami della stessa norma. Tale documento farà esplicito riferimento all’installazione dell’Azienda, nei modi e nei termini definiti dal presente documento e che verranno a presentarsi all’atto pratico dell’installazione e della manutenzione del sistema nel tempo. Il responsibility agreement, redatto dall’aggiudicatario e revisionato/validato dall’Azienda, conterrà espliciti riferimenti alla “marcatura CE” dei sistemi offerti ed al fatto che i requisiti essenziali di sicurezza non verranno inficiati nella particolare installazione dell’Azienda e nel tempo, così come intesa sopra.

Qualora i sistemi forniti non s’intendano collegati in alcuna maniera alla rete dati, essi devono comunque

rispondere ai requisiti dettati dalla normativa citata.

Se l’oggetto di fornitura include dispositivi medici, il fornitore dovrà compilare, sottoscrivere e allegare all’offerta tecnica il modulo Manufacturer Disclosure Statement for Medical Device Security (MDS2) versione 2019 per ciascuno di essi, in maniera da permettere all’Azienda una più agevole valutazione delle eventuali criticità della messa in uso dei sistemi offerti anche secondo EC/TR 00000-0-0. È comunque onere del fornitore verificare la versione più recente del modulo dal sito NEMA e compilare e fornire tale versione.

In caso di fornitura di dispositivi medici, inoltre, l’aggiudicatario con la partecipazione alla presente procedura di gara dichiara che le caratteristiche tecniche dell’infrastruttura IT descritte in capitolato e nel presente documento, sono adeguate ai dispositivi medici oggetto di fornitura, nei termini previsti dal Regolamento Europeo 2017/745 con particolare riferimento all’Allegato I – par. 17.4 (“I fabbricanti indicano i requisiti minimi in materia di hardware, caratteristiche delle reti informatiche e misure di sicurezza informatica, compresa la protezione contro l’accesso non autorizzato, necessari per far funzionare il software come previsto”).

Inoltre, sempre nel caso in cui l’oggetto di fornitura include dispositivi medici, il sistema fornito dovrà

rispondere a quanto richiesto:

- dal IHE Patient Care Device (PCD) White Paper, “Medical Equipment Management (MEM):

Medical Device Cyber Security – Best Practice Guide”;

- dalla linea guida “XXXX 0000-00 Guidance on Cybersecurity for medical devices”.

In generale l’aggiudicatario si assume la piena responsabilità della sicurezza informatica e nel trattamento dei dati affidato nell’ambito di quanto richiesto dalla presente procedura d’acquisto, in particolare in merito all’integrità, disponibilità e riservatezza dei dati e dei sistemi. Pertanto, anche nei casi in cui la sicurezza dei dati gestiti dai sistemi oggetto di fornitura possa essere legata agli effetti di altro hardware e software in gestione di altro soggetto, l’aggiudicatario rimane responsabile di monitorare tali elementi e segnalare in via formale qualora ritenga vi siano aspetti di inadeguatezza. In tale responsabilità ricade anche l’onere di richiedere gli strumenti per fare gli audit ed il monitoraggio, per eseguire le ricerche di anomalie, oltre alla comunicazione formale delle proposte percorribili per raggiungere gli obiettivi. Analogamente l’aggiudicatario accetta e collabora pienamente a qualsiasi attività di assessment e audit che l’Azienda o società da essa incaricate dovessero condurre sui sistemi oggetto di fornitura.

Il servizio oggetto di fornitura dovrà rispettare quanto riportato nel documento “Strategia Cloud Italia” (ultima release), realizzato dal Dipartimento per la trasformazione digitale della Presidenza del Consiglio dei Ministri; in particolare per i servizi SaaS la qualificazione dei servizi Cloud offerti dovrà essere coerente con la classificazione dei dati oggetto di trattamento (“ordinari”, “critici” o “strategici”) nell’ambito della presente fornitura.

I servizi SaaS forniti dovranno avere caratteristiche tecniche compatibili con tale modalità di erogazione in maniera nativa, ovvero dovranno essere SaaS by design. In tal senso, tra gli altri aspetti caratteristici del paradigma SaaS by design, i sistemi offerti dovranno essere progettati secondo l’architettura 3-Tier, ovvero con una separazione tra il livello di presentazione ed il livello applicativo, in modo che gli utenti finali non abbiano in alcun modo accesso diretto alle risorse al livello dati (a titolo di esempio non esaustivo, non dovrà essere necessario realizzare trust di dominio tra il dominio degli utilizzatori e il dominio del server, ovvero non dovrà essere necessaria alcuna interazione sistemistica finalizzata all’accesso diretto dell’utente finale ad eventuali risorse locali del server, che dovrà essere gestita in sicurezza tramite meccanismi strettamente applicativi, fermo restando le prescrizioni relative al Single Sign On così come di seguito descritte). I servizi SaaS offerti dovranno essere fruibili tramite collegamento internet e tramite i web browser in uso presso l’Azienda e senza alcun componente aggiuntivo sul browser stesso o sul client in generale; la sicurezza delle connessioni tra browser e servizi SaaS remoti dovrà essere adeguata alla tipologia di dati scambiati, in ogni caso dovrà essere adottato il protocollo HTTPS (TLS 1.2 o superiore – in ogni caso non deprecato – con certificato pubblico in gestione e a carico dell’aggiudicatario; tale certificato dovrà essere riconosciuto come valido dai browser di cui sopra, senza specifiche configurazioni, ovvero non dovranno essere usati certificati di tipo self-signed) e in alcun caso verranno realizzate connessioni VPN o di altro tipo ad hoc, (es. sistemi di

virtualizzazione applicativa o del desktop) per sopperire ad eventuali carenze architetturali in termini di sicurezza o funzionalità, ovvero i servizi dovranno sempre essere fruibili in maniera efficace e sicura tramite internet. I server che contengono i dati trattati di titolarità dell’Azienda dovranno risiedere all’interno della UE e per nessuna ragione dovranno essere effettuate copie di tali dati al di fuori del perimetro della UE, neppure per motivi di continuità di servizio e disaster recovery.

Relativamente al Single Sign On (SSO), dovrà essere utilizzato il sistema di autorizzazione/autenticazione offerto dalla piattaforma di interoperabilità di Insiel che a sua volta si avvale degli endpoint ADFS Aziendali.

Nello scenario SaaS potranno essere forniti, se indispensabili per gli scopi della presente fornitura, anche specifici dispositivi connessi anch’essi con i servizi SaaS. Tale connettività verrà garantita unicamente per mezzo di connessione cablata alla rete LAN dell’Azienda e secondo le modalità descritte di seguito.

Inoltre, sempre in coerenza con quanto stabilito da AGID, i sistemi forniti dovranno essere progettati, realizzati ed installati in modo da minimizzare fenomeni di lock-in e in ogni caso, durante gli ultimi due trimestri di durata del contratto ed eventualmente per i tre mesi successivi, e comunque fino al raggiungimento dell’obiettivo, l’aggiudicatario dovrà favorire in ogni modo il travaso e la fruizione dei dati verso sistemi di terze parti, il che sarà vincolate al pagamento delle ultime due fatture. Tali attività ed i servizi professionali e tecnici associati sono perciò da intendersi oggetto di fornitura del presente contratto.

In generale per l’analisi preliminare e l’avviamento all’uso dei sistemi oggetto di fornitura l'Azienda metterà a disposizione 5 giornate uomo di tecnico sistemista senior e 5 giornate uomo di project manager. La mancanza di autonomia operativa da parte dell’aggiudicatario o particolari necessità di assistenza svolta da personale dell’Azienda, che vadano oltre i limiti sopra riportati, verranno computati dall’Azienda che si riserva la facoltà di quantificare le relative spese in base al listino allegato alla Convenzione Consip “Servizi di System Management” e di chiederne la deduzione al committente dal piano di fatturazione previsto. Con la partecipazione alla gara si intende accettato tale meccanismo compensativo.

Specifiche di integrazione con l’infrastruttura IT

I sistemi oggetto di fornitura dovranno essere integrati ed interfacciati con l’infrastruttura informatica di

rete e sistemistica dell’Azienda, secondo quanto riportato nel seguito.

I dispositivi dotati di connettività di rete (host) che necessitano di collegamento alla rete dati per svolgere le funzioni richieste, potranno essere inseriti nella LAN dell’Azienda seguendo lo scenario descritto nel seguito.

In particolare, gli host oggetto di fornitura saranno integrati nella sola infrastruttura di rete dell’Azienda e saranno oggetto di policy di segmentazione e segregazione del traffico. La segmentazione del traffico verrà effettuata assegnando agli host stessi una specifica classe di indirizzi IP statici (se il numero di host complessivi afferenti alla rete assegnata è minore di 50) o dinamici (se il numero di host complessivi afferenti alla rete assegnata è maggiore di 50) coerente con il piano di indirizzamenti aziendale e verranno inseriti in una VLAN dedicata, assegnata dall’Azienda, dalla quale potranno effettuare solo l’eventuale traffico necessario per svolgere le funzioni richieste in capitolato e l’eventuale traffico relativo all’assistenza remota da parte del fornitore. La segregazione del traffico verrà garantita tramite opportune ACL (Access Control List) o configurazioni sui firewall aziendali (ISFW – Internal Segregation Firewall), stilate per rete IP e per porta, o per protocollo o altro filtro intelligente, sulla base delle sole effettive necessità di traffico per svolgere le funzioni richieste in capitolato. Il fornitore dovrà garantire piena collaborazione nella redazione di tali ACL e/o regole sui firewall aziendali (ISFW – Internal Segregation Firewall), per una durata complessiva di almeno un giorno lavorativo uomo e comunque fino al raggiungimento del risultato atteso. In ogni caso il traffico sarà consentito solo dalla periferia al centro e non da periferia a periferia, in particolare la rete IP/VLAN assegnata non avrà in alcun caso visibilità di rete sulle reti IP/VLAN dei PC in dominio aziendale o altra rete comprendente host non in gestione. L'azienda si riserva di assegnare una o più reti IP/VLAN all’aggiudicatario in base alla specifica architettura proposta.

È attivo sulla LAN un sistema di autenticazione degli host di rete basato su protocollo IEEE 802.1x e realizzato per mezzo di tecnologia Microsoft NPS. Tutti gli host forniti e collegati alla LAN dell’Azienda dovranno essere tali da consentire l’autenticazione di rete tramite MAC address (cosiddetta MAC authentication). A titolo di esempio non esaustivo, l’autenticazione avviene solo a seguito di traffico effettuato a partire dall’host che dovrà essere in tal senso caratterizzato/configurato.

I collegamenti cablati dovranno essere realizzati con un adeguato grado di resistenza meccanica, nel caso per esempio dei dispositivi palmari o mobile, dovrà essere fornita una docking station e non saranno consentiti adattatori stand-alone di alcun tipo (ad esempio adattatori USB-RJ45). I dispositivi di tipo palmare e mobile dovranno essere specificatamente previsti dal fabbricante per uso in ambienti sanitari e locali ad uso medico (secondo la CEI 64-8/7), se del caso, ovvero rispondenti ai seguenti requisiti: rispondenza alle norme IEC 60601-1, grado di protezione IP pari almeno ad IP54; certificazione per resistenza alle cadute da 1 metro di altezza (per esempio secondo MIL-STD-810F/G); involucro/custodia certificato sanificabile, privo di spigoli (seamless) e realizzato in materiale antibatterico/antimicrobico soprattutto in relazione a MRSA. Le attività svolte dagli operatori dell’Azienda su tali dispositivi dovranno essere garantite dal fornitore con la migliore operatività in termini di facilità d’uso ed efficacia, in particolare per i dispositivi mobile i servizi dovranno essere resi disponibili dal fornitore per mezzo di specifiche applicazioni (non sarà consentito l’uso di applicazioni web su dispositivi mobile) e tali applicazioni dovranno essere pensate anche per l’uso off-line, data la necessità di avere connettività esclusivamente cablata di cui sopra.

Per le eventuali attività di assistenza remota, effettuate nel corso della durata del contratto dagli amministratori di sistema formalmente nominati dall’aggiudicatario, la connettività agli host oggetto di assistenza sarà garantita esclusivamente per mezzo dei sistemi VPN aziendali, su cui la modalità Split Tunnel è per policy sempre disattivata. L’accesso verrà consentito solo a seguito di domanda sottoscritta digitalmente dal legale rappresentante o procuratore protempore dell’aggiudicatario – compilando il modulo standard aziendale – ed inviata da casella PEC all’indirizzo PEC Aziendale, con allegati i documenti di identità e CF in corso di validità dei soggetti da abilitare. La connessione VPN dovrà essere di tipo client-to-site ed effettuata per mezzo di credenziali personali con bassi privilegi (livello user), ed in alcun caso saranno consentite connessioni di tipo site-to-site. Nel presente scenario, a valle dell’instaurazione della connessione VPN, il collegamento ai singoli host oggetto di assistenza dovrà avvenire esclusivamente con gli strumenti scelti dall’aggiudicatario, sempre e comunque con modalità rispondenti al quadro legislativo e normativo vigente, solo a valle di validazione degli strumenti stessi da parte dell’Azienda. Il servizio di connessione remota VPN non verrà prestato all’aggiudicatario con livelli di servizio garantiti; perciò, il servizio offerto dovrà essere organizzato in modo da sopperire all’indisponibilità del servizio VPN in altro modo (per esempio con intervento sul posto o altri sistemi di allarme e sicurezza), senza inficiare i livelli di servizio offerti né la sicurezza degli stessi, o evidenziando in offerta i livelli di servizio in caso di indisponibilità del servizio VPN.

Per quanto riguarda le eventuali attività di telemonitoraggio continuo da internet degli host oggetto di assistenza, nel presente scenario, lo strumento messo a disposizione da dalle Aziende è il firewall di navigazione gestito dalla società in house della Regione Autonoma Friuli Venezia Giulia denominata Insiel SpA: gli host forniti potranno raggiungere solo un numero limitato di destinazioni internet, su specifiche porte; in ogni caso il traffico consentito sarà quello minimo necessario per il funzionamento dei sistemi e non sarà consentita la navigazione internet nonché l’esfiltrazione di dati tramite questo canale. Verranno perciò effettuate specifiche abilitazioni basate su IP sorgente, IP destinazione e porta solo a seguito di domanda sottoscritta digitalmente dal legale rappresentante o procuratore protempore dell’aggiudicatario – compilando il modulo standard Aziendale – ed inviata da casella PEC alla casella PEC aziendale. L’aggiudicatario dovrà fornire la massima collaborazione in tal senso all’Azienda per la definizione delle suddette abilitazioni. Nel presente scenario, la risoluzione dei nomi sarà basata esclusivamente su uno specifico servizio DNS (Domain Name Service) dedicato a tutti i dispositivi segregati/isolati presenti sulla rete aziendale, compresi quelli oggetto di fornitura. Analogamente al servizio VPN di cui sopra, anche il servizio di connettività in uscita tramite firewall di navigazione Insiel non verrà prestato all’aggiudicatario con livelli di servizio garantiti, perciò il servizio offerto dovrà essere organizzato in modo da sopperire all’indisponibilità del servizio in altro modo (per esempio con intervento sul posto o altri sistemi di allarme e sicurezza), senza

inficiare i livelli di servizio offerti né la sicurezza degli stessi, o evidenziando in offerta i livelli di servizio in caso di indisponibilità del servizio.

L’aggiudicatario sarà responsabile in toto delle prescrizioni di ambito sicurezza informatica e privacy, secondo quanto previsto dal quadro legislativo e normativo vigente, nonché dal presente documento; in particolare per quanto riguarda le politiche: di autenticazione, autorizzazione e accounting (AAA), di backup e disaster recovery, sugli aggiornamenti di sicurezza di tutti i software installati sugli host oggetto di assistenza, di protezione antivirus e da altre tipologie di cyber attacco.

Per quanto riguarda i sistemi operativi server, gli oneri di licenza e di qualunque altro tipo, diretti e indiretti, finalizzati al corretto e sicuro funzionamento del sistema oggetto di fornitura saranno completamente a carico dell’aggiudicatario, come pure l’onere della continua verifica nei dizionari di vulnerabilità internazionali (al minimo dovrà essere monitorato CVE - Common Vulnerabilities and Exposures) dei sistemi operativi in uso e di qualunque altra componente software fornita od installata dall’aggiudicatario, nonché la sostituzione immediata ed incondizionata dei sistemi operativi stessi in caso di criticità contrassegnate con livello maggiore o uguale al range “6-7”.

Si specifica infine che sono da intendersi oggetto di fornitura eventuali PC client ed eventuali server fisici che si rendessero necessari, nonché tutto l’hardware di tipo IT necessario al corretto e sicuro funzionamento dei sistemi oggetto di fornitura.

Nel caso in cui le applicazioni fornite dall’aggiudicatario fossero rispondenti alle specifiche del paradigma SaaS e del SSO basato su protocollo SAML, così come descritte all’inizio del presente documento, l’aggiudicatario stesso potrà proporre in offerta tecnica di utilizzare le applicazioni offerte sui PC client aziendali standard (postazioni di lavoro aziendali). In tal caso non sarà necessaria la fornitura dei PC client dedicati da parte dell’aggiudicatario. l'Azienda, tuttavia, si riserva di verificare gli estremi ed i dettagli tecnici della proposta e si riserva di rifiutarla a suo insindacabile giudizio. In tal caso l’aggiudicatario dovrà comunque fornire tutti i PC client necessari.

Gli eventuali server forniti dovranno, inoltre, essere del tipo da installazione da rack standard 19” con una occupazione massima di 2 rack unit (a meno di documentata necessità) e dotati di doppio modulo di alimentazione integrato.

Inoltre, tali server non dovranno/potranno per alcun motivo essere utilizzati dagli operatori come stazioni di lavoro.

Specifiche tecniche di sicurezza informatica

Di seguito vengono definite le specifiche che i sistemi forniti dovranno rispettare, sia nel caso di non collegamento in rete, sia nello scenario descritto nel presente documento, relativamente ad aspetti generali della sfera dell’IT (Information Technology) con particolare riferimento alla sicurezza informatica (security).

Vale in ogni caso il principio generale per cui la sicurezza informatica è un fattore intrinseco dell’architettura dei sistemi oggetto della presente fornitura e delle caratteristiche tecniche degli elementi che li compongono; perciò l’aggiudicatario dovrà garantire che, sia l’architettura che gli elementi, siano progettati, implementati e manutenuti nel tempo in modo da minimizzare il rischio informatico residuo (sia di “attacchi ai sistemi” che di “attacchi dai sistemi”) e comunque in osservanza delle normative e best practice già citate dal primo paragrafo del presente documento e sempre in coerenza con il paradigma “Zero Trust”.

Verranno eseguite periodicamente dall’Azienda o da personale a tal scopo incaricato procedure di Vulnerability Assessment e Penetration Test e l’aggiudicatario si impegna pertanto a risolvere criticità o vulnerabilità che dovessero in tal modo emergere. Analogamente l’aggiudicatario si impegna a collaborare con il SOC (Security Operation Center) aziendale per il miglioramento continuo dei sistemi forniti.

Inoltre, i sistemi forniti dovranno rispettare le seguenti prescrizioni.

In generale, tutti gli elementi forniti non dovranno essere in alcun caso fuori supporto tecnico del fabbricante o a fine ciclo di vita (end-of-life) e comunque non dovranno trovarsi in tale stato per tutta la durata contrattuale.

In generale, tutti i software forniti dovranno essere:

− coerenti con la necessità di richiedere applicazioni, servizi e procedure privacy by design e privacy by default per ogni percorso di trattamento. Tutti i sistemi devono essere costruiti per proteggere i dati trattati e farlo come impostazione predefinita. L’aggiudicatario è tenuto a fornire documentazione delle misure implementate anche allo scopo di permettere le necessarie valutazioni al Titolare;

− intuitivi e di facile utilizzo, ad ogni livello di accesso ed in ogni configurazione, per tutti gli operatori (a prescindere dal ruolo);

− dotati di impostazioni internazionali di Microsoft Windows (se presente) IT standard, comprese le tastiere, allo scopo di non incorrere in nessun caso in errori nelle date, nei dati numerici e nei dati personali locali;

− stabili, in particolare che siano in grado di gestire le eccezioni;

− sicuri, sia dal punto di vista della sicurezza informatica che della qualità delle funzioni svolte;

− ottimizzati, in termini di rapporto tra uso delle risorse e prestazioni;

− sviluppati tenendo conto dei principi del “ciclo di vita del software” e dell’“analisi del rischio”, secondo le norme tecniche (o principi e metodologie almeno equivalenti) e le best practice internazionali; in ogni caso non dovranno utilizzare librerie deprecate e/o obsolete, né dovranno essere scritti e sviluppati con versioni del linguaggio di programmazione fuori supporto tecnico del fabbricante o a fine ciclo di vita (end-of-life) e comunque non dovranno trovarsi in tale stato per tutta la durata contrattuale;

− pensati, progettati e realizzati nel rispetto del quadro legislativo vigente, nonché in modo da non mettere in alcun caso gli operatori in condizione di violare il quadro legislativo stesso nell’espletamento del normale utilizzo dei sistemi;

− installati e configurati per essere utilizzati, in condizioni di massima sicurezza e funzionalità, nello specifico contesto dell’Azienda, così come descritto nel presente documento;

− manutenuti e gestiti in modo da conservare e mantenere stabili nel tempo tutte le caratteristiche possedute al momento del collaudo definitivo.

In particolare, tutti i software forniti che verranno installati su dispositivi collegati alla LAN e inseriti nel dominio xxxxx.xx, dovranno essere eseguiti sempre:

− in un contesto user space per i client,

− come servizio per tutti i server,

− come servizio per i client se non è richiesta interazione con l’operatore,

ed in ogni caso non dovranno essere modificati in alcun modo i permessi di default del file system e del registro di sistema Microsoft (ove presente).

In particolare, per quanto concerne le configurazioni:

− quelle degli applicativi server dovranno risiedere in database e comunque mai sui dischi locali dei PC client;

− quelle globali degli applicativi client (ovvero non riferite alle personalizzazioni dei singoli account) dovranno risiedere in un file nella cartella di installazione dell’applicativo (a cui quindi avranno accesso solo gli utenti con ruolo Amministratore) oppure nella cartelle

%HOMEDRIVE%\ProgramData, oppure nel registro di sistema (ove presente) nella sottochiave

informazioni critiche in termini di sicurezza e funzionalità (a titolo di esempio non esaustivo: le stringhe di connessione ai database, le credenziali necessarie per instaurare eventuali altre connessioni client/server, ecc.) dovranno essere cifrate almeno con algoritmo AES256;

− quelle personali degli applicativi client (ovvero riferite alle personalizzazioni dei singoli account)

dovranno risiedere nel profilo dell’account a cui si riferiscono (ove presente).

Ovvero, in ogni caso non dovranno risiedere configurazioni globali degli applicativi client nei profili degli account, né altresì configurazioni personali degli applicativi client fuori dai profili degli account.

In particolare, a titolo esemplificativo e non esaustivo, si ricorda che, anche nel perimetro delle prescrizioni previste dalla Circolare AGID 18 aprile 2017, n. 2/2017, recante “Misure minime di sicurezza ICT per le pubbliche amministrazioni”, i sistemi forniti:

- non devono prevedere nessun account locale;

- non devono prevedere nessun account impersonale per gli operatori e account di servizio solo se del tipo gMSA, group Managed Service Account;

- devono consentire azioni di software inventory;

- devono poter essere distribuiti in “package” fruibili dai sistemi di distribuzione aziendali;

- devono utilizzare solo sistemi di comunicazione sicuri (crittati);

- devono rispettare le tecnologie di protezione delle banche dati di dati personali e sensibili;

- devono consentire le valutazioni di vulnerabilità e il fornitore deve adoperarsi per la risoluzione

in tempi certi ed accettabili delle anomalie rilevate dall’Azienda o dalle aziende ad esse deputate.

In ogni caso i software oggetto di fornitura non dovranno fare uso di Applet Java e ActiveX.

Come indicato in premessa, l’aggiudicatario verrà designato responsabile ex art.28 del GDPR, ed in quest’ambito dovrà, tra l’altro, inviare, nel rispetto delle procedure aziendali, le richieste di abilitazione degli incaricati e degli amministratori afferenti all’aggiudicatario (anche quelle necessarie per lo svolgimento delle attività di assistenza remota). I relativi account e le relative autorizzazioni verranno sempre erogate dall'Azienda e a livello personale, secondo le proprie procedure ed in ogni caso con i privilegi necessari e sufficienti allo svolgimento delle mansioni di competenza.

Per quanto concerne gli “account amministrativi” (ovvero ogni account a cui è associato un ruolo Amministratore o che è dotato di privilegi amministrativi o che consenta di svolgere funzioni di amministratore su qualunque macchina, sistema o applicativo fornito), questi:

− potranno, nel caso di account amministrativi locali di default (a titolo di esempio non esaustivo: “admin”, “administrator”, “root”, ecc.), essere impersonali e dovranno essere tutti comunicati all’Azienda ove richiesti, che potrà modificarne le password e che li conserverà secondo le proprie procedure standard di sicurezza; in ogni caso non dovranno essere configurati account amministrativi locali ulteriori rispetto a quelli di default; ove non richiesti da Aziende la gestione e responsabilità si intende a carico dell’aggiudicatario;

− dovranno, nel caso di account amministrativi non locali che consentano l’accesso interattivo a macchine/sistemi/applicativi collegati alla LAN, essere sempre personali e rispettare quanto riportato nel presente documento relativamente alle modalità di autenticazione (authentication) degli operatori per mezzo di account – e relative credenziali – personali;

− non dovranno, nel caso di account amministrativi impersonali, essere in alcun caso presenti, se non del tipo gMSA;

− dovranno, nel caso di tutti gli account di sistemi non in LAN, essere gestiti a cura e responsabilità

dell’aggiudicatario;

essere impersonali e dovranno essere tutti comunicati all’Azienda ove richiesti, che potrà modificarne le password e che li conserverà secondo le proprie procedure standard di sicurezza; in ogni caso non dovranno essere configurati account amministrativi in numero maggiore dello stretto necessario; ove non richiesti dalle Aziende la gestione e responsabilità si intende a carico dell’aggiudicatario;

in tal caso, ovvero per quanto concerne gli account impersonali, consentiti solo secondo quanto riportato nel punto precedente, questi non dovranno in alcun caso permettere:

o di modificare le configurazioni, impostazioni e settaggi di macchine/sistemi/applicativi;

o di visualizzare, modificare o cancellare dati personali diversi da quelli eventualmente trattati

contestualmente all’uso dell’account stesso.

Eventuali dati personali salvati in ulteriori archivi, diversi da quelli descritti nel presente documento, saranno ammessi solo con funzioni di “archivi provvisori”, ovvero di passaggio intermedio dei dati prima dell’invio agli archivi definitivi. I dati personali devono permanere negli archivi provvisori il minor tempo possibile, ovvero per un tempo massimo che sia configurabile e che in ogni caso non superi le 24 ore naturali, con l’implementazione di opportune procedure di cancellazione automatica che non consentano il recupero locale dei dati.

In ogni caso l’accesso agli archivi di dati personali (anche provvisori) dovrà avvenire solo da parte degli account personali e degli account gMSA autorizzati, sulla base di opportuni permessi settati in modo che il livello dei privilegi di accesso sia il più basso possibile e che l’accesso ai dati avvenga sempre per tramite dell’applicativo e non direttamente da parte dell’account.

Non è consentita l’archiviazione, anche temporanea ed anche in forma anonima, dei dati su macchine

situate esternamente rispetto alla rete dati dell’Azienda, salvo esplicita autorizzazione da parte dell'Azienda.

Non sarà in alcun caso consentita la fornitura ed installazione di apparati attivi di rete standard (switch, router, firewall, access point Wi-Fi, VPN concentrator, Mi-Fi etc.) a meno di eccezioni concordate con l’Azienda che in ogni caso si riserva di accettarle a suo insindacabile giudizio, a seguito di presentazione di adeguata documentazione tecnica che ne giustifichi la necessità. In particolare: nel caso di apparati di sicurezza, l’aggiudicatario si impegna, come precedentemente riportato, a trasferire le logiche di sicurezza sui firewall aziendali (ISFW – Internal Segregation Firewall) aziendali nel caso di apparati per la connettività remota, l’aggiudicatario si impegna a far uso degli strumenti aziendali messi a disposizione dal’Azienda, come precedentemente riportato.

I firewall aziendali, utilizzati come ISFW a protezione di ciascuno dei contesti di rete descritti nel presente documento (reti e VLAN), sono tecnologicamente dei NGFW (Next Generation Firewall) dotati di funzionalità di statefull inspection e con application controll attivo, conseguentemente tutti i sistemi e le applicazioni oggetto di fornitura, nonché i servizi di assistenza remota e manutenzione, anche erogati tramite VPN, dovranno essere compatibili con tali tecnologie. A titolo di esempio non esaustivo, sistemi e applicazioni dovranno effettuare una gestione attiva del ciclo di vita delle sessioni ed in alcun caso per evitare malfunzionamenti o blocchi delle stesse dovrà essere necessario modificare sui firewall aziendali i relativi parametri TTL (Time-To-Live). L'azienda si riserva di bloccare qualunque tipologia di traffico ritenuto malevolo, in particolare a fronte di specifiche vulnerabilità che dovessero emergere nel corso della durata contrattuale.

Non sarà in generale consentita la fornitura di sistemi di cablaggio dati dedicati, a meno di casi particolari tecnicamente motivati, che dovranno essere esplicitati in offerta tecnica, motivati dettagliatamente ed approvati in ultima istanza dall’Azienda. Riguardo al cablaggio strutturato, dovranno essere utilizzati sempre e comunque i sistemi aziendali e gli eventuali ampliamenti necessari saranno eseguiti dall’Azienda. Dovranno essere indicati in offerta tecnica il numero e la dislocazione spaziale dei puti rete necessari al funzionamento

dei sistemi oggetto di fornitura, indicando per ciascun punto l’eventuale necessità di installazione di dispositivi di separazione (Separation Device) conformi alle norme IEC 60601-1, la cui installazione sarà a carico dell’Azienda. Nel caso in cui l’aggiudicatario volesse comunque offrire servizi di posa in opera di cablaggio strutturato, dovrà sottostare a tutte le policy aziendali, oltre alle norme tecniche di riferimento, e l'Azienda si riserva di indicare ogni singolo dettaglio realizzativo (compresi marca e modello, classe CPR, categoria, ecc. dei materiali da utilizzare) che costituiranno vincolo contrattuale inderogabile.

Document Metadata

Table of Contents

PACS REGIONALE FVG

Document Metadata