Capitolato Tecnico di Gara

avente ad oggetto l’acquisizione di un sistema informatico per la gestione dei servizi di emergenza e urgenza territoriali e continuità assistenziale per l’Azienda Usl Toscana Sud Est e videocomunicazioni per l’emergenza SST

“… la Repubblica tutela la salute come fondamentale diritto dell'individuo e interesse della collettività …”1. “… la potestà legislativa è esercitata dallo Stato e dalle Regioni nel rispetto della Costituzione, nonché dei vincoli derivanti dall'ordinamento comunitario e dagli obblighi internazionali […] sono materie di legislazione concorrente quelle relative a: […] tutela della salute; …”2. “… il presente decreto definisce […] i livelli essenziali di assistenza sanitaria […] attività di emergenza sanitaria territoriale ...”3. In Italia la tutela della salute è un diritto costituzionalmente garantito; l’organizzazione delle risorse dedicate a tale tutela è in capo ad ogni singola Regione che, in base alle linee di indirizzo nazionali, predispone tutte le infrastrutture necessarie a garantire quantomeno dei livelli essenziali di assistenza, fra i quali le attività di emergenza sanitaria territoriale.

“… dal punto di vista organizzativo generale, la Centrale operativa 118 - attiva 24 ore su 24 - ha l’obiettivo di organizzare e gestire le attività di emergenza-urgenza sanitaria territoriale, assicurando il coordinamento di tutti gli interventi dal momento dell’evento sino all’attivazione della risposta ospedaliera, garantendo il trasporto del paziente all’ospedale più vicino e più idoneo alla gestione della patologia, anche in collaborazione con gli altri Enti di Soccorso non sanitario (Vigili del Fuoco, Carabinieri, Polizia ecc..).

La Centrale operativa del 118 effettua la valutazione del grado di complessità degli interventi, procedendo poi ad attivare e coordinare, ricorrendo a procedure e protocolli condivisi, i mezzi di soccorso adeguati per tipologia di intervento, dal mezzo di soccorso di base all’elisoccorso. La definizione del grado di complessità dell’intervento viene eseguita tramite il "Sistema Dispatch", specifica funzione del 118 che comprende le diverse fasi del soccorso, a partire dalla ricezione della chiamata fino all'arrivo dei soccorritori sul luogo dell'evento. Il bacino di utenza delle Centrali 118 è rapportato alla disponibilità di nuove tecnologie informatiche e telefoniche che permettono di rendere più sicuro e standardizzato il coordinamento degli

1 La Costituzione, Parte I “Diritti e doveri dei cittadini”, Titolo II “Rapporti etico-sociali”, Articolo 32.

2 La Costituzione, Parte II “Ordinamento della Repubblica”, Titolo V “Le Regioni, le Provincie, i Comuni”, Articolo 117.

3 Xxxxxxx xxx xxxxxxxxxx xxx xxxxxxxxx xxx xxxxxxxx 00 novembre 2001, G.U. Serie Generale, n. 33 del 08 febbraio 2002, “Definizione dei livelli essenziali di assistenza”.

interventi di soccorso, consentendo di gestire elevati volumi di attività e di attivare funzioni operative integrate

ed interagenti a livello regionale …”4.

Il Servizio Sanitario Regionale Toscano (SSRT) intende dotarsi di strumenti di informatizzazione dedicati alla gestione dell’emergenza sanitaria territoriale, e più in particolare alla gestione organizzativa delle attività di emergenza-urgenza sanitaria territoriale (comunemente identificate come “servizio 118”).

Le Aziende Sanitarie territoriali del SSRT già dispongono di informatizzazioni dedicate ai servizi 118 che risolvono le esigenze di automazione con risorse, modi e metodi diversi fra loro, anche se ognuno con sufficiente efficacia.

L’attuale sistema delle CO118 dell’AUSL TSE nasce da una fornitura iniziale del 2008, aggiudicata da Estav Sud-Est alla ditta Telecom Italia SpA in A.T.I. con Beta80 SpA. Le centrali Inizialmente individuate erano una per ognuna delle provincie di Arezzo, Grosseto e Siena, allora gestite dalle rispettive AUSL provinciali (ex AUSL 7 di Siena, 8 di Arezzo e 9 di Grosseto).

A seguito della variazione del modello organizzativo, nel 2016 le CO118 sono state riorganizzate nelle sedi di Siena ed Arezzo, tramite procedura negoziata in esclusiva con l’A.T.I. fornitore dei sistemi in uso, che tuttora effettua il servizio di manutenzione ed assistenza hardware e software.

Il presente capitolato riguarda la fornitura di un sistema informatico per la gestione dei seguenti

servizi dell’Azienda Usl Toscana Sud Est:

• Servizio di emergenza territoriale (Centrali Operative 118);

• Servizio di trasporti di urgenza (ex “Ordinari” - Centrale di II Livello);

• Servizio di continuità assistenziale; e per tutta la Regione Toscana di un:

• Servizio di videocomunicazione avanzata fra assistito e Centrali Operative 118.

Il territorio interessato è tutta l’Area Vasta Toscana Sud Est, ossia le provincie di Siena, Grosseto ed Arezzo, esteso a tutta la Toscana per il Servizio di videocomunicazione avanzata.

L’installazione sarà unica per tutta l’AUSL TSE e sarà effettuata dalla ditta aggiudicataria dell’appalto su

server che saranno messi a disposizione da ESTAR.

4 Ministero della Salute, “Servizio Sanitario Nazionale: i LEA”, “Emergenza sanitaria territoriale”,

xxxx://xxx.xxxxxx.xxx.xx/xxxxxxx/xxx/xxxxxxxxxXxxxxxxxxXxx.xxx?xxxxxxxxxxxxxxx&xxx0000&xxxxxXxx&xxxxxxxxxxxxxxxxx

La fornitura oggetto del presente capitolato è dunque costituita dai seguenti componenti:

• software, ivi comprese le funzionalità di integrazioni con gli altri applicativi utilizzati dalla AUSL TSE;

• servizi di installazione, configurazione iniziale e avviamento;

• start up e formazione;

• servizi di manutenzione ed assistenza per un periodo temporale di 5 anni a decorrere dalla data del collaudo.

1.2 Obiettivi

L’Azienda Usl Toscana Sud Est (di seguito AUSL TSE) opera su un territorio molto ampio (tutta l’Area Vasta Toscana Sud Est - di seguito AVSE – che ha una superficie di circa 11.557 km2), caratterizzato da una bassa densità di popolazione (72 abitanti/km2), distanze oro-geografiche enormi e carenza infrastrutturale, nel quale sono presenti 14 xxxxxxxx0. In tale contesto i servizi territoriali risultano di vitale importanza, al fine di garantire una tempestiva ed efficace presa in cura dei pazienti anche in contesti poco urbanizzati.

La presente gara si pone l’obiettivo di dotare i servizi di gestione dell’emergenza territoriale, dei trasporti di urgenza, e della continuità assistenziale di un nuovo sistema informatico, corredato dalle moderne funzionalità e tecnologie necessarie per governare i processi operativi, garantendo una più efficace e ottimale gestione clinica e organizzativa, al fine sia di aumentare la sicurezza dei pazienti sia di migliorare l’utilizzo delle risorse, mettendo l’innovazione al servizio del cittadino al fine di diminuire le distanze fisiche anche con sistemi di videocomunicazione avanzata.

1.3 Definizioni

Nel testo che segue, oltre che alle definizioni contenute nelle norme UNI 11063 (Tutte le definizioni delle norme di riferimento per la manutenzione), viene fatto riferimento alle seguenti denominazioni e definizioni:

5 Gli ospedali presenti nell’AVSE sono:

• l’Azienda Ospedaliero-Universitaria Senese (AOUS);

• i 13 stabilimenti ospedalieri dell’AUSL TSE:

◦ nella provincia di Siena: ospedale di Nottola a Montepulciano, ospedale di Abbadia San Salvatore, ospedale di Campostaggia a Poggibonsi;

◦ nella provincia di Grosseto: ospedale Misericordia di Grosseto, ospedale S. Xxxxxx di Massa Marittima, ospedale di Castel del Piano, ospedale S. Xxxxxxxx xx Xxx di Orbetello, ospedale X. Xxxxxxxxxxx di Pitigliano;

◦ nella provincia di Arezzo: ospedale San Donato di Arezzo, ospedale di Bibbiena, ospedale della Valdichiana Aretina La Fratta, ospedale della Valtiberina a Sansepolcro, ospedale La Gruccia del Valdarno.

Termine	Descrizione del Termine
Aggiudicatario, Xxxxx Xxxxxxxxxxxxxx, Xxxxx appaltatrice, Ditta contraente, Contraente, Fornitore, Assuntore	Il fornitore aggiudicatario, che ha sottoscritto il contratto obbligandosi a quanto nello stesso previsto nei confronti dell’Azienda. Esso può identificarsi anche con un raggruppamento temporaneo di imprese o con il suo capofila.
Azienda Sanitaria, Azienda, Committente	Il complesso delle aziende sanitarie e gli enti del Servizio Sanitario della Regione Toscana che usufruiscono dei servizi oggetto dell’appalto.
Ente Appaltante, Stazione Appaltante	Ente che assegna l’appalto
Ditta concorrente, Ditta offerente	Impresa singola, raggruppamento temporaneo di imprese costituito o costituendo, consorzio o altro soggetto partecipante alla gara. Essa può identificarsi anche con il capofila di un raggruppamento temporaneo di imprese
Help Desk	Struttura che ha il compito di dare il supporto di primo livello a fronte di una richiesta di assistenza; qualora non sia possibile trovare una soluzione al problema via assistenza di primo livello, l’Help Desk ha il compito scalare il problema sia verso il supporto tecnico avanzato o verso un eventuale fornitore terzo che eroga il supporto tecnico specifico
Service Level Agreement (SLA)	in italiano: Accordo sul livello del servizio, in sigla SLA, è uno strumento contrattuale attraverso il quale si definiscono le metriche di servizio che devono essere rispettate da un fornitore di servizi.
Sistemi Serventi o Server	sottosistemi più o meno complessi, in grado di fornire servizi di tipo infrastrutturale di base o applicativi. Essi sono generalmente costituiti da hardware, software di base (sistemi operativi, driver di periferiche) e sistemi di memorizzazione interni o esterni, esclusivi o condivisi.
Unità Operativa (UO)	Struttura organizzativa professionale e/o funzionale dell’Azienda titolare di proprio budget assegnato
Trasporto di emergenza	Trasporto effettuato per una condizione che pone il paziente in imminente pericolo di vita e richiede un intervento immediato.
Trasporto urgenza	Trattasi di servizio di trasporto sanitario previsto nei livelli di essenziali di assistenza, effettuati tramite ambulanza e servizi di trasporto nei quali le condizioni cliniche del paziente richiedono la necessità dell'assistenza in itinere con personale adeguatamente formato, nonché l'esigenza di garantire la continuità delle cure al fine di non interrompere il percorso assistenziale già intrapreso.
Dispatcher	Operatore formato che risponde, prende in carico, filtra e smista le telefonate dirette dal NUE 112.
Dispatch	Il Sistema del Dispatch (o di invio) è un sistema elaborato negli Stati Uniti che comprende tutte le operazioni inerenti il sistema di soccorso, dalla ricezione della chiamata all’arrivo dei soccorritori sul luogo dell’evento. E’ costituito da 5 fasi principali: intervista telefonica, attribuzione codice di gravità, scelta del mezzo di soccorso, istruzione all’utente sulle manovre da effettuare pre-arrivo dei mezzi di soccorso, supporto informativo ai soccorritori fino all’arrivo sul target.
Missione	La missione viene attribuita al mezzo di soccorso scelto dal dipatcher, ha un codice numerico identificativo. Per ogni evento possono essere presenti anche più mezzi di soccorso.
Centrale operativa 1° livello (CO 1° livello)	E’ la Centrale Operativa che coordina e governa il servizio 118. Sinonimo di Centrale Operativa 118 (CO118)
Centrale operativa 2° livello (CO 2° livello)	E’ la Centrale Operativa che coordina e governa il servizio di trasporti sanitari di urgenza.
Call taker	Call taker è la scheda evento che viene aperta sul software di centrale operativa 1° livello ogni volta che arriva una chiamata da linea di soccorso (NUE 112).
Stazionamento	Posizione del mezzo di emergenza quando non è in movimento.
Intervento	Per intervento di intendono tutte le attività a valle dell’avvenuta richiesta, dall’assegnazione delle Risorse fino al rientro di queste allo stazionamento.
Evento	Viene definito evento ogni chiamata ricevuta in centrale operativa 1° livello che genera la creazione di una scheda Evento sul software di centrale operativa. Da questa scheda evento può scaturire un intervento di soccorso oppure concludersi come informazione alla cittadinanza (consiglio telefonico) o essere destinata alla continuità assistenziale.
Target	E’ il luogo dove è richiesto il soccorso sul territorio (domicilio, strada, impianti sportivi, uffici pubblici, RSA, etc).
Rendez-vous nell’Emergenza Territoriale 118	Modalità operativa per la gestione di un'emergenza/urgenza sanitaria, dove la centrale 118 decide un punto di incontro, a metà strada tra un target remoto, tra mezzo di soccorso avanzato e mezzo di soccorso di base (con malato a bordo). Al Rendez Vous non è previsto il trasbordo del malato,

ma del personale sanitario e delle attrezzature. Questa operazione farà diventare temporaneamente il mezzo di soccorso di base un mezzo di soccorso avanzato.

1.1 Terminologia, abbreviazioni

Glossario dei termini e delle abbreviazioni

Acronimo	Definizione
AA.OO.UU.	Aziende Ospedaliero Universitarie. Si Xxxxxx di AOU Pisana, AOU Careggi, AOU Meyer, AOU Senese
XX.XX.	Aziende Sanitarie. Si Tratta di USL Toscana Nord Ovest, USL Toscana Centro, USL Toscana Sud Est
AA.VV./CRI	Associazioni di Volontariato / Croce Rossa Italiana
ADT	Accettazione-Dimissione-Trasferimento (software ospedaliero)
ANAC	Autorità nazionale anticorruzione
AOUS	Azienda Ospedaliera Universitaria Senese
AS IS	“Come é attualmente”: termine utilizzato per indicare la situazione attuale
AUSL TSE	Azienda Usl Toscana Sud Est
AVTSE	Area Vasta Toscana Sud Est
BLS	Basic life support
BLSD	Basic Life Support Defribillation
CA	Continuità Assistenziale
CAM	Canone Assistenza Manutezione
CART	Cooperazione Applicativa Regione Toscana
CO II Livello	Centrale Operativa di Secondo Livello
CO118	Centrale Operativa 118
CTI	Computer-Telephone Integration Tecnologia che permette interazioni tra un telefono e un computer consentendone il coordinamento integrato
CUR	Centrale Unica di Risposta per l’emergenza
DEC	Direttore dell'Esecuzione del Contratto (art. 101 D.Lgs 50/2016)
DURC	Documento Unico di Regolarità Contributiva
DWH	Data Warehouse
ESTAR	Ente di supporto tecnico-amministrativo regionale
FTGM	Fondazione Toscana Xxxxxxxx Xxxxxxxxxx
GDPR	General Data Protection Regulation, il Regolamento Ue 2016/679 relativo alla protezione delle persone fisiche con riguardo al trattamento e alla libera circolazione dei dati personali
ISPRO	Istituto per lo Studio, la Prevenzione e la Rete Oncologica
MEV	Manutenzione EVolutiva
MMG	Medico di Medicina Generale
MSA	Mezzo di Sicurezza Avanzato (Ambulanza, automedica o elicottero con a bordo medici e/o infermieri)
MSB	Mezzo di Sicurezza Base (Ambulanza con a bordo personale dellle AA.VV./CRI con attestato BLSD)
MSB	Mezzo di soccorso di base (con il termine si indica BLSD o BLS)
NUE112	Numero Unico dell’Emergenza 112
OTV	Operatore Tecnico Volontariato
PDI	Piano dettagliato di intervento
PET	Postazione di Emergenza Territoriale
PLS	Pediatra di Libera Scelta
POI	Punto di Interesse (Point Of Interest)
PS / XX.XX.	Pronto Soccorso /Pronti Soccorso
PSAP	Public Safety Answer Point Il funzionamento della Centrale Unica di Risposta (CUR) del Servizio NUE 112 è organizzato su due livelli: il primo (CUR – PSAP1) riceve la chiamata di soccorso e il secondo (PSAP2 - Centrali operative Polizia di Stato, Arma dei Carabinieri, Vigili del Fuoco ed Emergenza Sanitaria) gestisce effettivamente la situazione di emergenza. Qualunque numero nazionale di emergenza si chiami (113, 112, 115 e 118), la telefonata viene ricevuta dalla Centrale Unica di Risposta.

RDA	Richiesta di Acquisto
RES	Responsabile del procedimento per la fase di esecuzione del contratto (art. 2 comma 1.b DGRT 16/2014)
RT	Regione Toscana
RUP	Responsabile unico del procedimento (art. 31 D.Lgs 50/2016) nella fase che si chiude con la stipula del contratto
SDA	Sistemi Dinamici di Acquisizione
SIT	Sistema Informativo Territoriale
SLA	Service Level Agreement
SSN	Servizio Sanitario Nazionale
SSR	Servizio Sanitario Regionale
SSRT	Servizio Sanitario Regionale Toscano
SW	Software
TAO	Terapia Anticoagulante Orale
TO BE	“Come dovrà essere”: termine utilizzato per indicare la situazione futura e/o desiderata
UTIC	Unità Operativa di Terapia Intensiva Cardiologica

1.2 Riferimenti Normativi

La fornitura, che dovrà essere adeguata dal punto di vista funzionale e di aderenza alle prescrizioni normative ad un impiego in ambiente sanitario; dovrà altresì garantire aderenza a standard internazionali ed essere dotata di funzionalità di integrazione in rete con adeguato controllo degli accessi, tracciabilità degli interventi e gestione avanzata dei referti con disponibilità anche di interfaccia ad alto livello (XML) per agevolare future integrazioni con altre risorse di un Sistema Informativo Ospedaliero.

Il prodotto dovrà essere dotato delle funzionalità necessarie a consentire il trattamento dei dati nel rispetto del Regolamento UE 679/2016 relativo alla disciplina sulla protezione dei dati personali (GDPR).

Il sistema, qualora previsto dalle normative, deve essere certificato come dispositivo medico e dovrà essere allegata Dichiarazione di Conformità del produttore secondo il Regolamento Dispositivi medici 2017/745.

2 Oggetto della fornitura ed esclusioni

2.1 Oggetto della fornitura

Il presente Capitolato disciplina la forniture, comprensiva di installazione, formazione, avviamento e manutenzione di un sistema informatico per la gestione dei servizi dell’Azienda Usl Toscana Sud Est relativi all’emergenza territoriale (Centrali Operative 118 di Arezzo e Siena/Grosseto) ed ai trasporti di urgenza (ex “Ordinari” - Centrale di II Livello) afferenti al Dipartimento di Emergenza e Urgenza, di continuità assistenziale afferente al Dipartimento del Territorio e di video comunicazione fra assistito e Centrali Operative.

Per ciascuno di essi, di seguito si riporta una descrizione del contesto organizzativo, dei processi aziendali e degli obiettivi tecnico-funzionali che si vogliono raggiungere con la fornitura.

2.1.1 Servizio di emergenza territoriale

II servizio di emergenza territoriale della AUSL TSE si articola in:

• servizio 118 di Arezzo, governato e coordinato dalla CO118 di Arezzo e che al momento risulta articolato su 58 postazioni territoriali, di cui 5 automediche, 7 ambulanze infermierizzate, 46 postazioni mobili con volontari appositamente formati (BRAVO);

• servizio 118 di Siena-Grosseto, governato e coordinato dalla CO118 di Siena-Grosseto e che al momento risulta articolato su 78 postazioni territoriali di cui 14 automediche, 12 postazioni infermierizzate, 52 postazioni mobili con volontari appositamente formati (BRAVO).

Le AA.VV./CRI sono parte integrante del sistema 118, supportando le attività di emergenza con il personale del volontariato impiegato sulle ambulanze. I trasporti sanitari di emergenza sono infatti svolti sia da personale medico-infermieristico6, sia da personale del volontariato appositamente formato (in gergo spesso chiamati col termine “BRAVO”).

Segue una descrizione del processo di gestione di un generico evento di emergenza sanitaria. In caso di emergenza sanitaria, il cittadino contatta il 112.

6 Il numero telefonico 118 è stato di recente sostituito dal Numero Unico dell’Emergenza 112, sul quale confluiscono tutte le telefonate

dei cittadini inerenti situazioni di emergenza. Il numero “118” è attualmente attivo con deviazione di chiamata sul numero “112”.

La CUR competente7 (PSAP1) prende in carico il contatto. Qualora l’emergenza sia di tipo sanitario, la CUR passa la xxxxxxxx0 alla CO118 di riferimento (PSAP2) (attualmente tramite conferenza telefonica) con la quale condivide anche la scheda contatto parzialmente compilata (attualmente sfruttando l’integrazione esistente tra l’applicativo della CUR di Firenze e quello delle CO118 di Siena-Grosseto e Arezzo9). Il contatto viene quindi preso in carico dall’infermiere della CO118, responsabile del processo di “Dispatch”, e solo successivamente dall’operatore che si occupa di attivare il mezzo sul territorio (in base ai criteri stabiliti dall’infermiere nella fase precedente).

Il mezzo di soccorso attivato per l’evento riceve la scheda evento/missione su dispositivo mobile (tablet) sul quale è installata apposita app con la quale il sistema informatico di Centrale si integra (e si dovrà integrare)10. Le principali informazioni/funzionali svolte dell’equipaggio del mezzo di soccorso sono:

• ricezione ed aggiornamento dei dati della missione (tra cui anche gli stati);

• attivazione della navigazione assistita verso il target (luogo evento, ospedale ecc.);

• compilazione e firma delle schede paziente;

• visualizzazione ed archiviazione della documentazione prodotta dagli elettromedicali integrati.

Il medico di CO118 fornisce consulenza agli infermieri della CO118 ed agli equipaggi dei mezzi in caso di necessità.

I trasporti sanitari possono essere richiesti anche dai reparti ospedalieri (es. per trasferimento di pazienti tra due ospedali). Qualora per il trasporto sia necessaria un’ambulanza, i reparti contattano direttamente le CO118 (attualmente attraverso linea telefonica dedicata - senza passare dalla CUR, corredata da email, con cui il medico richiedente trasmette la documentazione necessaria e proposta di classe di Eherenwerth). Il medico di CO118 assegna quindi la classe Eherenwerth (confermando o modificando la proposta del reparto) e individua il regime di trasporto11. Se il trasporto deve essere svolto in emergenza, un operatore di CO118 provvede alla programmazione, all’inserimento del trasporto nel gestionale, quindi alla ricerca ed attivazione del mezzo sul territorio12.

7 Se il cittadino chiama dalle provincie di competenza dell’AUSL TSE risponde la CUR di Firenze.

8 La gestione delle telefonate da parte delle CO118 avviene attraverso l’utilizzo del software CTI, integrato con il gestionale della CO118.

9 Anche il nuovo sistema informatico gestione di Centrale Operativa 118 dovrà integrarsi con il gestionale della CUR di Firenze0.

10 Attualmente gli equipaggi dei mezzi 118 utilizzano sui tablet la app mobile nativamente integrata con la gestione di CO118; in futuro

è previsto l’utilizzo di una app di un fornitore esterno con la quale dovrà essere prevista apposita integrazione.0

11 La classe di Eherenwerth determina il livello di assistenza richiesto per il trasporto.

12 Attualmente l’inserimento del trasporto nel gestionale è fatto nel momento in cui il trasporto avviene realmente, in quanto il software in uso non consente la schedulazione di trasporti in emergenza futuri. Ai fini della programmazione di tali trasporti, ad oggi la CO118 si avvale quindi di documentazione cartacea. Si richiede che il software oggetto di gara, oltre a consentire la gestione del flusso di

Una volta che la CO118 e le AA.VV./CRI hanno compilato nel gestionale della CO118 tutte le informazioni relative alla missione (stati, kilometraggio ecc..)13, i dati sono trasmessi al software della AA.VV./CRI che ha erogato il servizio di trasporto14, attraverso specifica integrazione applicativa15.

I dati di trasporto completi sono quindi verificati dal personale amministrativo dell’Ufficio Trasporti AUSL TSE (attività di “validazione”) e valorizzati economicamente su base della Delibera RT 908/2018 “Determinazione dei costi standard”. L’attività di “rendicontazione”, che segue quella di validazione, consiste nella trasmissione alle AA.VV./CRI della quantificazione economica dei servizi erogati. Attualmente tale attività avviene sia attraverso l’invio di fogli di lavoro tramite email, sia mediante la condivisione dei dati tramite integrazione software.

Con il presente Capitolato, l’AUSL TSE intende acquisire un nuovo sistema informatico da utilizzare presso le CO118 per la gestione degli eventi di emergenza e presso l’Ufficio Trasporti AUSL TSE per la validazione e rendicontazione dei trasporti effettuati dalle AA.VV./CRI. Il sistema dovrà essere utilizzato anche da parte delle AA.VV./CRI per le attività di competenza.

La nuova automazione software dovrà avere tutte le funzionalità e le interfacce/integrazioni necessarie per favorire l’ergonomia del lavoro per gli operatori di Centrale ed il rapido accesso a tutte le basi dati che possono supportare il personale nella gestione degli interventi, anche attraverso integrazioni con applicativi esterni (come meglio specificato al §4.4).

Particolare attenzione dovrà essere fornita alle funzionalità di reportistica, personalizzabile e facilmente configurabile anche da parte di un amministratore di sistema (personale AUSL TSE o ESTAR) opportunamente formato, per la consultazione in tempo reale i dati relativi al servizio di emergenza.

Il sistema dovrà inoltre alimentare con cadenza almeno giornaliera il DWH aziendale, a cui il 118 farà

riferimento per l’analisi di grandi moli di dati.

richiesta/approvazione/assegnazione classe di Eherenwerth, permetta anche di gestire la programmazione dei trasporti in emergenza futuri.

13 Attualmente, per l’inserimento di tutti i dati relativi alla missione di emergenza effettuata, il personale delle AA.VV./Cri accede al gestionale della CO118. Tale possibilità dovrà essere garantita anche con il nuovo software. Come evoluzione futura si potrà inoltre prevedere la possibilità di ricevere le informazioni suddette dal software delle AA.VV./CRI, ovviamente per le sole AA.VV./Cri che, oltre al gestionale del 118, hanno anche un proprio software per la gestione dei trasporti.

14 Non tutte le AA.VV./CRI hanno un proprio applicativo. Quelle che non lo hanno utilizzano esclusivamente il software del 118.

15 Anche il nuovo software che sarà acquisito con la gara in oggetto dovrà essere integrato con il/i gestionali delle AA.VV./CRI0.

2.1.2 Servizio di urgenza territoriale

Il governo del servizio di urgenza territoriale è svolto da una unica CO II Livello per tutta l’AVTSE, mentre i trasporti sono erogati dalle AA.VV./CRI convenzionate. L’organizzazione del servizio è diversa fra le varie provincie.

2.1.2.1 Area Provinciale di Arezzo

Dagli ospedali (per dimissioni o trasferimenti) la richiesta arriva direttamente alla CO II livello tramite l’applicativo di ADT16, in dotazione agli ospedali del territorio aretino ed integrato con il gestionale della CO II Livello. La CO II livello verifica l’appropriatezza prescrittiva e assegna il servizio alla AA.VV./C.R.I., individuata in base ad un calendario di disponibilità delle AA.VV./C.R.I. concordato con le medesime, secondo il criterio della competenza territoriale.

Dal territorio la richiesta giunge alla CO II livello tramite le AA.VV./C.R.I., le quali ricevono in una prima fase la richiesta dell’utente, la trasmettono alla CO II livello (attualmente tramite fax service o posta elettronica17). La CO II livello, verificata l’appropriatezza prescrittiva e la competenza territoriale, provvede a validare la richiesta ed autorizzare le AA.VV./C.R.I. richiedente all’effettuazione del servizio.

2.1.2.2 Area Provinciale di Grosseto

Dagli ospedali (per dimissioni o trasferimenti) la richiesta viene trasmessa direttamente alla CO II livello tramite il gestionale della CO118, al quale hanno accesso i reparti ospedalieri delle provincie di Siena e Grosseto18. La CO II livello verifica l’appropriatezza prescrittiva e assegna il servizio alla AA.VV./C.R.I., secondo il criterio della competenza territoriale, garantendo un equilibrio nella distribuzione dell’attività tra le varie AA.VV./C.R.I. nei territori in cui sono presenti più associazioni (in un futuro prossimo anche per la provincia di Grosseto sarà utilizzato un calendario per l’assegnazione, analogamente a quanto avviene per la provincia di Arezzo).

Dal territorio di competenza vale quanto detto per l’Area Provinciale di Arezzo.

16 Attualmente soltanto l’applicativo di ADT della provincia di Arezzo è integrato con il software della CO II Livello per la gestione dei trasporti ordinari. Il nuovo sistema informatico dovrà prevedere integrazione con gli applicativi di ADT delle 3 provincie.

17 La nuova automazione dovrà prevedere sia la consultazione della prescrizione elettronica (da attivare qualora la Regione Toscana preveda nel catalogo delle prestazioni prescrivibili anche il trasporto di urgenza), sia la possibilità per le AA.VV./CRI di allegare alla richiesta di trasporto copia della prescrizione medica (rispetto all’integrazione in essere tra il software delle AA.VV./CRI ed il software di CO 2° Livello il campo per la trasmissione dell’allegato è da aggiungere).

18 In futuro, questa possibilità ai reparti ospedalieri dovrà essere garantita attraverso gli applicativi di ADT delle 3 province.

2.1.2.3 Area Provinciale di Siena

Dagli ospedali (per dimissioni o trasferimenti) la richiesta viene trasmessa direttamente alla CO II livello, (attualmente tramite fax o tramite il gestionale della CO118, al quale hanno accesso i reparti ospedalieri delle provincie di Siena e Grosseto)19. La CO II livello verifica l’appropriatezza prescrittiva e assegna il servizio alla AA.VV./C.R.I., individuata in base alla procedura denominata “tasto di assegnazione”, che utilizza un algoritmo in grado di assegnare il servizio tenendo conto della competenza territoriale e della disponibilità comunicate dalle AA.VV. /C.R.I..

Dal territorio di competenza, la richiesta giunge direttamente alla CO II livello (attualmente tramite chiamata telefonica dell’utente). La CO II livello acquisite le informazioni utili all’effettuazione del servizio, assegna la missione tramite opzione dell’utente, oppure, in caso di viaggio non opzionato, tramite procedura informatizzata denominata “tasto di assegnazione” (per trasporti primari), che utilizza un algoritmo in grado di assegnare il servizio tenendo conto della competenza territoriale e della disponibilità comunicate dalle AA.VV./C.R.I.. Le AA.VV./CRI (delle 3 provincie) che sono dotate di un proprio applicativo possono lavorare esclusivamente su questo e scambiare i dati di interesse con la CO II Livello attraverso integrazione applicativa.

Per le 3 provincie, le attività di validazione e rendicontazione corrispondono a quanto descritto per

l’emergenza.

Con il presente capitolato, l’AUSL TSE intende acquisire un nuovo sistema informatizzato da utilizzare presso la CO II Livello e le AA.VV./CRI per la gestione dei trasporti di urgenza e presso l’Ufficio Trasporti AUSL TSE per le attività di validazione e rendicontazione.

Si richiede che il nuovo sistema sia altamente configurabile, in grado di offrire strumenti specifici, sicuri e affidabili per gestire l'operatività amministrativa e garantire la completa tracciabilità del servizio in ogni fase del processo, dalla prenotazione/assegnazione alla rendicontazione, in completa integrazione tra CO II livello le AA.VV./CRI e i reparti Ospedalieri.

Particolare attenzione dovrà essere fornita alle funzionalità di reportistica, che dovranno consentire al personale AUSL TSE di consultare in tempo reale i dati relativi al servizio di urgenza. Si richiede

19 In futuro, questa possibilità ai reparti ospedalieri dovrà essere garantita attraverso gli applicativi di ADT delle 3 provincie.

inoltre che la reportistica sia personalizzabile e facilmente configurabile anche da parte di un amministratore di sistema aziendale opportunamente formato.

Il sistema dovrà altresì alimentare con cadenza almeno giornaliera il DWH aziendale, a cui gli uffici

competenti faranno riferimento per l’analisi di grandi moli di dati.

2.1.3 Servizio di continuità assistenziale

La continuità assistenziale è il servizio che, in assenza del medico di famiglia, garantisce l'assistenza medica di base per situazioni che rivestono carattere di non differibilità, cioè per quei problemi sanitari per i quali, sebbene non siano emergenze, non si può aspettare fino all'apertura dell'ambulatorio del proprio medico curante o pediatra di libera scelta.

Nella AVTSE il servizio è governato da operatori “laici” di due Centrali operative di CA (la CO di Arezzo gestisce il servizio per la provincia di Arezzo, quella di Grosseto per le provincie di Siena e Grosseto), che si occupano di rispondere alle telefonate, annotare le generalità dei pazienti (dati anagrafici, contatto telefonico, motivo della chiamata...) ed attivare i medici in servizio sul territorio20.

La Centrale Operativa di Grosseto attualmente utilizza il software della CO118 (CTI e gestionale) per la gestione delle chiamate, mentre quella di Arezzo utilizza un diverso CTI e l’applicativo utilizzato dalla ex AUSL8 per il tracciamento dei contatti telefonici di CA.

Le visite e le consulenze erogate dai medici di CA invece attualmente non sono registrate in alcun sistema informatico strutturato (archiviazione in cartelle locali di file e/o in cartelle cartacee).

Con il presente capitolato, l’AUSL TSE intende acquisire un nuovo sistema informatico da utilizzare presso le CO di Continuità Assistenziale e possa essere utilizzato anche dai medici di CA attraverso pc o tablet per la comunicazione della presenza in servizio e per la registrazione delle prestazioni erogate (supporto telefonico, visita a domicilio, visita in ambulatorio...).

20 I medici di CA sono medici convenzionati con la AUSL TSE.

2.1.4 Servizio di videocomunicazione avanzata fra assistito e Centrali Operative

La ASLTSE intende aggiungere un importante tassello al sistema di emergenza, dotandosi di un nuovo ed innovativo sistema di comunicazione fra assistito e CO118.

Attualmente il contatto con chi richiede assistenza avviene unicamente per via telefonica. Poter avere, oltre che un contatto orale, anche un contatto visivo fin dal primo momento, permette di essere ancora più vicini al cittadino. Sfruttando la tecnologia comunemente diffusa chiunque chiami dal proprio cellulare dovrà entrare direttamente in contatto video con la centrale operativa, trasmettendo le immagini del luogo ad esempio dell’incidente, in modo che chi gestisce la chiamata dalla centrale operativa possa valutare al meglio la situazione e dare le corrette informazioni e procedure di primo soccorso al chiamante o alle altre persone presenti sul posto.

Le immagini provenienti dalla scena di un evento, ad esempio, di “maxiemergenza” (mostrate da un cittadino o dai primi mezzi di soccorso) permetteranno di compiere una prima ricognizione a distanza; a seguito delle valutazioni svolte (es. numero e tipologia dei feriti coinvolti, possibilità di soccorso con mezzi terrestri od aerei), potranno essere prese le scelte più efficaci.

Con il presente capitolato, l’AUSL TSE intende acquisire un nuovo sistema informatico che consenta al cittadino che contatta la CO118 di condividere immagini del luogo e della scena, effettuando non soltanto una videochat con gli operatori sanitari. Il sistema dovrà funzionare senza l’ausilio di nessuna “App” ma attraverso il browser con cui si naviga su Internet con lo smartphone (previa accettazione di un consenso inviato da centrare ad esempio via SMS).

2.2 Obiettivi specifici della fornitura

Il progetto e la relativa realizzazione devono prevedere il raggiungimento degli obiettivi prefissati dalla AUSL TSE e, pertanto, migliorare i servizi erogati ai cittadini, evolvendo verso un sistema informativo dinamico, distribuito, che non proponga vincoli tecnologici. Tale sistema dovrà basarsi sulle mutate esigenze organizzative e sui modelli che nel corso degli anni si sono delineati. È necessaria un’ampia versatilità e riconfigurabilità adeguate al contesto organizzativo mutevole.

Altri obiettivi sono i seguenti:

• ottimizzazione dei flussi di lavoro;

• minimizzazione del rischio di errori nella gestione del workflow clinico attraverso un elevato livello di automatizzazione ed integrazione informatica;

• gestione paperless della documentazione clinica e dei trasporti;

• riduzione dei tempi di recupero delle informazioni cliniche relativamente ai pazienti trattati;

• semplificazione dell’interfaccia e del flusso di lavoro per tutti gli attori coinvolti nel processo (118,

Centrale di 2° Livello, AA.VV./CRI, Continuità Assistenziale);

• miglioramento delle possibilità di reportistica ed analisi sui dati relativi ai processi gestiti.

2.3 Elementi non compresi nella fornitura

Le componenti hardware verranno messe a disposizione dalla stazione appaltante. L’infrastruttura di rete, di storage, di elaborazione dedicate al funzionamento dei servizi implementati nell’ambito di questa fornitura saranno in gestione della stazione appaltante, che garantirà l’operatività delle risorse tecnologiche necessarie al corretto funzionamento di tali infrastrutture, dimensionandole in diretta collaborazione dell’aggiudicatario, che dovrà prevedere tutte le necessità per l’intero periodo contrattuale e descriverle in offerta tecnica.

Il sistema per la AUSL TSE sarà ospitato presso i data center aziendali si Arezzo (Ospedale San Donato) e Siena (ESTAR – Centro Direzionale P.zza Rosselli); il sistema di videocomunicazione dedicato alle altre centrali di RT sarà comunque ospitato in hardware messo a disposizione dalla stazione appaltante. Le ditte partecipanti dovranno esplicitare nell’offerta tecnica le caratteristiche delle componenti hardware che dovranno essere messe a disposizione affinché ne sia garantito il corretto funzionamento. La stazione appaltante, tramite ICT Estar garantisce l’affidabilità, le performances e la sicurezza, sia in termini di protezione perimetrale da indebito accesso, sia in termini di continuità di servizio dei sistemi in caso di malfunzionamenti.

Sono pertanto a carico della stazione appaltante:

• la rete locale e geografica;

• i server, di cui devono essere indicate le specifiche tecniche con criteri di ridondanza e gli spazi disco necessari;

• le licenze del software di base (sistema operativo, database, ecc…);

• le postazioni di lavoro ivi compresi eventuali dispositivi mobili (es. tablet, smartphone) Sono inoltre esclusi dalla fornitura:

• il sistema di registrazione vocale delle telefonate;

• il sistema per la comunicazione con le radio;

• la app mobile fornita agli equipaggi dei mezzi di gestione dell’emergenza.

3 Contesto

Nel presente paragrafo si riportano alcuni dati relativi all’ambito di riferimento con particolare focus sulle informazioni utili a definire il dimensionamento dell’ambito di applicazione e ad inquadrare la situazione in Essere.

3.1 Principali dati di attività

Servizio	Q.ta/anno
trasporti di urgenza	250.000 circa
trasporti di emergenza	120.000 circa
contatti di continuità assistenziale	104.000 circa

3.2 Attuali moduli software in uso

L’attuale fornitore dei sistemi è il RTI TIM/Beta80. Di seguito i principali moduli software in uso.

Modulo	Servizio erogato
Emma 118	Gestionale client/server delle CO 118, delle CO II Livello e della Centrale di CA di Siena/Grosseto21, dotato di integrazione con POT/Barra Telefonica
Emmaweb	Interfaccia web per l’accesso da parte delle AA.VV./CRI per la la gestione dei trasporti di emergenza e urgenza, dai reparti ospedalieri dell’AVSE per la richiesta di trasporti di emergenza e urgenza, dai PS dell’AVSE per la visualizzazione delle schede di emergenza sanitaria di centrale operativa e referti (schede MSA ed MSB);
Smarthub	App utilizzata dagli equipaggi dei mezzi di trasporto per la navigazione, trasmissione stati missioni e compilazione delle schede MSA ed MSB.
Datawarehouse 118	Datawarehouse alimentato dalle due installazioni Emma118
MisEmma	Sistema di statistiche su base dati ed estrazione dati
Xxxx	gestionale amministrativo per la validazione e rendicontazione dei trasporti
Nice trading record	Software per il riascolto delle registrazioni telefoniche
Geos	Cartografia
Portale Giornalisti	Sito web consultazione degli eventi 118 di rilevanza pubblica

3.3 Utenze stimate

Nella tabella seguente si riporta una stima del numero di utenti che si prevede utilizzeranno i sistemi oggetto del presente Capitolato.

21 Il Servizio di CA per Arezzo utilizza un software del fornitore ErreEffe (GPI), a differenza di quello di Siena/Grosseto.

Componente applicativa	Numero di utenti previsto (stima)
Sistema per la gestione dell’emergenza territoriale	1000 utenti fra operatori di Centrale 118, Ufficio Amministrativo Trasporti, AA.VV./CRI, amministratori di sistema e supervisori, operatori OTV
Software per la gestione dell’urgenza territoriale	500 utenti fra operatori di Centrale II livello, Ufficio Amministrativo Trasporti, AA.VV./CRI, amministratori di sistema e supervisori
Software per la gestione della Continuità Assistenziale	350 utenti attivi fra operatori di Centrale di CA, medici di CA, amministratori di sistema e supervisori

3.4 Aspetti regolatori sui Medical Device

Qualora dei moduli siano secondo l'attuale assetto normativo qualificabili come dispositivi medici, come tali dovranno essere conformi alla legislazione vigente coerentemente con la destinazione d’uso prevista. Nello specifico, ove applicabili, i Dispositivi Medici devono essere conformi al:

• D.lgs 46/1997 e successive integrazioni o modifiche, attuazione della direttiva 93/42/CEE, concernente i dispositivi medici;

• Regolamento (UE) 2017/745 del Parlamento Europeo e del Consiglio del 5 aprile 2017 relativo ai dispositivi medici.

Gli operatori economici sono tenuti a presentare tutta la documentazione comprovante le certificazioni richieste, per ciascuno dei moduli di cui sopra.

3.5 Valutazione del Rischio di Ambito e della complessità della fornitura

Il sistema informatico oggetto del presente Capitolato, in tutti i sui ambiti così come specificato nei Capitoli precedenti (§2.1.1, §2.1.2 ,§2.1.3, § 2.1.4) presenta elevati livelli di complessità. I requisiti di Riservatezza, Integrità e Disponibilità sono da considerarsi ad alto livello di rischio e pertanto dovrà essere compilata la Scheda check di compliance sicurezza e privacy applicativi software (VAC.1) ad ALTO RISCHIO allegata al presente Capitolato (Allegato_5_SchedaCheckCompliance).

4 Processi funzionali ed eventuali sistemi informatici correlati

4.1 Modello Applicativo e descrizione dei Processi

Si riporta di seguito una definizione dei processi che il software dovrà supportare suddiviso nelle macro-fasi

principali che il sistema offerto dovrà gestire nell’ambito del flusso di lavoro implementato.

4.1.1 Processo di gestione dei trasporti di emergenza

Scopo delle funzionalità per l’emergenza territoriale è consentire alle CO118 di fungere da “regia” per tutto il sistema 118, governando e coordinando le attività relative, ottimizzando e razionalizzando l’utilizzo dei Mezzi e delle Persone impegnati sul territorio, con l’obiettivo di migliorare il servizio erogato ai cittadini.

Il sistema di gestione dei trasporti di emergenza deve essere allineato e costantemente aggiornato in base agli accordi aziendali, regionali e integrativi locali nel normale contratto di manutenzione, senza oneri aggiuntivi. La Ditta si deve impegnare a riallineare, nel più breve tempo possibile, il software, i reports e tutto quanto necessario per garantire una celere applicazione di eventuali nuovi accordi e/o modelli organizzativi.

Nell’allegato Allegato_1_Flowchart_Emergenza è rappresentato il processo di gestione dei trasporti di emergenza. Si precisa che tale flow chart deve intendersi come indicativa del processo che la AUSL TSE intende attuare con il supporto del software oggetto di gara. Resta inteso che un’analisi di dettaglio del processo operativo dovrà essere effettuata dalla Ditta aggiudicataria prima della configurazione del software al fine di riscontrare eventuali modifiche organizzative sopraggiunte o differenze operative tra le due CO118 di Arezzo e Siena-Grosseto.

4.1.2 Processo di gestione dei trasporti di urgenza

Scopo delle funzionalità per il servizio di urgenza territoriale (ex “Trasporti Ordinari”) è di coordinare le attività relative, ottimizzare l’utilizzo dei Mezzi e delle Persone coinvolti, permettere una gestione congiunta delle risorse insieme al sistema 118, tramite una gestione unificata, pur prevedendo a priori un’assegnazione preferenziale di ciascuna risorsa a questo o a quel servizio. Il sistema di gestione dei trasporti di urgenza deve essere allineato e costantemente aggiornato in base agli accordi regionali e integrativi locali nel normale contratto di manutenzione, senza oneri aggiuntivi. La Ditta si deve impegnare a riallineare, nel più breve

tempo possibile, il software, i reports e tutto quanto necessario per garantire una celere applicazione di eventuali nuovi accordi territoriali.

Nell’allegato Allegato_2_Flowchart_Urgenza è rappresentato il processo di gestione dei trasporti di urgenza. Si precisa che tale flow chart deve intendersi come indicativa del processo che la AUSL TSE intende attuare con il supporto del software oggetto di gara. Resta inteso che un’analisi di dettaglio del processo operativo dovrà essere effettuata dalla Ditta aggiudicataria prima della configurazione del software al fine di riscontrare eventuali modifiche organizzative sopraggiunte o differenze operative tra le provincie nelle quali si eroga il servizio.

4.1.3 Processo di gestione dei trasporti di continuità Assistenziale

Il sistema informatico dovrà supportare il servizio di continuità assistenziale (ex “Guardia Medica”), sia nella gestione delle telefonate con smistamento delle stesse al personale medico competente/disponibile, sia nella rendicontazione delle prestazioni erogate dai medici di CA.

Il sistema di gestione della continuità assistenziale dovrà essere allineato e costantemente aggiornato in base agli accordi regionali e integrativi nel normale contratto di manutenzione, senza oneri aggiuntivi. La Ditta si deve impegnare a riallineare, nel più breve tempo possibile, il software, i reports e tutto quanto necessario per garantire una celere applicazione di eventuali nuovi accordi territoriali.

Nell’allegato Allegato_3_Flowchart_ContinuitàAssistenziale è rappresentato il processo di gestione del servizio di CA. Si precisa che tale flow chart deve intendersi come indicativa del processo che la AUSL TSE intende attuare con il supporto del software oggetto di gara. Resta inteso che un’analisi di dettaglio del processo operativo dovrà essere effettuata dalla Ditta aggiudicataria prima della configurazione del software al fine di riscontrare eventuali modifiche organizzative sopraggiunte o differenze operative tra le provincie nelle quali si eroga il servizio.

4.1.4 Videocomunicazione avanzata fra assistito e Centrali Operative

Il sistema informatico dovrà supportare la gestione dei pazienti in emergenza fornendo strumenti di comunicazione avanzata con la CO118. In particolare, si richiede che il sistema fornisca almeno le seguenti funzioni:

1. gestione di videochiamate: la Centrale 118 dovrà poter effettuare videochiamate con gli assistiti in possesso di smartphone, senza necessità che questi abbiano installato alcuna app finalizzata a tale scopo;

2. localizzazione GPS del chiamante: il sistema dovrà consentire la localizzazione GPS del chiamante anche se questi ha la funzionalità di localizzazione GPS disattivata sul proprio telefono cellulare;

3. messaggistica istantanea: il sistema dovrà consentire alla CO118 di inviare e ricevere messaggi scritti (“chat”) con gli assistiti coinvolti negli eventi, senza necessità che questi abbiano installato alcuna app finalizzata a tale scopo;

4. traduzione: il sistema dovrà supportare la CO118 nella gestione di assistiti stranieri, al minimo fornendo un servizio di traduzione in/da lingua straniera in tempo reale dei messaggi scritti di cui al punto precedente.

4.2 Contesto Strutturale ed Organizzativo

Il progetto che si vuole realizzare con quanto richiesto nel presente capitolato, insiste sui seguenti ambiti:

• miglioramento dei servizi erogati ai cittadini, evolvendo verso un sistema informativo dinamico, distribuito, che non proponga vincoli tecnologici.

• ottimizzazione dei flussi di lavoro;

• minimizzazione del rischio clinico;

• gestione paperless della documentazione;

• reingegnerizzazione del flusso di lavoro;

• semplificazione dell’interfaccia utente (118, Centrale di 2° Livello, AA.VV./CRI, Continuità

Assistenziale);

• miglioramento reportistica ed analisi sui dati relativi ai processi gestiti.

4.3 Integrazioni con sistemi interni ed esterni

Il presente capitolato riguarda quattro ambiti:

• Servizio di emergenza territoriale (Centrali Operative 118);

• Servizio di trasporti di urgenza (ex “Ordinari” - Centrale di II Livello);

• Servizio di continuità assistenziale;

• Servizio di videocomunicazione avanzata fra assistito e Centrali Operative 118.

Qualora il fornitore intenda offrire quanto sopra tramite software separati, si dà per sott’inteso la presenza di uno layer software che renda trasparente all’utilizzatore il passaggio tra di essi, che dovranno pertanto nativamente interessi fra di loro integrati.

Tutte le integrazioni descritte sotto dovranno essere implementate nel rispetto di quanto indicato nel §4.3, verificando l’esistenza di eventuali versioni aggiornate al momento dell’avvio del progetto. I dettagli tecnici delle integrazioni devono essere oggetto dell’offerta tecnica al presente capitolato in termini di soluzione proposta e secondo le modalità di integrazione rese necessarie sulla base dei fornitori dei servizi invocati.

In considerazione dell’obiettivo della stazione appaltante, descritto nel Documenti di definizione ambiente tecnologico, di implementare un modello di tipo service-oriented abbandonando progressivamente logiche application-oriented, le ditte concorrenti dovranno considerare di redigere offerte tecniche coerenti con tali indicazioni; qualora il sistema offerto non sia, nella sua prima installazione, pienamente aderente al modello service-oriented, dovranno essere indicate le tempistiche, a partire dall’ordine di fornitura, entro cui il sistema offerto evolverà verso tale approccio, senza oneri aggiuntivi. Tali tempistiche non potranno essere superiori a 240 giorni solari.

Lo sviluppo e l’implementazione delle integrazioni in oggetto lato fornitore si intende a carico della ditta aggiudicataria, mentre lato applicativi integrati sarà da considerarsi a carico della stazione appaltante che prenderà accordi specifici con i relativi fornitori.

In caso di variazioni normative o dei protocolli di intesa (vd. Protocollo di Intesa Ministeriale CUR NUE 112) si intendono compresi nell’offerta e a carico dell’aggiudicatario le relative attività di adeguamento delle integrazioni per tutta la durata del contratto.

4.3.1 Integrazioni obbligatorie

Di seguito un dettaglio delle integrazioni che dovranno obbligatoriamente far parte della fornitura22:

Sistema Informatico

Istanza

Fornitore

Nome software

Macro-obiettivi

dell’integrazione

Integrazione già

esistente con gli attuali software?

Rif. Specifiche

Anagrafe

pazienti regionale

Regionale

Dedalus

Orfea

Ricerca e censimento dati anagrafici pazienti

(il software attuale si

integra per l’anagrafe

RFC249

22 Nella tabella laddove riportata genericamente la provincia si fa riferimento agli Ospedali di AUSL TSE ivi ubicati (cfr. nota Errore. I l segnalibro non è definito.5).

con altro sistema informatico)

ADT

Arezzo

GPI

Degenza

Richieste trasferimenti/consulenze intraospedalieri (urgenza o emergenza) e dimissioni.

(da reingegnerizzare)

da realizzare

(da RFC123)

Siena

Data Processing

Ricoveri

Grosseto

Data Processing

Ricoveri

AOUS

Exprivia

Aurora

Arezzo

GPI

DEU

Condivisione dati missione/paziente destinato a PS, riconciliazione anagrafica pazienti trasportati da 118, condivisione dati di esito

dimissione da PS, richieste trasporti

(da reingegnerizzare)

RFC134 (CO118 🡪 PS)

RFC 106 (PS 🡪 CO118)

Grosseto e Siena

Dedalus

FirstAid

AOUS

Exprivia

AuroraPS

Gestionale AA.VV./CRI

In uso da circa 20

AA.VV. / CRI

Gruppo Informatico23

SmartGAV

Condivisione dati trasporti di emergenza ed urgenza eseguiti dalle AA.VV./CRI

Webservices

Sistema di Accoglienza Regionale

Regionale

Regione Toscana

SAR

Recupero dati NRE di richiesta trasporto di

urgenza, aggiornamento stato NRE

RFC231

E-prescription

Regionale

Dedalus

Sire3

Prescrizione elettronica per continuità assistenziale

Chiamate in contesto

Repository

Arezzo, Siena,

Grosseto

Gmed

Repository XDS

Consultazione documentazione presente nel repository, eventuale invio schede firmate digitalmente dai servizi oggetto di fornitura (schede

evento ecc…)

Affinity Domain e Standard XDS

AOUS

APP 118

Unica

In fase di affidamento

Condivisione dati missione corredati dai dati delle rilevazioni effettuate con gli elettromedicali e raccolti

dalla APP

da realizzare

Sistema radio

Unica

In fase di aggiornamento

Condivisione degli stati missione ed altri dati caratterizzanti la missione

(con i sistemi attuali in fase di aggiornamento / sostituzione)

da realizzare

Sistemi di fonia e registrazione

N.A.

In fase di aggiornamento

I sistemi dovranno integrarsi con i sistemi di raccolta e registrazione chiamate consentendo la consultazione ed il riascolto da parte della CO118, della

CO II Livello e della CA delle registrazioni

(con i sistemi attuali in fase di aggiornamento / sostituzione)

da realizzare

Cataloghi aziendali

Unica

Onit

Allinea

RCT - tabelle di riferimento di regione toscana, fra

queste si evidenziano in particolare:

RFC178

23 Attualmente tutte le AA.VV./CRI che non dispongono di un proprio applicativo, utilizzano uno stesso software (unico fornitore). In futuro potrebbero essere acquisiti dalle AA.VV./CRI nuovi applicativi, che eventualmente si integreranno con il gestionale AUSL TSE secondo le stesse specifiche tecniche.

				◦ COMUNI ◦ STATI ◦ INTERVENTI ◦ DIAGNOSI_ICD9_CM ◦ ESENZIONI ◦ AZIENDECOMUNI ◦ FARMACI ◦ AZIENDE_SANITARIE Catalogo unico prestazioni Discipline • Medici interni, esterni e convenzionati • Elenco personale medico e sanitario • Centri di Costo, specialità
Datawarehouse aziendale	Unica	Onit	DWH	Messa a disposizione di dati	NO	Webservices
Debiti informativi				Invio messaggistica e generazione flussi verso Regione Toscana e/o Ministero		RFC134 Altri da normativa
CUR 112				Scambio di informazioni come da Protocollo di Intesa Ministeriale CUR NUE 112
Autenticazione centralizzata	ASLTSE		Anagrafe Soggetti / LDAP	Autenticazione al sistema informatico su sistemi centralizzati	NO	LDAPS
Autenticazione centralizzata	Regionale		ARPA		NO	RFC180

Il Sistema di videocomunicazione avanzata fra assistito e Centrali Operative 118, dovrà integrarsi con i gestionali utilizzati dalle Centrali Operative 118 della RT (2 per Area Vasta Centro, 2 per Area Vasta Nord Ovest) e dalla CUR, oltre che con quanto previsto nel presente Capitolato.

4.3.2 Integrazioni opzionali

Oltre alle integrazioni del paragrafo precedente, il fornitore dovrà essere in grado di integrarsi con altri sistemi come meglio sottoelencato:

Sistema Informatico	Macro-obiettivi dell’integrazione
UTIC	Ottimizzazione del percorso per la gestione di stroke e stemi
RIS	Ottimizzazione del percorso per la gestione del politrauma
Terapie Intensive	Ottimizzazione del percorso per la gestione della sepsi
Vari	Ottimizzazione del percorso di ulteriori patologie tempo dipendenti
Identità Digitale	Gestire l’accesso al sistema informativo tramite il sistema SPID/CNS
Firma Digitale	Consentire la firma digitale della documentazione prodotta dl sistema informatico
Sistema di comunicazione satellitare	Condivisione degli stati missione ed altri dati caratterizzanti la missione

Particolare attenzione dovrà essere dedicata alle integrazioni necessarie alla gestione dei c.d. “Percorsi tempo dipendenti” (DGRT n. 1106 del 28/10/2021). Il fornitore dovrà illustrare tutte le azioni che è in grado

di intraprendere sui propri sistemi informatici al fine di adeguarsi alle nuove versioni dei protocolli operativi e RFC di Regione Toscana.

5 Requisiti Funzionali e Tecnologici del sistema

La fornitura deve includere le funzionalità che seguono, classificate secondo la tematica delle funzioni.

5.1 Requisiti Funzionali

Si riportano nel seguito le caratteristiche generali che il sistema deve avere oltre ai requisiti espressi nei capitoli precedenti. Tali caratteristiche hanno carattere obbligatorio eccetto quelle espressamente indicate come migliorative e/o preferenziali, come meglio spiegato nella legenda seguente.

Legenda:

Obbligatorio: requisito indispensabile pena l’esclusione

Preferenziale: requisito non indispensabile ma che qualifica positivamente una offerta rispetto ad un’altra

Migliorativo: requisito non indispensabile che la commissione si riserva di valutare come proposta migliorativa

ID	Requisito	Obbligatorio/ Migliorativo/ Preferenziale
R1	Tutta la documentazione (manuali, video tutorial ecc..) prodotta dovrà essere in lingua italiana, così come le funzionalità del software (pulsanti, etichette ecc…).	Obbligatorio
R2	Tutta la documentazione (manuali, video tutorial ecc..) dovrà essere aggiornata, almeno in seguito a cambi di releases significativi (major releases).	Obbligatorio
R3	Disponibilità di servizi on line a supporto dell’apprendimento e dell’uso del software. Esempio: • Video Tutorial in linea: ovvero piattaforme interattive e navigabili per imparare velocemente ad usare il software, con i problemi più frequenti risolti/descritti mediante appositi video; a tali piattaforme si deve poter accedere direttamente da menù dell’applicativo; • Forum: ovvero uno spazio virtuale dedicato agli operatori per lo scambio di esperienze, al confronto e alla discussione; • Help on line: ovvero un motore di ricerca per trovare le soluzioni nel Video Tutorial e nel Forum NB: Tutti questi strumenti devono essere mantenuti aggiornati alla versione corrente del software per tutta la durata dell’appalto.	Obbligatorio

5.1.1 Sistema di emergenza territoriale

ID	Requisito	Obbligatorio/ Migliorativo/ Preferenziale
E4	POT/Barra Telefonica unificata indipendente dai sistemi telefonici ed integrata con il gestionale per l’apertura della scheda contatto.	Obbligatorio
E5	Gestione rubrica telefonica integrata con il POT/Barra telefonica ma consultabile anche offline.	Obbligatorio
E6	Ricezione chiamata e scheda contatto dalla CUR (con generazione automatica del numero CAL).	Obbligatorio

ID	Requisito	Obbligatorio/ Migliorativo/ Preferenziale
E7	Apertura di eventi, partendo dalla ricezione di chiamate telefoniche su POT (non ricevute dalla CUR), riportando in tal caso nella scheda di gestione i dati relativi al numero telefonico chiamante, oppure tramite apertura manuale.	Obbligatorio
E8	Gestione delle schede contatto/intervento/evento/paziente.	Obbligatorio
E9	Gestione dell’entità “Località”, con rapporto “n:1” rispetto all’entità “Comune” (ad ogni comune possono essere associate n località, ma ogni località appartiene esclusivamente ad un comune). L’inserimento dell’indirizzo dell’evento dovrà consentire, oltre alla compilazione dei campi “Via/Piazza/Viale...” e “Comune”, anche l’eventuale compilazione del campo “Località”.	Obbligatorio
E10	Integrazione con il servizio di anagrafica regionale.	Obbligatorio
E11	Attribuzione tipologia di intervento (primario, secondario, informazioni utenza…). Particolare attenzione dovrà essere dedicata alle informazioni necessarie alla gestione dei c.d. “Percorsi tempo dipendenti” (DGRT n. 1106 del 28/10/2021). Il fornitore dovrà illustrare tutte le azioni che è in grado di intraprendere sui propri sistemi informatici al fine di adeguarsi alle nuove versioni dei protocolli operativi e RFC di Regione Toscana.	Obbligatorio
E12	Il Sistema deve prevedere protocolli di intervista che facilitino gli operatori nell’individuazione del livello di gravità delle chiamate.	Obbligatorio
E13	Inserimento e aggiornamento dei protocolli di intervista di cui al punto precedente.	Preferenziale
E14	Valorizzazione del livello di emergenza (codice colore).	Obbligatorio
E15	Inserimento delle Istruzioni Pre-Arrivo per l’erogazione al cittadino durante il dispatch.	Obbligatorio
E16	Funzionalità per l’inserimento e l’aggiornamento delle istruzioni Pre-Arrivo di cui al punto precedente.	Obbligatorio
E17	Attivazione dei mezzi di soccorso e gestione degli interventi.	Obbligatorio
E18	Gestione del passaggio di consegne a fine turno (bacheca elettronica).	Obbligatorio
E19	Gestione turnistica del personale.	Preferenziale
E20	Calendario della turnistica delle AA.VV./CRI sui PET (con storicizzazione dei turni effettuati), con visualizzazione grafica delle coperture/turni programmati e presenza di alert per gli operatori di CO118 in caso di PET con fasce orarie non garantite.	Obbligatorio
E21	Gestione del processo di inserimento dei turni sui punti PET da parte delle AA.VV./CRI e di validazione da parte della CO118.	Preferenziale
E22	Integrazione con la app installata sui tablet per l’attivazione dei mezzi di soccorso e per l’aggiornamento delle schede missione/soccorso (in particolare, si richiede che i dati relativi alle missioni/trasporti di emergenza siano integrabili e modificabili contemporaneamente sia attraverso la app della AUSL TSE, sia attraverso il gestionale oggetto di gara, con segnalazione all’utente che ha la funzionalità aperta di successiva modifica del dato inserito da parte di altro utente).	Obbligatorio
E23	Integrazione con sistema radio per la trasmissione degli stati missione e la comunicazione sui canali utilizzati dal servizio di emergenza.	Obbligatorio
E24	Modulo per la gestione della cartografia, con possibilità di visualizzare su mappa tutte le informazioni gestite dal sistema informatico, aggiornate dal sistema con refresh automatici (localizzazione del target, dei mezzi in stazionamento ed in movimento, dei POI, degli eventi attivi e relativa gravità/codice attivazione/codice rientro, ecc…). Il Sistema deve essere d’ausilio, tramite le informazioni Toponomastiche e Cartografiche: • di supportare l’Operatore nella corretta determinazione del Luogo dell’intervento (visualizzazione automatica nel cartografico della localizzazione del target); • di consentire alla CO118 di governare e supportare i mezzi sul territorio, grazie alla consultazione dei mezzi di soccorso attivi e liberi, con visualizzazione in cartografia della posizione in tempo reale, correlata anche ad eventi di traffico/chiusura strade sul territorio;	Obbligatorio

Requisito

Obbligatorio/ Migliorativo/ Preferenziale

• di supportare la CO118 nella gestione di eventi in situazioni particolari (eventi quali fiere, sagre ecc.., eventi di particolare entità, maxiemergenze), permettendo la visualizzazione su mappa delle aree interessate, degli eventi attivi ecc...

E25

Layer sovrapponibile alla cartografia implementabile dalla CO118 attraverso inserimento di enti, dispositivi, siti di atterraggio per elisoccorso ed annotazione di punti di interesse (POI).

Obbligatorio

E26

Interfaccia con cartografie di terze parti e/o proprietarie della AUSL TSE e/o dei Comuni dell’AVTSE

(es. SIT).

Obbligatorio

E27

Il Sistema deve essere in grado, in base a parametri configurabili, di segnalare automaticamente all’operatore che la chiamata in corso sia potenzialmente il duplicato di una già ricevuta. Deve quindi rendere possibile, su richiesta, un raffronto diretto della/e chiamata/e già censite e quindi permettere l’accorpamento dei nuovi dati in caso di reale duplicazione o la normale gestione se si trattasse di chiamata diversa.

Obbligatorio

E28

Il Sistema deve segnalare la necessità di attivazione degli altri Enti per portare a termine l’Intervento,

distinguendo tra Enti attivati e da attivare.

Obbligatorio

E29

Il Sistema deve gestire la funzione di attivazione del Medico di Centrale Operativa 118 con l’evidenziazione di una richiesta di consulto sul video della postazione a lui dedicata e la possibilità di visualizzare ed integrare i dati relativi alla richiesta di Intervento.

Obbligatorio

E30

Il Sistema deve essere in grado di suddividere il Territorio in zone omogenee per:

• delimitare le aree di intervento dei Mezzi,

• delimitare il bacino di afferenza dei Presidi Ospedalieri,

• delimitare le aree di intervento degli altri Enti, etc...

Obbligatorio

E31

Il Sistema, in base alla caratterizzazione della scheda evento, deve essere in grado di suggerire una lista di mezzi in funzione dell’adeguatezza per competenza territoriale ed assistenziale. Deve essere possibile l’assegnazione, se necessario, di un mezzo non di turno al momento della chiamata, per far fronte all’utilizzo di mezzi estemporanei o provenienti da altre Province.

Obbligatorio

E32

Il Sistema, in base alle informazioni raccolte durante l’intervento e alla tipologia del mezzo intervenuto, deve essere in grado di suggerire il presidio ospedaliero ottimale di destinazione.

Obbligatorio

E33

Il Sistema dovrà essere in grado di gestire i rendez-vous, ossia coordinare l’invio di più mezzi o in

caso della necessità di trasporto di più pazienti o per esigenze di carico-scarico.

Obbligatorio

E34

Tutte le fasi dell’Intervento, compreso eventuale rendez-vous e fermo per passaggio a livello, devono essere memorizzate dal Sistema ed associate ai dati orari di ciascuna. La marcatura degli orari dovrà avvenire sia in modo manuale, con intervento da parte dell’operatore, sia in modo automatico, fruendo degli stati con data/ora certi resi disponibili dalla app o dal sistema radio. Il sistema dovrà tracciare e dare evidenza delle due differenti modalità di inserimento. Il sistema dovrà consentire di associare/gestire alle tratte del trasporto soste tecniche presso strutture ospedaliere diverse da quella di destinazione.

Obbligatorio

E35

Qualunque modifica apportata ai dati delle schede deve essere tracciata e facilmente consultabile da parte degli operatori di CO118, che devono essere in grado di risalire a data/orario e operatore dell’ultimo aggiornamento.

Obbligatorio

E36

Il Sistema dovrà consentire la gestione del flusso di richiesta/approvazione/assegnazione della classe di Eherenwerth, permettendo di gestire la programmazione di trasferimenti di emergenza futuri (si rimanda alla flow chart rappresentata nell’Allegato_1_Flowchart_Emergenza).

Il sistema dovrà notificare gli operatori di CO118 ricordando la necessità di attivare i mezzi per i trasferimenti programmati.

Obbligatorio

E37

Il Sistema dovrà gestire un’agenda gare e manifestazioni, con indicazione dell’evento, del periodo di interesse (data da-a, fascia oraria), stazionamento, mezzi di soccorso, Ente, numeri di telefono, zone geografiche interessate (con indicazione delle zone corrispondenti sul cartografico).

Il Sistema dovrà offrire la possibilità di registrare interventi collegati alla gara/manifestazione, in modo che siano esclusi dalla rendicontazione AUSL TSE a carico del SSRT/Aziendale.

Dovranno essere presenti specifici alert/messaggi che avvisino l’operatore di CO118 della presenza

di gare/manifestazioni impattanti nel luogo ed al momento dell’evento.

Obbligatorio

ID	Requisito	Obbligatorio/ Migliorativo/ Preferenziale
E38	Il Sistema dovrà essere in grado di fornire supporto nelle attività di pianificazione e gestione di maxi emergenze sia in fase di allerta che in fase di allarme.	Obbligatorio
E39	Il Sistema dovrà produrre alert configurabili (bloccanti e non bloccanti) che avvisino gli operatori di situazioni particolari, riscontrate dal gestionale anche attraverso interrogazioni agli altri applicativi con esso integrati (es. alert per l’infermiere dispatch in caso di positività ad infezioni particolari, paziente che effettua TAO, presenza di accessi in PS nelle 72 ore precedenti all’evento, ecc...)	Preferenziale
E40	Il Sistema si dovrà integrare con i software utilizzati dai XX.XX. dell’AVTSE per la condivisione dei dati relativi ai pazienti trasportati.	Obbligatorio
E41	Integrazione con il repository XDS aziendale per la consultazione dei referti in esso archiviati.	Obbligatorio
E42	Consultazione in tempo reale di dati e documenti raccolti dagli elettromedicali dei mezzi di soccorso sul territorio (tali dati e documenti saranno raccolti dalla app in fase di acquisizione, ma dovranno essere consultabili in tempo reale anche sul gestionale da parte della Centrale 118).	Obbligatorio
E43	Integrazione con gli applicativi utilizzati per la gestione dei c.d. “Percorsi tempo dipendenti” (DGRT n. 1106 del 28/10/2021) quali ad esempio, i gestionali delle UTIC dell’AVTSE per la trasmissione dei tracciati ECG e per la gestione del teleconsulto cardiovascolare, i sistemi RIS ecc…	Migliorativo
E44	Interfaccia utente per il riascolto delle telefonate registrate (ed archiviate nel sistema di registrazione) direttamente dalle schede intervento/evento/missione, alle quali la registrazione telefonica dovrà essere collegata.	Obbligatorio
E45	Servizi per la rendicontazione a RT dei dati dei trasporti effettuati (RFC 134).	Obbligatorio
E46	Integrazione con i software di ADT di AVTSE (AUSL TSE ed AOUS) per la richiesta, da parte dei reparti ospedalieri, dei trasporti per dimissioni o trasferimenti.	Obbligatorio
E47	Funzionalità per consentire ai reparti ospedalieri (AUSL TSE ed AOUS) di richiedere trasporti per dimissioni o trasferimenti, tramite accesso ad apposito portale di richiesta trasporto (da attivarsi in attesa della integrazione di cui al punto precedente).	Obbligatorio
E48	Dovrà essere possibile attivare la funzionalità di cui al punto precedente anche per case di cura/strutture socio-sanitarie private e/o convenzionate con l’AUSL TSE.	Preferenziale
E49	Integrazione con il software delle AA.VV./CRI per lo scambio dei dati dei trasporti di emergenza.	Obbligatorio
E50	Funzionalità, tramite portale web, accessibile alle AA.VV./CRI per l’inserimento dei dati a corredo della missione (da attivarsi per le AA.VV./Cri che non utilizzano un gestionale proprio ma soltanto quello del 118).	Obbligatorio
E51	Funzionalità per la validazione e rendicontazione dei trasporti di emergenza effettuati dalle AA.VV./CRI, per la gestione dei processi amministrativi di supporto da parte dell’ufficio trasporti AUSL TSE.	Obbligatorio
E52	Servizio di censimento dei BLSD, personale formato ed invio sms, scatenato alla registrazione di eventi sul territorio che richiedono l’utilizzo di defibrillatore, con destinatari i cittadini che nella banca dati del 118 risultano avere conseguito la certificazione BLSD e che risultano geolocalizzati in posizione prossima al luogo dell’evento, eventualmente anche tramite integrazione con servizio esterno.	Obbligatorio
E53	Funzionalità per il censimento e la profilazione dei giornalisti accreditati (abilitati alla ricezione degli SMS ed alla consultazione della pagina web relativa ad eventi pubblici). Tale abilitazione potrà essere fornita, oltre che dall’amministratore del sistema, anche dal personale dell’Ufficio Stampa AUSL TSE. Servizio di invio sms, scatenato al verificarsi di determinate condizioni (eventi di rilevanza pubblica accertati), destinato ai giornalisti accreditati. Pagina Web per la consultazione, da parte degli uffici stampa AUSL TSE e dei giornalisti accreditati, degli eventi registrati dal 118 di rilevanza pubblica. Tale pagina dovrà essere raggiungibile tramite internet (anche esternamente alla rete intranet della AUSL TSE).	Preferenziale
E54	Chat per la comunicazione rapida tra gli operatori della CO 2°Livello, delle AA.VV./CRI e della CO118.	Preferenziale
E55	Reportistica nei format richiesti da Regione Toscana (es. numero viaggi, km Percorsi, Stand By/non in convenzione, ecc…).	Obbligatorio

Requisito

Obbligatorio/ Migliorativo/ Preferenziale

E56

Al momento dell’apertura di una scheda, qualora il sistema rilievi degli episodi aperti in tempi recenti (range configurabile) di Continuità Assistenziale, dovranno essere evidenziati degli alert opportuni e dovrà essere consentita la visualizzazione delle schede di CA.

Obbligatorio

5.1.2 Sistema di urgenza territoriale

ID	Requisito	Obbligatorio/ Migliorativo/ Preferenziale
U1	POT/Barra Telefonica unificata indipendente dai sistemi telefonici ed integrata con il gestionale per l’apertura della scheda contatto.	Obbligatorio
U2	Gestione rubrica telefonica integrata con il POT/Barra telefonica ma consultabile anche offline.	Obbligatorio
U3	Possibilità di gestire conferenze e trasferimenti di chiamata direttamente dal POT/Barra telefonica.	Obbligatorio
U4	Apertura/compilazione scheda di prenotazione, differenziato rispetto alle tipologie di trasporto (es. trasporto per dialisi, trasporto per chemioterapia, trasporto per accertamenti diagnostici, trasporto per consulenza, ecc..). Il sistema dovrà consentire tale possibilità: alla CO 2° Livello; alle AA.VV./CRI, tramite il loro gestionale (integrato con quello oggetto di gara), oppure tramite accesso di queste ultime al software della CO 2°Livello (attraverso pagina web raggiungibile da rete internet); a reparti ospedalieri, case di cura, residenze socio-sanitarie, tramite il software di ADT (integrato con quello oggetto di gara), oppure tramite accesso di queste ultime al software della CO 2°Livello (attraverso pagina web raggiungibile da rete internet).	Obbligatorio
U5	Integrazione con il servizio di anagrafe degli Assistiti, con possibilità di integrarne i dati necessari es. (indirizzo), ma anche di ricavare dal servizio interrogato tutti i dati utili alla prenotazione del trasporto.	Obbligatorio
U6	Il Sistema dovrà supportare l’operatore nella decisione dell’adeguatezza e della rimborsabilità del trasporto al cittadino secondo regole e accordi regionali/aziendali (es. servizio non rimborsabile per pazienti non residenti in Regione Toscana).	Obbligatorio
U7	Gestione del passaggio di consegne a fine turno (bacheca elettronica).	Preferenziale
U8	Gestione turnistica del personale integrata con la rilevazione presenze.	Migliorativo
U9	In caso di prenotazione non inserita da una AA.VV./CRI, il sistema dovrà consentire l’attribuzione dei trasporti alle varie AA.VV./CRI operanti sul territorio attraverso algoritmi che possono variare nel tempo col variare degli accordi aziendali/territoriali. Tali algoritmi si baseranno prevalentemente sullo storico dei trasporti effettuati in regime di urgenza. Il sistema dovrà prevedere in tempo reale l'accettazione e/o il rifiuto del servizio, proponendo la missione alla successiva AA.VV./CRI in lista. Il sistema dovrà memorizzare per singola AA.VV./CRI tutti i rifiuti/accettazioni. Le variazioni necessarie dovranno essere effettuate a cura della Ditta aggiudicataria nel normale contratto di manutenzione.	Obbligatorio
U10	Il sistema dovrà consentire alla CO 2° Livello la validazione delle prenotazioni inserite dalle AA.VV./CRI.	Obbligatorio
U11	Il Sistema dovrà supportare il personale della CO 2° Livello al fine di ottimizzare le risorse utilizzate per i trasporti (massimizzando l’occupazione dei mezzi di trasporto, minimizzando il numero dei mezzi attivati, suggerendo il mezzo più idoneo al trasporto da effettuare in base ai percorsi ecc…). Il sistema dovrà consentire l’accorpamento di più pazienti/richieste di trasporto all’interno dello stesso viaggio.	Obbligatorio
U12	Il Sistema dovrà consentire la chiusura e l’archiviazione di ogni singolo servizio, sia manualmente sia con procedure automatiche al verificarsi di determinate condizioni configurabili.	Obbligatorio
U13	Modulo per la gestione della cartografia, con possibilità di visualizzare su mappa tutte le informazioni relative ai mezzi attivi in regime di urgenza, ai trasporti programmati e in corso, con visualizzazione dello stato (in sosta, in viaggio..).	Obbligatorio

ID	Requisito	Obbligatorio/ Migliorativo/ Preferenziale
	Il Sistema dovrà essere d’ausilio, tramite le informazioni Toponomastiche e Cartografiche, al fine di supportare la CO 2° Livello nella corretta determinazione degli indirizzi.
U14	Il Sistema dovrà essere d’ausilio per la gestione di trasporti di urgenza in presenza di situazioni particolari, permettendo la visualizzazione su mappa delle aree interessate da eventi rilevanti (es. fiere, sagre ecc..), anche in caso di inserimento di tali situazioni particolari da parte della CO 118.	Preferenziale
U15	Il Sistema dovrà essere in grado, in base a parametri configurabili, di segnalare automaticamente all’operatore che la prenotazione inserita sia potenzialmente il duplicato di una pre-esistente. Dovrà quindi rendere possibile, su richiesta, un raffronto diretto delle prenotazioni già censite e quindi permettere l’accorpamento/annullamento dei dati o la normale gestione.	Obbligatorio
U16	Tutte le fasi del trasporto dovranno essere memorizzate dal Sistema ed associate ai dati orari di ciascuna. La marcatura degli orari dovrà avvenire sia in modo manuale, con intervento da parte dell’operatore, sia in modo automatico, fruendo degli stati con ora certi resi disponibili dalla app sui mezzi di urgenza oggetto di fornitura. Il sistema dovrà tracciare e dare evidenza delle due differenti modalità di inserimento.	Obbligatorio
U17	Qualunque modifica apportata ai dati delle schede dovranno essere tracciate e facilmente consultate da parte degli operatori di CO 2°Livello, che dovranno essere in grado di risalire a data/orario e operatore dell’ultimo aggiornamento.	Obbligatorio
U18	Interfaccia utente per il riascolto delle telefonate registrate (ed archiviate nel sistema di registrazione) direttamente dalle schede trasporto, alle quali la registrazione telefonica dovrà essere collegata.	Obbligatorio
U19	Integrazione con i software di ADT di AVTSE (AUSL TSE ed AOUS) per la richiesta, da parte dei reparti ospedalieri, dei trasporti per dimissioni, visite o consulenze.	Obbligatorio
U20	Funzionalità per consentire ai reparti ospedalieri di richiedere trasporti per dimissioni, visite o consulenze (da attivarsi in attesa della integrazione di cui al punto precedente, attraverso pagina web raggiungibile anche esternamente alla rete intranet AUSL TSE).	Obbligatorio
U21	Dovrà essere possibile attivare la funzionalità di cui al punto precedente anche per case di cura/strutture socio-sanitarie private e/o convenzionate.	Preferenziale
U22	Integrazione con il software delle AA.VV./CRI per lo scambio dei dati dei trasporti di urgenza.	Obbligatorio
U23	Funzionalità, accessibile tramite servizio web esposto esternamente alla rete AUSL TSE, utilizzabile dalle AA.VV./CRI per l’inserimento dei dati a corredo della missione (da attivarsi per le AA.VV./CRI che non dispongono di un gestionale proprio).	Obbligatorio
U24	App da installare su eventuali smartphone/tablet delle AA.VV./CRI per l’invio al gestionale della CO 2° Livello degli stati di avanzamento della missione (“tratte”) e dei dati inerenti il trasporto di urgenza effettuato (equipaggio, kilometri iniziali e finali ecc…), nonché per la navigazione assistita verso la struttura di destinazione e/o il domicilio del paziente. disponibile per Sistema Operativo Android e IOS.	Obbligatoria
U25	Rendicontazione, secondo gli accordi regionali/locali, dei trasporti effettuati con relativi report da inviare a consuntivo alle AA.VV./CRI.	Obbligatorio
U26	Sistema di messaggistica (chat) per la comunicazione rapida tra gli operatori della CO2°Livello, delle AA.VV./CRI e della CO118.	Preferenziale
U27	Gestione dei mezzi di trasporto in dotazione alle singole AA.VV./CRI con differenziazione della tipologia e delle specifiche dei mezzi (mezzo attrezzato singolo, mezzo attrezzato collettivo, pulmino per trasporti collettivi etc).	Obbligatorio
U28	Il sistema dovrà generare alert di anomalie in caso di utilizzo del solito mezzo su più servizi contemporaneamente.	Obbligatorio
U29	Gestione dei dati previsti dalla reportistica UTIF (es. nominativi equipaggio, kilometri iniziali e finali, kilometri percorsi, soste, percorrenze..).	Obbligatorio
U30	Visualizzazione tabellare e su calendario dei servizi con colorazioni/layout diversi a seconda delle caratteristiche (tipologia, tipo mezzo, provincia, stato ecc..).	Obbligatorio
U31	Gestione dei seguenti attributi minimali associati ad ogni trasporto: Dati servizio: Partenza (provincia, comune, località, indirizzo, civico, piano, orario, ascensore, rampa scale) Destinazione (provincia, comune, località, indirizzo, civico, piano, orario, ascensore, rampa scale, ospedale, reparto) Dati Assistito Anagrafica Patologie	Obbligatorio

ID	Requisito	Obbligatorio/ Migliorativo/ Preferenziale
	Allergie Peso Particolarità (es. grande obeso) Deambulazione Telefono Dati inerenti al servizio Numero di telefono Chiamata da (valorizzato in caso di richiesta fatta telefonicamente e non inserita direttamente da reparto/AA.VV./CRI) Riferimento / Contatto Causa Tipologia mezzo Tipologia viaggio Medico Richiedente Reparto e Ospedale Richiedente Numero Ricetta (NRE) Ricetta (allegato pdf/immagine)
U32	Gestione dei servizi continuativi (o cicli), schedulabili in maniera ripetitiva per un certo periodo / in determinate date (es. trasporto di paziente per dialisi, terapie riabilitative, chemioterapia, radioterapia, ecc...).	Obbligatorio
U33	In caso di cicli / servizi continuativi, visualizzazione per ogni viaggio della prescrizione di riferimento e del relativo numero (es. 4/10 – 5/10 ecc..)	Obbligatorio
U34	Possibilità, per la CO 2° Livello e per le AA.VV./CRI, di inserire richieste di trasporto (anche di servizi continuativi) con data esecuzione passata.	Obbligatorio
U35	Gestione dei servizi sospesi (missioni successive ad oggi).	Obbligatorio
U36	Presenza di alert configurabili (bloccanti e non bloccanti) che avvisino gli operatori di situazioni particolari, riscontrate dal gestionale anche attraverso interrogazioni agli altri applicativi con esso integrati (es. alert in caso di trasporto richiesto per un cittadino non residente in Regione Toscana).	Obbligatorio
U37	Rapido accesso per la consultazione della prescrizione associata ad ogni richiesta di trasporto direttamente dalla lista principale (minimizzando il numero di “click” per gli utenti).	Obbligatorio
U38	Il sistema dovrà consentire all’Ufficio Trasporti AUSL TSE di elaborare apposito report di riepilogo/rendicontazione per singola AA.VV./CRI, relativamente a periodi temporali, tipologia mezzo utilizzato, tipologia di trasporto (dialisi, visite, chemioterapie, radioterapie, dimissioni ecc..). Si richiede la presenza di alert, configurabili e personalizzabili, che segnalino agli utenti la presenza di eventuali anomalie (es. servizio con durata/kilometri percorsi/importo eccessivi). L’Ufficio Trasporti dovrà avere la possibilità di modificare all’occorrenza anche servizi archiviati, con notifica per l’AA.VV./Cri che li ha erogati.	Obbligatorio
U39	Alta flessibilità nella configurazione delle regole di determinazione degli importi dei trasporti (es. in caso di viaggi di andata e ritorno dovrà essere riconosciuta una sola attivazione).	Obbligatorio
U40	Valorizzazione del costo del trasporto al termine dello stesso, con visualizzazione dell’importo calcolato anche da parte dell’AA.VV./CRI che lo ha erogato.	Obbligatorio
U41	Possibilità di filtrare i report generati in fase di validazione/rendicontazione per periodo (anche per intervalli temporali personalizzabili), per tipologia di trasporto...	Obbligatorio
U42	Strumenti di reporting (a titolo esemplificativo e non esaustivo: dettagli per servizio, riepilogo servizi complessivo, per singola AA.VV.CRI, per destinazione con evidenza dei kilometri percorsi…).	Obbligatorio
U43	Report nel format richiesto da Regione Toscana (es. numero viaggi, km Percorsi..).	Obbligatorio
U44	Integrazione con il Sistema TS per la consultazione della prescrizione elettronica.	Preferenziale

5.1.3 Sistema di continuità assistenziale

ID	Requisito	Obbligatorio/ Migliorativo/ Preferenziale
CA1	POT/Barra Telefonica unificata indipendente dai sistemi telefonici ed integrata con il gestionale per l’apertura della scheda contatto.	Xxxxxxxxxxxx
XX0	Gestione rubrica telefonica integrata con il POT/Barra telefonica ma consultabile anche offline.	Xxxxxxxxxxxx
XX0	Possibilità di gestire conferenze e trasferimenti di chiamata direttamente dal POT/Barra telefonica.	Xxxxxxxxxxxx
XX0	Apertura/compilazione scheda contatto. Il sistema dovrà consentire l’apertura di un evento in automatico partendo dalla ricezione di una chiamata telefonica, riportando, in tal caso, nella scheda di gestione i dati relativi al numero telefonico chiamante, oppure tramite apertura manuale. Il sistema dovrà consentire l’assegnazione della scheda contatto, individuando il medico sulla base della competenza territoriale.	Xxxxxxxxxxxx
XX0	Integrazione con il servizio di anagrafe degli Assistiti, con possibilità di integrarne i dati necessari es. (indirizzo), ma anche di ricavare dal servizio interrogato tutti i dati utili alla prenotazione del trasporto.	Xxxxxxxxxxxx
XX0	Gestione del passaggio di consegne a fine turno (bacheca elettronica).	Preferenziale
CA7	Gestione turnistica del personale integrata con la rilevazione presenze.	Migliorativo
CA8	Gestione dell’entrata/uscita in servizio dei medici di CA, con informazione consultabile da parte della Centrale di CA.	Obbligatorio
CA9	App fruibile da dispositivi mobili e funzionalità web con cui i medici potranno compilare le schede evento e registrare le prestazioni erogate ai pazienti. Si richiede che la app sia disponibile per i più comuni Sistemi Operativi mobile.	Obbligatorio
CA10	App fruibile da dispositivi mobili e funzionalità web con cui i medici potranno gestire gli stati rispetto alle schede evento (es. al telefono, in visita ambulatoriale, in visita a domicilio paziente, in viaggio verso domicilio paziente, in viaggio verso ambulatorio) e che consenta la navigazione assistita verso il domicilio del paziente. Si richiede che la app sia disponibile per i più comuni Sistemi Operativi mobile.	Preferenziale
CA11	Reportistica per il monitoraggio delle attività di CA, anche secondo il format previsto dalla Regione Toscana (come da accordo integrativo regionale sulla CA24).	Obbligatorio
CA12	Gestione dinamica dell’associazione della postazione di CA al territorio. Il sistema dovrà consentire di gestire degli algoritmi di associazione della postazione sulla base di parametri configurabili (es. in base al CAP, alla via ecc..); dovrà essere comunque possibile inserire delle eccezioni puntuali (es. strada che dal civico 1 al civico 10 è di competenza della postazione di CA 1 e dal civico 11 al civico 20 della postazione di CA 2).	Preferenziale
CA13	Interfaccia utente per il riascolto delle telefonate registrate (ed archiviate nel sistema di registrazione) direttamente dalle schede contatto, alle quali la registrazione telefonica dovrà essere collegata.	Obbligatorio
CA14	Il Sistema dovrà essere in grado, in base a parametri configurabili, di segnalare automaticamente all’operatore che il contatto inserito è potenzialmente il duplicato di uno pre-esistente. Dovrà quindi rendere possibile, su richiesta, un raffronto diretto delle schede contatto già censite e quindi permettere l’accorpamento/annullamento dei dati o la normale gestione.	Preferenziale
CA15	Tutte le fasi del contatto dovranno essere memorizzate dal Sistema ed associate ai dati orari di ciascuna. La marcatura degli orari dovrà avvenire sia in modo manuale, con intervento da parte dell’operatore (caso di rendiconto a posteriori), sia in modo automatico, fruendo degli stati con ora certa, resi disponibili dalla app (descritta al punto CA9 e CA10). Il sistema dovrà tracciare e dare evidenza delle due differenti modalità di inserimento.	Obbligatorio
CA16	Qualunque modifica apportata ai dati delle schede dovrà essere tracciata e facilmente consultabile da parte degli amministratori di sistema, che dovranno essere in grado di risalire a data/orario e operatore dell’ultimo aggiornamento.	Obbligatorio
CA17	Sistema di messaggistica (chat) per la comunicazione rapida tra gli operatori ed i medici di CA.	Migliorativo
CA18	Tracciamento GPS degli spostamenti dei mezzi utilizzati dai medici della CA.	Preferenziale
CA19	Nel caso in cui il medico CA attivi la CO118, la scheda contatto dovrà essere visionabile/trasferita al sistema in uso alla CO118.	Obbligatorio
CA20	Il sistema dovrà integrarsi con il sistema di prescrizione elettronica che consenta al medico di effettuare la prescrizione senza necessità di inserire manualmente i dati del contatto.	Obbligatorio

24 DGRT n. 488 del 07/05/2018

Requisito

Obbligatorio/ Migliorativo/

Preferenziale

CA21

Il sistema dovrà integrarsi con i sistemi di firma digitale da utilizzare al momento della chiusura della scheda evento. I documenti firmati dovranno conseguente essere trasmesso al repository aziendale

che a sua volta provvederà all’invio in conservazione sostitutiva.

Obbligatorio

CA22

Il sistema nel caso in cui l’assistito non sia né residente né domiciliato in Regione Toscana, dovrà

emettere uno specifico alert che notifiche al medico che la prestazione è soggetta al pagamento di un corrispettivo.

Obbligatorio

CA23

Il sistema dovrà consentire anche la gestione del servizio di CA turistico.

Obbligatorio

5.1.4 Sistema di videocomunicazione avanzata fra assistito e Centrali Operative

Requisito

Obbligatorio/

Migliorativo/ Preferenziale

Funzionalità per la localizzazione GPS del chiamante anche se questi ha la localizzazione disattivata

sul proprio telefono (cellulare?) o non è in grado di utilizzarla (ma quale è la tecnologia per consentire questo scambio dati?)

Preferenziale

Servizio di chat con l’utente (l’utente con quale app chatterà)

Migliorativo

5.2 Requisiti tecnologici

Requisito

Obbligatorio/ Migliorativo/

Preferenziale

Integrazione con il sistema di autenticazione centralizzato. Gestione strutturata delle utenze e dei profili: il software in acquisizione dovrà possedere al suo interno funzionalità, utilizzabili solo dai profili di amministrazione, dedicate alla generazione e manutenzione delle utenze e dei profili di accesso alla procedura. Il gestionale deve essere integrato/integrabile, senza oneri aggiuntivi, con

gli eventuali sistemi aziendali di identity management.

Obbligatorio

Configurazione multi-tenant (con possibilità di gestire vari profili ed enti)

Obbligatorio

Funzionalità di amministratore di sistema per la profilazione degli utenti, la personalizzazione di report e per semplici attività di configurazione.

Obbligatorio

Sistema di messaggistica interna al software dedicata alla pubblicazione di news o alert redatti dall’amministratore dell’applicativo e/o dal fornitore (es. per notificare le modifiche introdotte con i cambi di release).

Il meccanismo di messaggistica deve strutturarsi su due livelli gerarchici:

• messaggi che richiedono la presa visione obbligatoria da parte dell’utente al momento dell’accesso (login) al gestionale;

• messaggi che possono essere letti in differita e conservati in un’area apposita dell’applicativo e segnalati con un alert fino all’avvenuta lettura.

Preferenziale

Inoltro delle richieste di assistenza tecnica, da parte dell’operatore, mediante appositi pulsanti/voci di menù a disposizione dell’utente dal sistema informatico. Una volta premuto il pulsante o selezionata la voce di menù:

• sarà automaticamente attivata la telefonata al servizio di assistenza del fornitore;

• oppure (in caso di segnalazioni non bloccanti) l’utente verrà invitato a compilare un form (eventualmente pre-compilato con i dati dell’utente) con le informazioni necessarie per inoltrare correttamente la segnalazione, che verrà trasmessa via mail al fornitore.

L’interfaccia utente dovrà anche consentire all’operatore di monitorare lo stato di avanzamento delle

segnalazioni trasmesse, sia aperte telefonicamente che inviate via mail.

Obbligatorio

5.3 Requisiti di sicurezza

Legenda:

OB (Obbligatorio): requisito indispensabile pena l’esclusione

OP (Opzionale): requisito non indispensabile ma che qualifica positivamente una offerta rispetto ad un’altra

REQUISITI GENERALI		OB	OP
R1	Il fornitore deve adottare al proprio interno le procedure e politiche di sicurezza definite dall’amministrazione committente, con particolare riferimento alle modalità di accesso ai sistemi dell’amministrazione, all’hardening (esempio installazione di soluzioni di end point security) dei dispositivi utilizzati dal fornitore, alla gestione dei dati dell’amministrazione.	X
R2	Il fornitore deve possedere la certificazione ISO/IEC 27001 e mantenerla per tutta la durata della fornitura.	X
R3	L’amministrazione può, con un preavviso di 20 giorni solari, richiedere ulteriori attività di auditing secondo modalità concordate con il fornitore. Le risultanze di tali audit verranno comunicate all’amministrazione.	X
R4	L’amministrazione, direttamente o tramite terzi incaricati, può eseguire verifiche relative alla conformità della prestazione dei servizi rispetto a quanto stabilito nel capitolato tecnico oltre che nell’offerta tecnica se migliorativa.	X
R5	Il personale del fornitore che presta supporto operativo nell’ambito della fornitura di servizi di sicurezza dovrà possedere certificazione su specifici aspetti della sicurezza.	X
R6	Il fornitore deve disporre di una struttura per la prevenzione e gestione degli incidenti informatici con il compito d’interfacciarsi con le analoghe strutture dell’amministrazione e con le strutture centrali a livello governativo.	X
R7	Il fornitore deve dotarsi delle misure minime di sicurezza per limitare il rischio di attacchi informatici (misure minime AgID livello standard)	X
R8	Il Security Operation Center del fornitore ha la responsabilità della gestione operativa e continuativa degli incidenti informatici sui servizi erogati nell’ambito della fornitura.	X
R9	Il fornitore deve garantire il rispetto di quanto richiesto dalla normativa vigente in materia di sicurezza cibernetica, anche in riferimento ai contenuti del GDPR, mettendo in atto misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio, tenuto conto dello stato dell’arte e dei costi di attuazione nonché della natura, dell’oggetto, del contesto e delle finalità del trattamento come anche del rischio di varia probabilità e gravità per i diritti e le libertà delle persone fisiche, e adottando procedure tecniche e organizzative volte alla gestione di eventuali violazioni di dati personali (vedi anche Scheda Check Compliance Sicurezza e Privacy SCCSP)	X
R10	Sulle reti messe a disposizione dal fornitore devono essere presenti di dispositivi di sicurezza perimetrale con funzioni di sicurezza (ad esempio Firewall e sistemi di Network Detection ed Event & Log Monitoring, SIEM, ecc.) necessari a rilevare e contenere eventuali incidenti di sicurezza ICT e in grado di gestire gli IoC (Indicator of Compromise).	X
R11	Il fornitore deve usare protocolli cifrati e meccanismi di autenticazione nell’ambito dei servizi erogati.	X
R12	Qualora il fornitore subisca un attacco, in conseguenza del quale vengano compromessi sistemi del committente da lui gestiti, deve farsi carico delle bonifiche del caso, e riportare i sistemi in uno stato di assenza di vulnerabilità.	X
R13	Il fornitore deve dare disponibilità a far parte di un Comitato di Direzione Tecnica (a supporto del TCSE art. 4 “Regolamento Politiche di Sicurezza delle Informazioni” di Estar), eventualmente aperto anche a soggetti terzi, che tratti il tema della sicurezza, sia nell’ottica di favorire la risoluzione di temi aperti sia per introdurre eventuali varianti al contratto per fronteggiare nuove minacce o altro.		X
R14	Il fornitore deve condividere le informazioni necessarie al fine di garantire il corretto monitoraggio della qualità e della sicurezza, eventualmente pubblicando le stesse nel portale della fornitura.	X
R15	Il fornitore si impegna a sottoscrivere una clausola di non divulgazione (NDA) sui dati e sulle informazioni dell’amministrazione.	X

R16

Le soluzioni e i servizi di sicurezza proposti dal fornitore devono essere aggiornati dal punto di vista tecnologico, con riferimento all’evoluzione degli standard e del mercato; devono essere conformi alle normative e agli standard di riferimento applicabili; devono venire adeguati nel corso del contratto, senza oneri aggiuntivi, alle normative che l’UE o l’Italia rilasceranno in merito a servizi analoghi.

REQUISITI SPECIFICI PER FORNITURE DI SERVIZI DI SVILUPPO APPLICATIVO		OB	OP
R17	Il fornitore deve attenersi alla politica di sicurezza dell’amministrazione committente, con particolare riferimento all’accesso ai dati dell’amministrazione, che avverrà esclusivamente sui sistemi di sviluppo e test.	X
R18	In fase di analisi, o di fornitura di un prodotto/servizio o software il fornitore deve definire ed esplicitare le specifiche di sicurezza (non funzionali) a partire dai requisiti eventualmente espressi dall’amministrazione.	X
R19	In fase di progettazione codifica, del software o servizio software il fornitore deve implementare le specifiche di sicurezza nel codice e nella struttura della base dati con particolare riferimento alla criptazione dei dati quando necessario.	X
R20	Al termine del collaudo e/o progetto, il fornitore deve rilasciare tutta la documentazione necessaria all’amministrazione per gestire correttamente quanto rilasciato anche sotto l’aspetto della sicurezza.	X

REQUISITI SPECIFICI PER FORNITURE DI OGGETTI CONNESSI IN RETE		OB	OP
R21	Supporto di protocolli sicuri e cifrati (HTTPS, SSH v2, ecc.).	X
R22	Filtraggio di indirizzi IP.	X
R23	Supporto di protocolli di autenticazione (ad esempio RADIUS, IEEE 802.1X, ecc.).	X
R24	Gestione di più profili con privilegi diversi. (vedi anche 1.4 scheda SCCSP)	X
R25	Funzionalità di “richiesta creazione o cambio della password al primo accesso”, in quanto compatibile con il sistema di autenticazione offerto. (vedi anche 1.2D scheda SCCSP)	X
R26	Blocco dell’utenza dopo un numero definito (fisso o variabile) di tentativi falliti di accesso, in quanto compatibile con il sistema di autenticazione offerto.		X
R27	Gli accessi degli utenti devono essere registrati su un archivio (log) non cancellabile con il reset. (vedi anche 1.3 e 2.2, 2.3 scheda SCCSP)	X
R28	Gestione dei log di sistema (accessi, allarmi, ecc.).	X
R29	Il fornitore (anche in collaborazione con il produttore della tecnologia) deve offrire processi, unità organizzative e strumenti dedicati alla gestione di vulnerabilità scoperte sui prodotti oggetto della fornitura.		X

REQUISITI SPECIFICI PER FORNITURE DI SERVIZI DI GESTIONE REMOTA		OB	OP
R30	Se di competenza del fornitore, i meccanismi di autenticazione devono essere basati su meccanismi di crittografia asimmetrica, a chiave pubblica; la lunghezza delle chiavi va impostata sulla base della criticità della comunicazione da cifrare (ad esempio 256 bit per le meno critiche, 512 bit per le più critiche); la gestione e distribuzione delle chiavi e dei certificati è a carico del fornitore.	X
R31	Autorizzazione: sulla base delle credenziali fornite dall’utente, si devono individuare i diritti e le autorizzazioni che l’utente possiede e permetterne l’accesso alle risorse limitatamente a tali autorizzazioni.	X
R32	Confidenzialità nella trasmissione dei dati: le comunicazioni tra la componente di gestione remota centralizzata e la componente locale installata presso la sede dell’amministrazione devono essere cifrate. (vedi anche 6.4 scheda SCCSP)	X
R33	Fornire meccanismi che permettano di garantire l'integrità di quanto trasmesso (ad esempio meccanismi di hashing).		X

R34	Il fornitore deve descrivere nel dettaglio le soluzioni tecniche utilizzate (dispositivi hardware e software impiegato, modalità operative, politiche di sicurezza, …) per soddisfare i requisiti di sicurezza dell’amministrazione committente (ad esempio, Misure Minime AgID livello Standard).	X
R35	In fase di attivazione del servizio, il fornitore deve concordare con l’amministrazione le modalità operative e le politiche di sicurezza, i livelli di gravità degli incidenti, le attività e le contromisure che dovranno essere svolte per contrastare le minacce.	X
R36	Il fornitore dovrà attenersi alle politiche di sicurezza definite dalla committente, con particolare riferimento alla definizione di ruoli e utenze per l’accesso ai sistemi gestiti.	X
R37	In caso di necessità, da parte degli operatori, di accesso a Internet, il fornitore deve utilizzare un proxy centralizzato e dotato di configurazione coerente con la politica di sicurezza definita dall’amministrazione.	X
R38	In caso di rilevazione di un incidente di gravità elevata (con scala da definire a inizio fornitura), il fornitore deve dare immediata notifica, tramite canali concordati con l’amministrazione, dell’incidente rilevato e delle azioni da intraprendere, al Responsabile della Sicurezza indicato dall’amministrazione e agli organismi individuati dal legislatore a presidio della sicurezza cibernetica.	X
R39	Per ogni incidente di sicurezza, il fornitore s’impegna a consegnare all’amministrazione, entro il giorno successivo, un report che descriva la tipologia di attacco subito, le vulnerabilità sfruttate, la sequenza temporale degli eventi e le contromisure adottate.	X
R40	Su richiesta dell’amministrazione, il fornitore deve consegnare i log di sistema generati dai dispositivi di sicurezza utilizzati, almeno in formato CSV o TXT. Tali log dovranno essere inviati all’amministrazione entro il giorno successivo a quello in cui è avvenuta la richiesta. ( vedi anche 2.4 e 2.5 scheda SCCSP)	X
R41	Il fornitore deve monitorare periodicamente, con una frequenza relazionata alla criticità della fornitura, la pubblicazione di upgrade/patch/hotfix necessari a risolvere eventuali vulnerabilità presenti nei dispositivi utilizzati per erogare i servizi e nelle infrastrutture gestite. Acquisita conoscenza, in sede di monitoraggio, del rilasscio rilascio dell’upgrade/patch/hotfix, il fornitore deve avviare una valutazione, da rilasciarsi entro un numero giorni da stabilirsi, propedeutica all’installazione delle stesse sui dispositivi di sicurezza, che ad esempio identifichi la possibilità di applicare la patch immediatamente, o la necessità di apportare MEV o integrazioni prima di procedere alle installazioni.	X

5.4 Recupero di dati storici

Incluso nel contratto è il recupero dei data base storici. La ditta aggiudicataria dovrà consentire l’eventuale avvicendamento con i sistemi attualmente in uso senza alcun fermo, con relativo recupero completo degli archivi. Più in dettaglio un elenco esemplificativo e non esaustivo:

5.4.1 Servizio di emergenza territoriale

• Recupero elenco mezzi, convenzioni e PET

• Recupero elenco enti AA.VV./CRI

• Recupero punti di interesse personalizzati su cartografia

• Recupero schede di intervento, comprensive di documenti e immagini allegati

• Recupero listini

• Recupero utenti

• … ecc ...

5.4.2 Servizio di urgenza territoriale

• Recupero elenco mezzi e convenzioni

• Recupero elenco enti AA.VV./CRI

• Recupero punti di interesse personalizzati su cartografia

• Recupero schede di trasporto

• Recupero listini

• Recupero utenti

• … ecc ...

5.4.3 Servizio di continuità assistenziale

• Recupero utenti

• Recupero zone di competenza

• … ecc ...

5.5 Integrazione con sistemi di Business Intelligence Aziendali

Il sistema informatico dovrà alimentare con cadenza almeno giornaliera il DWH aziendale (§2.1.1Errore. L 'origine riferimento non è stata trovata., §2.1.2, §2.1.3, §0), a cui i servizi elencati nel presente Capitolato e le altre strutture aziendali faranno riferimento per l’analisi di grandi moli di dati.

5.6 Requisiti Minimi Formazione e Affiancamento all’Avvio

La formazione dovrà essere necessariamente erogata entro l’avvio in produzione nell’ambito delle aziende sanitarie ed enti del SSRT per il personale coinvolto nell’utilizzo del sistema informatico.

L’affiancamento all'avvio dovrà essere necessariamente erogato on site senza oneri aggiuntivi.

5.7 Requisiti infrastrutturali

Indipendentemente dal dominio automatizzato, ESTAR propone una serie di linee guida tecnologiche25 quali riferimento per l’attivazione di nuove automazioni. Tale documentazione rappresenta la base fondamentale sulla quale si sviluppano le considerazioni del presente documento.

5.7.1 Contesto ICT

Le rapide e significative modificazioni organizzative dei Servizi Sanitari regionali, che comportano nuovi raggruppamenti delle risorse e diversi dispiegamenti dei servizi a supporto della tutela della salute, in parallelo all’inarrestabile rinnovamento tecnologico legato all’informatizzazione, impongono la rapida adozione di modelli implementativi mirati all’efficacia, alla sicurezza, alla continuità di servizio, rendendo necessario ripensare alle automazioni identificando modi, metodi e risorse che possano garantire continuità negli investimenti e nei risultati per un periodo di medio-lungo termine.

L’informatizzazione, e gli investimenti ad essa dedicati devono riuscire non solo a risolvere le esigenze del quotidiano operare, ma anche ed insieme a garantire continuità di efficace supporto difronte a modificazioni organizzative; a riallocazione fisica o logica delle risorse elaborative; a progressiva realizzazione di servizi immateriali trasversali di interesse; ad implementazione di procedure che rendano possibile continuità di servizio, ripristino rispetto a disastri, disponibilità e sicurezza rispetto all’accesso ai dati.

Ogni singola automazione deve concorrere a creare un Sistema Informativo Sanitario distribuito, che non proponga vincoli tecnologici, pronto ad evoluzioni almeno a medio termine, sapendo essere efficace strumento dell’Azienda Sanitaria che lo utilizza, ma in contemporanea mattone di un più ampio e completo sistema omogeneo e coordinato di informazioni sanitarie, utili e necessarie in prima istanza a garantire la tutela della salute di ogni singolo cittadino, e subito a seguire alla costruzione della migliore conoscenza possibile sui fenomeni di evento sanitario, così da poter sempre meglio prevenire, investire, intervenire.

Ogni sistema informatico deve comunque garantire ampio e completo supporto a tutte le funzioni operative che insieme rappresentano le necessità del servizio, opportunamente descritte e definite da chi quotidianamente si trova ad operare in quell’ambito. Ma diventa altrettanto essenziale definire i modelli logici di riferimento e le scelte tecnologiche che l’informatizzazione deve comunque implementare, a garanzia di

25 “ESTAR – Documentazione ICT”, “Documenti Compliance ICT “, xxxxx://xxxxxxx.xxxxx.xxxxxxx.xx/xxxxx.xxx/xxxxxxxxxxxxxx-xxx/0- architettura-del-software

continuità di servizio, di capacità interoperativa, di erogabilità e fruibilità distribuita ed efficace delle funzioni automatizzate.

5.7.2 Modelli tecnologici di implementazione

5.7.2.1 e-service

Una qualsiasi automazione informatica deve in primis garantire il supporto alle operatività quotidiane dell’ambito che va ad informatizzare. In generale, automatizzare significa consentire l’inserimento di dati – che descrivono compiutamente l’organizzazione automatizzata - in maniera facilitata ma vincolata e validata. Questi inserimenti consentono di rappresentare tutti i flussi organizzativi dell’ambito, di risolvere debiti informativi verso richiedenti istituzionali, di interpretare ruolo di riferimento per particolari funzioni nei confronti di informatizzazioni terze, di coadiuvare indagini rispetto alle funzioni informatizzate, di consolidare una oggettiva definizione informatica dell’ambito.

Per risolvere le funzioni proprie dell’ambito, un’automazione implementa operatività già attivate in altri ambiti. Ad esempio, in sanità accade spesso che si debba collegare l’identità di un paziente ad un’operatività tipica dell’ambito (un’indagine diagnostica, una prestazione sanitaria, un intervento di emergenza territoriale, …). Per collegare tale identità, si deve procedere ad una ricerca in base a parametri standard (nome, cognome, codice fiscale, residenza, età, …) fino a determinare se l’identità stessa è univocamente rintracciata, o addirittura ad inserirla se l’ambito è autorizzato a farlo. Le funzioni di gestione di un’identità paziente sono quindi comuni alla quasi totalità degli ambiti sanitari informatizzati; ognuna delle automazioni interpreta tali funzioni a suo modo, arrivando ai medesimi risultati in modo differente. Per far si che queste “funzioni trasversali” siano disponibili ad ogni ambito interessato, ovvero all’informatizzazione dell’ambito stesso, nelle linee guida26 sull’interoperabilità emesse da AgID per la Presidenza del Consiglio, il vecchio concetto di “integrazione” si evolve in un più approfondito concetto di utilizzo degli e-services. Gli e-services sono “… servizi digitali, realizzati da un erogatore per assicurare l’accesso ai propri dati e/o l’integrazione dei propri processi attraverso l'interazione dei suoi sistemi informatici con quelli dei fruitori …”.

Un e-service implementa un luogo informatico che rappresenta tutte le funzioni tipiche dell’ambito

automatizzato, ne garantisce tutti i vincoli e le validazioni, ovvero ne informatizza tutte le responsabilità

26 Presidenza del Consiglio dei Ministri, Agenzia per l’Italia Digitale, “Sistema Pubblico di Connettività”, “Il nuovo modello di interoperabilità”, xxxxx://xxx.xxxx.xxx.xx/xx/xxxxxxxxxxxxxx/xxxxxxx-xxxxxxxx-xxxxxxxxxxxx/xx-xxxxx-xxxxxxx-xxxxxxxxxxxxxxxx.

organizzative e normative; che interpreta informaticamente il ruolo univoco di gestore di quell’ambito, esponendo servizi di utilizzo delle informazioni, intendendo per informazioni non i semplici dati, ma gli stessi già validati, resi coerenti, garantendone un utilizzo proprio, addirittura interpretandone la interpretazione/visualizzazione laddove le particolarità dell’ambito lo rendessero necessario. Qualsiasi variazione e/o investimento da dedicare alla gestione di sviluppi informatici dovrà essere attivato tenendo conto delle logiche e-service, in un’ottica di evoluzione delle molteplici informatizzazioni che ripetevano al loro interno insiemi di funzioni simili.27

I numerosi ambiti che replicavano l’implementazione delle regole di responsabilità e gestione di un insieme comune devono eliminare completamente tale implementazione, sostituendola con invocazioni all’e-service specializzato, limitandosi ad utilizzare le interfacce (API) che questo espone, giocoforza sottostando alle regole da questo univocamente implementate, ovvero liberandosi dalla necessità di implementare tali regole.

Proseguendo l’esempio iniziato in precedenza, i nuovi investimenti devono tenere conto di un e-service dedicato alla gestione dell’identità paziente, che ne interpreti tutte le regole ed i vincoli e che esponga tutte le funzioni (API) che consentono ad una informatizzazione terza di utilizzare al suo interno riferimenti all’identità dei pazienti. Parallelamente, ogni informatizzazione, sia essa nuova implementazione, che già attiva - in un’ottica di continua evoluzione -, non deve implementare (o deve sostituire) tutta l’implementazione risolta da quell’e-service, attivando invece una serie di invocazioni alle API esposte dall’e- service stesso.

Il fornitore dovrà dettagliare un’offerta tecnica che preveda modalità di fruizione e-service ovvero tramite invocazione di API dedicate all’ambito. Se la committenza non dispone all’atto dell’acquisizione di e-services di riferimento, sarà a carico dell’aggiudicatario l’attivazione di ogni e- service di ambito non attivo.

Per tutta la durata del contratto, senza oneri aggiuntivi, relativamente agli ambiti ritenuti trasversali dalla committenza, il fornitore si impegna a collaborare all’analisi necessaria per definire compiutamente le logiche di ogni e-service di interesse; ad implementare ogni e-service nella procedura, in termini di fruizione verso terzi, ma anche di erogazione qualora fosse il dominio informatizzato il responsabile di quell’ambito.

27 Presidenza del Consiglio dei Ministri, Agenzia per l’Italia Digitale, Determinazione n. 406/2020 del 9 settembre 2020, “Adozione della Circolare recante le linea di indirizzo sulla interoperabilità tecnica”, Allegato “00_Linea di indirizzo interoperabilità tecnica.pdf”, xxxxx://xxxxxxxxxxx.xxxx.xxx.xx/xxxxxx/xxxxxxxxXxxx.xxx?xxxxxxxxxxxx_xxxxxxxx/000000000000X O00_Linea+di+indirizzo+interoperabi lit%E0+tecnica.pdf.

Il fornitore dovrà dettagliare un’offerta tecnica che dimostri la capacità, possibilmente nativa, di utilizzare API e-services per gli ambiti ritenuti trasversali. Se il sistema informatico oggetto di acquisizione dovrà privilegiare l’implementazione di tali funzioni trasversali come parti autonome rispetto alla procedura stessa, ovvero come e-services. Alternativamente, dovranno essere presentate soluzioni presentino un piano concreto e dettagliato, entro tempi certi, di implementazione delle logiche di fruizione tramite e-service degli ambiti trasversali identificati dalla committenza

Trattandosi di servizi il cui utilizzo è fortemente legato alle capacità applicative e di interazione dell’automazione, la configurabilità, l’attivazione di nuove API, la modifica di API esistenti, deve fare parte della manutenzione evolutiva programmata dell’automazione stessa.

5.7.2.2 Metodo di utilizzo delle API e-services

Chiarita la necessità di isolare come informatizzazioni autonome quelle degli ambiti trasversali, e la messa in disponibilità di fruizione dei servizi così implementati tramite API note e condivise, così che ogni procedura possa eliminare quelle gestioni al suo interno sostituendole con la fruizione di quelle API, devono essere identificati i metodi tecnologici ritenuti adeguati ad implementare le connessioni che supportano tali interazioni.

Il livello più basso di integrazione è quello dell’interazione a livello di dati: le due informatizzazioni condividono un accesso ad una base dati comune, nella quale scrivono/leggono i dati di interesse ed in base a questi agiscono. Risulta evidente che le regole di validazione dei dati stessi devono essere implementate (e mantenute in caso di evoluzione) in entrambe le informatizzazioni. Le connessioni infrastrutturali delle informatizzazioni con il database condiviso sono di tipo fortemente accoppiato (hard coupled), difficilmente dispiegabile su connessioni fisiche territoriali, che garantiscono livelli di servizio inferiori rispetto a connessioni fisiche di campus.

Un livello di integrazione subito superiore è quello dell’interazione a livello di informazioni: le due informatizzazioni espongono delle routines interrogabili (API) che implementano le logiche di contatto bloccanti (sincrone) condivise. Ogni automazione invoca la routine esposta dall’automazione interoperante, attendendo le informazioni di risposta, in base alle quali agisce. Risulta evidente che le connessioni infrastrutturali delle informatizzazioni devono adeguarsi alle metodologie di esposizione delle API (ad esempio, librerie condivise, connessioni CORBA, metodi RPC, ...), risultando di tipo hard coupled, difficilmente dispiegabile su connessioni fisiche territoriali, che garantiscono livelli di servizio inferiori rispetto a connessioni fisiche di campus.

Un livello di integrazione ancora superiore è quello dell’interazione a livello di informazioni loose coupled: le informatizzazioni espongono delle routines interrogabili (API) che implementano le logiche di contatto tramite metodi con connessione atomica e possibilmente non bloccante (asincrona). In linea generale i sistemi invocano le API per segnalare cambiamenti di stato (pubblicazione). I sistemi a cui interessa tale segnalazione (sottoscrittori) la ricevono e la memorizzano per utilizzarla quando opportuno per la propria logica operativa; nel momento nel quale quel cambiamento di stato dovrà essere utilizzato nelle logiche proprie del sottoscrittore, potrà essere interrogato il pubblicatore richiedendo informazioni complete rispetto ai cambiamenti di interesse (asincronicità non bloccante). Le integrazioni si evolvono da molteplici connessioni uno-ad-uno a segnalazioni uno-a-molti, con eventuali conseguenti richieste molti-ad-uno. La possibilità di inserire nella catena di pubblicazione attori non noti all’atto dell’attivazione, dovunque attivi, a prescindere dalle modalità di connessione fisica, ripropone un modello di interoperabilità distribuita attivo da anni nel mondo delle interazioni business-to-business di internet. Per sfruttare l’evidente efficacia e flessibilità di tale modello, le metodologie di connessione infrastrutturale delle informatizzazioni devono adeguarsi alle metodologie di internet, esponendo delle API come metodi di tipo http(s), risultando di tipo debolmente accoppiato (loose coupled), con sessioni che hanno eguale efficacia sia su connessioni fisiche territoriali che di campus.

Le già citate linee guida emesse da AgID sull’interoperabilità richiamano la necessità di attivare “… indifferentemente SOAP e REST quali tecnologie per l’implementazione delle API. La scelta della tecnologia da utilizzare è lasciata alle Pubbliche Amministrazioni che costituiscono un dominio di interoperabilità sulla base delle specifiche esigenze …”28.

Il fornitore dovrà dettagliare un’offerta tecnica che dimostri la capacità di poter attivare di poter attivare la fruizione di tutte le interoperabilità, in particolare degli e-services, con metodologie asincrone non bloccanti utilizzando web services di tipo SOAP o REST su trasporto di tipo http(s), dettagliandone la numerosità. Alternativamente dovrà essere data evidenza della disponibilità entro tempi determinati a trasformare le interoperabilità in modalità asincrona non bloccante utilizzando web services di tipo SOAP o REST su trasporto di tipo http(s).

28 Presidenza del Consiglio dei Ministri, Agenzia per l’Italia Digitale, Determinazione n. 406/2020 del 9 settembre 2020, “Adozione della Circolare recante le linea di indirizzo sulla interoperabilità tecnica”, Allegato “00_Linea di indirizzo interoperabilità tecnica.pdf”, cap. 6, “Tecnologie per le API”.

Trattandosi di interfacce il cui utilizzo è fortemente legato alle funzionalità applicative e interoperabilità dell’automazione, la configurabilità, l’attivazione di nuove API, la modifica di API esistenti, devono fare parte della manutenzione evolutiva programmata dell’automazione stessa.

5.7.2.3 Microservizi

Il concetto di interoperabilità verso servizi di riferimento (e-services) in modalità asincrona non bloccante tramite metodi SOAP o REST su trasporto di tipo http(s) (vd. §5.7.2.2) delineato quale modalità implementativa per tutti i contatti fra attori diversi, deve essere ritenuto parimenti essenziale per il ridisegno ed una efficace implementazione dell’automazione oggetto di attivazione. I moduli interni alla procedura che svolgono funzioni che la committenza ritenesse di interesse trasversale devono essere implementati con logica a microservizi, ovvero come e-services interni alla procedura stessa, esponenti API con le metodologie citate in §5.7.2.2. Tali e-services interni devono poter essere fruiti tramite API definite sotto coordinamento della committenza ed in collaborazione con tutti gli interessati che la committenza ritenga necessario coinvolgere. Per tutta la durata del contratto e senza oneri aggiuntivi, il fornitore si impegna a collaborare con la committenza per la definizione di e-services ritenuti di interesse trasversale, nonché per l’attivazione di implementazioni che garantiscano la fruizione o l’erogazione degli stessi così come definito in collaborazione con la committenza.

Il fornitore dovrà dettagliare un’offerta tecnica che dimostri la capacità di poter attivare la fruizione di tutte le funzioni interne delimitate ed atomiche come e-services interni, con metodologie asincrone non bloccanti utilizzando web services di tipo SOAP o REST su trasporto di tipo http(s), dettagliandone la numerosità. Alternativamente dovrà essere data evidenza della disponibilità entro tempi determinati a trasformare le funzioni trasversali in e-services interni, fruiti in modalità asincrona non bloccante utilizzando web services di tipo SOAP o REST su trasporto di tipo http(s).

Trattandosi di interfacce il cui utilizzo è fortemente legato alle funzionalità applicative dell’automazione, la configurabilità, l’attivazione di nuove API, la modifica di API esistenti, devono fare parte della manutenzione evolutiva programmata dell’automazione stessa.

5.7.2.4 Servizi immateriali

Qualsiasi funzione trasversale per la quale il dominio in attivazione esprima responsabilità organizzativa e/o gestionale (servizio immateriale), ovvero per la quale attori terzi possano diventare fruitori, deve essere applicativamente isolata ed attivata tramite un e-service esposto in modalità asincrona non bloccante, che risolva API definite sotto il governo di ESTAR e congiuntamente a

chiunque ESTAR ritenga attore interessato, tramite web services di tipo SOAP o REST su trasporto di tipo http(s).

Il fornitore dovrà dettagliare un’offerta tecnica che dimostri la capacità di poter attivare, relativamente a tutte le funzioni che la committenza ritenga essere servizi immateriali, l’attivazione applicativamente autonoma e la fruizione in modalità e-service tramite metodologie asincrone non bloccanti utilizzando web services di tipo SOAP o REST su trasporto di tipo http(s), dettagliandone la numerosità. Alternativamente dovrà essere data evidenza della disponibilità alla loro attivazione entro tempi ben determinati.

Trattandosi di servizi il cui utilizzo è fortemente legato alle capacità applicative e all’interoperabilità dell’automazione, la configurabilità, l’attivazione di nuovi servizi immateriali, la modifica di servizi immateriali esistenti, devono fare parte della manutenzione evolutiva programmata dell’automazione stessa.

5.7.2.5 Incapsulamento tecnologia obsoleta

In ambito sanitario sono attivi tutta una serie di apparati che non garantiscono connettività di rete; oppure che la garantiscono con modalità scarsamente efficaci; oppure che utilizzano la rete con metodologie non in grado di garantire un dispiegamento efficace ed in continuità di servizio dell’apparato in un territorio comunque complesso.

Gran parte degli apparati biomedicali, o degli apparati di supporto specializzato (gestione radio, gestione registrazioni audio/video, gestione formati raw, …), utilizzano tecnologia molto sofisticata dedicata a risolvere con estrema efficacia l’ambito di interesse, ma che risolvono le ormai inevitabili connessioni con la rete informatica con efficacia purtroppo molto inferiore.

Si verificano casi di apparati biomedicali dal costo limitato (centinaia o migliaia di euro) che non implementano interfacce di connessione alla rete informatica, limitandosi ad attivare le ormai inevitabili interoperabilità informatiche tramite connessioni di tipo locale (seriali, USB, ...).

Si verificano casi di strumentazione analitica di laboratorio di ultima generazione, efficacissima relativamente alla gestione della catena di produzione delle indagini diagnostiche, del costo di centinaia di migliaia di euro a singolo apparato, che attiva la connessione alla rete informatica tramite una interfaccia IP che non è in grado di gestire il default gatewaying. Tale limite non consente di inserire l’apparato in una subnet dedicata, garantendo contemporaneamente sicurezza, efficacia, indipendenza dalla dislocazione territoriale.

Sono ampiamente presenti sul mercato apparati diagnostici di settori comunemente ritenuti all’avanguardia dal punto di vista della interoperabilità informatica, come ad esempio modalità radiodiagnostiche, con costi che superano anche il milione di euro, che attivano connessioni efficaci dal punto di vista infrastrutturale, ma

che rendono operative le API di gestione delle interoperabilità tramite tecnologie sincrone bloccanti e/o tramite modalità di utilizzo della rete informatica di tipo loose coupled: le metodologie di tipo http(s), ovvero i trasporti che meglio supportano i web services SOAP o REST. Esistono ad esempio modalità radiodiagnostiche che garantiscono la disponibilità di sole API di tipo HL7 v2.x in modalità hat-piped (quindi in modalità sincrona bloccante su connessione socket permanente), piuttosto che tramite tecnologia da anni consolidata e funzionante quale HL7 XML/WS, oppure HL7 FHIR.

Ognuno di questi apparati che non appare in grado di partecipare ad una interoperabilità evoluta su IP in modalità asincrona non bloccante tramite l’utilizzo di API SOAP o REST su trasporto di tipo http(s), deve essere ricondotto a tale modalità di funzionamento incapsulandone le funzionalità ormai obsolete in un e-service appositamente implementato che chiameremo per comodità e-service gateway.

Si tratta di implementare ed attivare un e-service che esponga le api con le tecnologie e le metodologie di utilizzo delle API già più volte richiamate (vd. §5.7.2.2), attivato in ambiti limitrofi ai dispositivi dei quali deve incapsulare le funzionalità obsolete così che possa connettersi fisicamente ad essi qualsiasi sia la modalità da questi esposta. In termini informatici, l’e-service gateway si rappresenta come un bridge sia tecnologico, che di API, che di trasporto, che di metodo, fra risorse fruibili solo localmente ed in maniera non e-service, e le logiche e-service. Uno dei due lati del bridge è fortemente customizzato in base alle “incapacità” di ogni singolo apparato e ne garantisce la continuità operativa rispondendo alle necessità di colloquio locali dell’apparato stesso; l’altro lato del bridge espone servizi asincroni non bloccanti tramite API SOAP o REST su trasporto di tipo http(s), interrogabili da qualsiasi servizio fruitore esterno autorizzato.

L’e-service gateway si rappresenta come apparato informatico di tipo appliance-like, ovvero facilmente sostituibile, o bilanciabile, o scalabile, o configurabile.

Il fornitore dovrà dettagliare un’offerta tecnica che dimostri la capacità di poter attivare, relativamente a tutti gli apparati che fanno parte dell’ambito applicativo automatizzato e che non sono in grado di esporre nativamente servizi di tipo e-service come rappresentato in (vd. §5.7.2.2), l’incapsulamento delle funzionalità obsolete e la loro esposizione con tecnologia e metodologia di e-service gatewaying, dettagliandone la numerosità. Alternativamente dovrà essere data evidenza della disponibilità alla loro attivazione entro tempi ben determinati.

Trattandosi di servizi il cui utilizzo è fortemente legato alle capacità applicative e all’interoperabilità dell’automazione, la configurabilità, l’attivazione di nuovi e-gateways, la modifica di e-gateways esistenti, devono fare parte della manutenzione evolutiva programmata dell’automazione stessa.

5.7.2.6 Multi-tiering

Le sempre più pressanti esigenze di gestione della sicurezza dei dati informatici, attivata tramite isolamenti via subnettig, in parallelo alla necessità di configurare le risorse di computazione e storage in maniera diversificata rispetto alla peculiarità dei servizi informatizzati, ha portato alla diffusione di modelli logici di attivazione dei server applicativi secondo le specifiche multi-tiering.

Suddividendo, come succede nella quasi totalità delle applicazioni che erogano servizi in ambito web, le risorse computazionali e di storage in tre tiers diversi (presentazione, logica applicativa e persistenza), è possibile configurare tali risorse nella maniera ottimale in base al servizio supportato, nonché attivare logiche di bilanciamento, ridondanza, continuità di servizio, disaster recovering, content-filtering e sicurezza differenziate in base al tier servito.

Pur essendo possibile in linea generale “spezzare” applicazioni obsolete in due tiers, attivando un server dedicato per la gestione della persistenza dei dati, risulta evidente che una vera procedura nata ed implementata in ambito multi-tiered sia cosa ben diversa da tale “spezzettamento”. La logica multi-tier si dimostra ambito nativo del modello e-service, per il quale, ad esempio, la gestione della persistenza dati potrebbe essere attivata tramite un e-service dedicato che incapsula le funzionalità del database piuttosto che con i modelli di fruizione a connessione diretta del database stesso (xDBC). Più in generale, il modello multi-tiered potrebbe rappresentare un modello per il quale ogni tier espone delle API e-service ed è accedibile solo tramite queste. Questo modello rappresenta la massima efficacia ad oggi raggiungibile rispetto alla migliore allocazione delle risorse, alla più consona attivazione di sistemi di bilanciamento, ridondanza, continuità di servizio, filtering, alla più efficace scalabilità dei volumi di utilizzo, alla più ampia distribuzione dei servizi su territori comunque complessi, alla più flessibile riorganizzabilità dei servizi e delle risorse rispetto alle modificazioni organizzative e normative.

Il fornitore dovrà dettagliare un’offerta tecnica che implementi, possibilmente in modo nativo, l’uso in tier separati tramite tecnologi e modalità e-service, dettagliandone la numerosità. Alternativamente dovrà essere data evidenza della disponibilità alla loro attivazione entro tempi ben determinati.

Trattandosi di infrastrutture e metodi il cui utilizzo è fortemente legato alle capacità applicative dell’automazione, la configurabilità, l’attivazione di nuove tiers, la modifica di tiers esistenti, devono fare parte della manutenzione evolutiva programmata dell’automazione stessa.

5.7.2.7 Monitoraggio applicativo

L’attivazione di procedure ospitate in datacenter dedicati rende necessaria una capacità nativa delle automazioni di comunicare, sia in caso di eventi ritenuti significativi, sia in caso di richiesta da terzi autorizzati, sempre e comunque tramite l’utilizzo di tecnologie e modalità e-service, il loro “stato di salute”.

Una effettiva proattività rispetto ai malfunzionamenti applicativi è infatti realizzabile solo se la procedura stessa è in grado di allertare su stati interni non consoni, ed è comunque in grado di rispondere a semplici richieste su ben determinati insiemi di condizioni rispetto allo stato di salute applicativo interno.

Trattandosi tipicamente di eventi di segnalazione (o di richieste e risposte) di tipo JSON/REST via http(s) su porta IP dedicata, e trattandosi di informazioni legate alle singolarità degli ambiti applicativi, le API sia di cambiamento di stato che di richiesta/risposta devono essere concordate sotto coordinamento di ESTAR e con la partecipazione degli attori terzi che ESTAR ritenga opportuno coinvolgere, così da poter esprimere il miglior livello di conoscenza delle condizioni interne all’applicazione.

Il fornitore dovrà dettagliare un’offerta tecnica che implementi e-services di monitoraggio applicativo, possibilmente in modo nativo, dettagliandone la numerosità. Alternativamente dovrà essere data evidenza della disponibilità alla loro attivazione entro tempi ben determinati.

Trattandosi di e-service il cui utilizzo è fortemente legato alle capacità di continuità di servizio dell’automazione, la configurabilità, l’attivazione di nuove API, la modifica di API esistenti, deve fare parte della manutenzione evolutiva programmata dell’automazione stessa.

5.7.3 Architettura infrastrutturale

Il sistema deve essere erogato tramite un’architettura Full Web, preferibilmente HTML 5 Browser Independent (priva di qualsiasi installazione client e senza utilizzo di plugin o altro client-side quale java, etc), fruibile tramite protocolli sicuri (HTTPS, SSL, etc) con browser Microsoft Internet Explorer, Google Chrome, Firefox e Apple Safari o altro browser di mercato.

Con riferimento alla Det. ESTAR N° 803 del 18/05/2021 AUSL TSE tramite ESTAR si è recentemente dotata della infrastruttura tecnologica a supporto dei servizi da erogare come dal presente capitolato. Tale infrastruttura implementa un modello di sviluppo almeno a medio termine tramite tecnologie consolidate, efficaci e sperimentate.

Il modello che l’informatica del SSRT ha adottato ormai da anni è quello della virtualizzazione delle risorse

computazionali. Il sistema poggia sulla piattaforma di virtualizzazione che consente di predisporre l’utilizzo

di una serie di risorse implicite a garanzia della continuità di servizio, quali backup dei server in tempo reale (snapshot), gestione di HA (repliche delle VM con attivazione automatica “a caldo”), replica dei sistemi in ottica di DR (Site Recovery Manager), possibilità di tuning delle risorse “a caldo”, così mantenendo adeguate le performances dei sistemi in caso di modificazione dei carichi, ampie possibilità di scelta rispetto al ripristino di funzionalità sia parziali che totali.

Il modello di upgrade di recente aggiudicazione comprende l’attivazione di una linea di comunicazione dedicata e ridondata, con sufficiente larghezza di banda fra la sede della CO118 Ruffolo29 e la rispettiva sala CED Xxxxxxxx (Siena). La configurazione ottimale prevede anche una connessione fra le sale CED provinciali (Xxxxxxxx-Siena e X. Xxxxxx-Arezzo), in questo caso implementando la minima latenza attivabile, ridondata.

L’attivazione di tale connessione a bassa latenza permette una gestione DR con tempi minimi (RTO) e ripristino con dati aggiornati agli ultimi minuti prima del disastro (RPO), oltre alla comunicazione bidirezionale necessaria per predisporre il passaggio ad un’unica istanza informatizzazione 118 per tutta la AUSL Toscana Sudest. La comunicazione bidirezionale può essere attivata anche con linee a latenza maggiore (e conseguente minor impatto economico), fermo restando un corrispondente aumento dei tempi di RTO e RPO.

In sintesi il sistema dovrà:

• Funzionare su server virtuali, per garantire flessibilità, performances, continuità di servizio, per facilitare l’accorpamento delle istanze procedurali, per favorire la messa in opera di procedure di DR, per consentire un efficace utilizzo delle risorse centralizzate (Installazione su server virtuali, senza utilizzo di macchine fisiche)

• Utilizzare sistemi di replica incrociata fra le due istanze a livello di virtualizzazione

• Implementare procedure di DR fra le istanze

In rispondenza al quadro normativo nazionale e regionale, incluso a titolo esemplificativo, ma non esaustivo, deve essere garantito il disaccoppiamento tra dato sanitario e dato anagrafico per una non immediata associazione, e immediato adeguamento nel tempo del sistema ad ogni variazione normativa. Il fornitore fornirà i dettagli tecnico/applicativi che abilitino la interoperabilità con i sistemi in essere. A cura del fornitore e qualora applicabile al dominio della fornitura, dovrà essere predisposto di un adeguato protocollo operativo da far utilizzare alle strutture sanitarie in caso di indisponibilità del servizio, da mantenere

29 Xxxxxxx è la sede della CO118 di Siena-Grosseto.

aggiornato almeno annualmente e da testare almeno mensilmente (concordando tempi e modi in fase di contratto attuativo). Sempre a cura del fornitore, dovrà essere predisposto con cadenza di rinnovo annuale e con verifica della consistenza dei dati salvati, del piano di backup necessario al ripristino dei dati in caso di incidente, e senza necessità di variare il sistema di backup già in esercizio.

E’ incluso, al collaudo, o su richiesta anche successiva dell’Azienda/Ente, che il fornitore effettui un test di completezza del recovery. L’interazione con strumenti di office automation (tramite integrazione, off-line su file prodotti dal servizio, etc) non deve essere limitata a strumenti proprietari quali, a titolo esemplificativo, ma non esaustivo, Microsoft Office, ma deve essere effettuabile con strumenti di office automation di tipo open source, garantendo identiche funzionalità ed operatività. Si precisa che i diversi strumenti di office automation devono coesistere, ovvero il software fornito deve dare garanzie di funzionamento contemporaneo su pc con software di produttività diversi.

Dovranno essere dettagliate le caratteristiche hardware/software-di-base richieste per i server virtuali (ram, cpu, storage, s.o.) e per i PC client.

L’architettura dovrà essere multi-tenant, ovvero dovrà essere possibile gestire più strutture qualora le esigenze operative ne richiedano la necessità.

Si ritengono parte integrante del presente capitolato i seguenti documenti di definizione dell’ambiente tecnologico di riferimento pubblicati alla pagina Web di ESTAR xxxx://xxxxxxx.xxxxx.xxxxxxx.xx/xxxxx.xxx/xxxxxxxxxxxxxx-xxx/ - reperibili alla voce "documenti compliance ICT"

• Regole di utilizzo della rete InterSST2

• Linee guida tecnologiche

• CAST Descrizione del Modello

• CAST Specifiche Funzionali InteroperabilitaESB

• CAST Registry OID

• CAST Specifica Interfaccia Applicativa EventHandler

Document Metadata

Table of Contents

Capitolato Tecnico di Gara

Document Metadata