Cartella Clinica Informatizzata di Rianimazione/Terapia Intensiva - Requisiti di riferimento

Sommario

Cartella Clinica Informatizzata di Rianimazione/Terapia Intensiva - Requisiti di riferimento 1

PRELIMINARI 3

Acronimi– Glossario – Definizioni 3

Terminologia 3

Art. 1. Oggetto della fornitura 4

Art. 2. Obiettivi della fornitura 4

Art. 3. Caratteristiche funzionali minime 5

Art. 4. Caratteristiche auspicabili 8

Art. 5. Modalità, tempi di implementazione, installazione e collaudo 9

a. Tempi di consegna, installazione e avvio in uso clinico 11

b. Formazione ed affiancamento 13

c. Prove di Accettazione e Collaudo 16

Art. 6. Servizi di Assistenza e Manutenzione 19

a. Caratteristiche del Servizio di Manutenzione ed Assistenza Tecnica 20

b. Service Level Agreement (SLA) 24

c. Performance fornitura: Uptime, Downtime, Outage 24

d. Gestione avvisi di sicurezza e segnalazioni di incidenti 25

e. Condizioni di fine contratto 26

Art. 7. Penali 26

Art. 8. Configurazione 27

Art. 9. Componenti BASE 29

Appendice. 1. Gestione e Integrazione Anagrafica 31

a. Specifiche Anagrafica AOU Modena 31

b. Specifiche Anagrafica AUSL Romagna 31

Appendice. 2. Integrazione ADT 32

a. Specifiche ADT AOU Modena 32

b. Specifiche ADT AUSL Romagna 32

Appendice. 3. Integrazione Order Entry 35

a. Specifiche Order Entry AOU Modena 35

b. Specifiche Order Entry AUSL Romagna 35

Appendice. 4. Integrazione RIS-PACS 38

a. Specifiche RIS-PACS AOU Modena 38

b. Specifiche RIS-PACS AUSL Romagna 38

Appendice. 5. Integrazione Archivio farmaci di reparto 40

a. Specifiche Archivio farmaci di reparto AOU Modena 40

b. Specifiche Archivio farmaci di reparto AUSL Romagna 40

Appendice. 6. Integrazione Laboratorio Analisi 41

a. Specifiche Laboratorio Analisi AOU Modena 41

b. Specifiche Laboratorio Analisi AUSL Romagna 41

Appendice. 7. Integrazione Anatomia Patologica 42

a. Specifiche Anatomia Patologica AOU Modena 42

b. Specifiche Anatomia Patologica AUSL Romagna 42

Appendice. 8. Integrazione Emoteca Trasfusionale 43

a. Specifiche Emoteca Trasfusionale AOU Modena 43

b. Specifiche Emoteca Trasfusionale AUSL Romagna 43

Appendice. 9. Integrazioni con Dispositivi Medici 44

Appendice. 10. Gestione Privacy e Sicurezza Informatica 45

a. Specifiche Gestione Privacy e Sicurezza Informatica AOU Modena 46

b. Specifiche Gestione Privacy e Sicurezza Informatica AUSL Romagna 46

Appendice. 11. LDAP/Active Directory 46

a. Specifiche LDAP/Active Directory AOU Modena 46

b. Specifiche LDAP/Active Directory AUSL Romagna 47

Appendice. 12. Soluzione di Business Continuity e Disaster Recovery 47

a. Caratteristiche generali dell’architettura 47

b. Business continuity e Disaster Recovery 48

Appendice. 13. Integrazione HL7 outbound (referti, report) 50

a. Specifiche HL7 outbound AOU Modena 50

b. Specifiche HL7 outbound AUSL Romagna 50

Appendice. 14. Funzionalità di Business Intelligence 51

a. Specifiche Business Intelligence AOU Modena 51

b. Specifiche Business Intelligence AUSL Romagna 51

Appendice. 15. Recupero dei precedenti 51

a. Recupero precedenti AOU Modena 51

b. Recupero precedenti AUSL Romagna – ambito Rimini 51

Appendice. 16. AOU Modena: caratteristiche specifiche 52

a. Infrastruttura Server e DB 52

b. Postazioni di lavoro 53

c. Specifiche Architetturali 53

Appendice. 17. AUSL Romagna: caratteristiche specifiche 54

a. Caratteristiche e vincoli di tipo generale 54

b. Infrastruttura Server e DB 55

c. Postazioni di lavoro 56

d. Specifiche Architetturali 56

PRELIMINARI

Acronimi– Glossario – Definizioni

ADT Admission, Discharge, and Transfer

APLIS Anatomic Pathology Laboratory Information System

AOU AUSL

Azienda Ospedaliero Universitaria Azienda Unità Sanitaria Locale

CSA Capitolato Speciale di Appalto

DICOM Digital Imaging and Communications in Medicine

DM Dispositivo Medico

GDPR General Data Protectio Regulation: Regolamento (UE) 2016/679 del Parlamento europeo e del Consiglio, del 27 aprile 2016

HIS Hospital Information System

IHE Integrating the Healthcare Enterprise

HL7 Health Level Seven

IVT Innovazione e Valutazione delle Tecnologie

MIR Manufacturer Incident Report

OE Operatore Economico

RTO Recovery Time Objective

RPO Recovery Point Objective

SIO Sistema Informativo Ospedaliero

TI Tecnologie Informatiche

TS Tecnologie Sanitarie

TSLB Tecnico Sanitario di Laboratorio Biomedico

UO Unità Operativa

UOC Unità Operativa Complessa

VNA Vendor Neutral Archive

UML Unified Modelling Language

Terminologia

Nel presente documento, le forme verbali:

 deve e dovrà: stanno a significare un requisito minimo obbligatorio di cui si richiede il possesso, pena esclusione;

 dovrebbe: sta a significare un requisito auspicabile, non obbligatorio;

 può o potrebbe sta a significare una possibile opzione ammessa.

Art. 1. Oggetto della fornitura

Sistema Hardware e Software ad uso dipartimentale destinato alla completa informatizzazione del flusso di lavoro in terapia intensiva e rianimazione.

La fornitura comprende il progetto di implementazione, configurazione, attivazione della cartella clinica elettronica, da ora in poi denominata CCE, importazione dei dati clinici e funzionalità presenti nell’attuale cartella clinica in esercizio presso le Aziende, servizi di integrazione con i vari sistemi informativi di riferimento, servizi di formazione, servizi di assistenza e manutenzione ordinaria, correttiva ed evolutiva.

Art. 2. Obiettivi della fornitura

 Completa dematerializzazione della cartella clinica di reparto cartacea con mantenimento delle medesime caratteristiche funzionali essenziali (incluse modalità compilazione, conservazione, archiviazione..) e piena valenza medico-legale; la cartella clinica elettronica di terapia intensiva deve costituire l'ambiente che consente agli utilizzatori sanitari di svolgere, documentare e gestire la totalità delle attività che riguardano il paziente in carico al reparto di terapia intensiva, garantendo continuità clinica dei dati in ingresso ed uscita, in maniera sicura;

 Continuità Clinica:

o Terapia

▪ Integrazione con repository locale delle terapie

▪ Integrazione con terapie in ingresso per riconciliazione e prosecuzione terapia

▪ Integrazione con terapie in uscita per prosecuzione terapia

o Parametri Vitali (PV)

▪ Possibilità di ricezione dei dati relativi ai PV da sistema di cartella clinica generalista per inclusione in cartella di TI e prosecuzione rilevazione internamente alla TI

▪ Possibilità di trasmissione dei dati relativi ai PV rilevati verso sistema di cartella clinica generalista per inclusione e prosecuzione rilevazione esternamente alla TI

o Ricezione della documentazione medica e infermieristica rilevate a monte della TI, per visualizzazione

o Trasmissione (ad altro sistema di cartella clinica) della documentazione medica e infermieristica rilevata in TI, per prosecuzione cartella;

o Ricezione del diario clinico (medico e infermieristico) rilevato a monte della TI (da CDR o altro sistema di cartella clinica), per visualizzazione

o Trasmissione del diario clinico (medico e infermieristico) rilevato in TI, per prosecuzione cartella;

 Supporto all’ottimizzazione e standardizzazione del flusso di lavoro e procedure sia in routine che in emergenza, con impatto migliorativo su ogni attività di reparto con particolare riferimento a efficienza e sicurezza paziente e operatore;

 Massima integrazione con il tessuto informativo ospedaliero e con i dispositivi medici a posto letto;

 Xxxxxxx integrità, accuratezza e fruibilità del dato archiviato estesa all’intero percorso di cura e oltre (es: alla ricerca) con particolare riferimento a:

o Passaggio di consegne tra professionisti;

o Consulenza/second opinion;

o Revisione dei dati archiviati;

o Cruscotti informativi di sintesi individuali o aggregati.

 Xxxxxxx supporto in termini di:

o Diagnostica/terapia;

o Direzione strategica/Valutazione performance;

o Didattica.

 Massima disponibilità di strumenti di analisi/sintesi/selezione sui dati archiviati (reportistica, statistiche, supporto studi clinici).

Art. 3. Caratteristiche funzionali minime

 Cartella clinica di tipo “attivo” con informazioni strutturate, campi calcolati (es: scores, protocolli clinici);

 Compatibilità con contesti multi-ospedale e/o multi-reparto. Gestione unificata della base dati con politiche di accesso/visibilità configurabili;

 Livello di servizio 24/7 su tutte le componenti del sistema;

 Pacchetto formativo completo per tutto il personale utilizzatore;

 Sistema completo di:

o Strumenti di monitoraggio/alert funzionale interno e sui canali di integrazione;

o Memorizzazione log con tracciabilità completa attivitàad ogni livello utente;

o Ambiente di test allineato per verifica preliminare di impatto e annullamento/minimizzazione di disservizio in caso rilascio patch/upgrade/releases.

 Flessibilità e configurabilità, in grado di adattarsi ai contesti installativi più vari sia dal punto di vista tecnico (diverse piattaforme hardware e software) che ergonomico (diverse esigenze organizzative);

 Design tecnico orientato alla massima usabilità con soluzioni specifiche per la minimizzazione del “numero di click” necessari per funzione, in ogni situazione operativa;

 Soluzione informatizzata in grado di gestire funzionalmente (migliorandone la fruibilità) ogni aspetto della struttura classica della cartella ovvero:

o Anagrafica;

o Accettazione;

o Anamnesi;

o Esame obiettivo;

o Terapia;

o Diario Clinico Giornaliero;

o Richiesta accertamenti;

o Dimissione/Trasferimento.

 Interfaccia grafica:

o Ottimizzata per touch screen (il cui uso previsto deve essere largamente prevalente) in particolare per le ws a posto letto;

o Data entry non automatizzato ridotto al minimo e massimamente strutturato con inserimento testuale libero ridotto al minimo;

o Gestione campi obbligatori configurabile;

o Completa di soluzioni tecniche orientate a massimizzarne l’usabilità;

o Approccio informativo e layout di tipo massimamente contestuale;

o Soluzioni grafiche ad elevata immediatezza (es.: schemi d’organo, codici colore, icone, widget,..).

 Struttura nel complesso organizzata a moduli funzionali con possibilità di implementazione dei singoli moduli anche in un secondo momento;

 I singoli moduli con destinazione d’uso medica con riferimento alle casistiche indicate nella definizione di dispositivo medico secondo la normativa vigente) dovranno essere specificamente certificati come dispositivo medico secondo la stessa normativa, con classificazione adeguata al livello di rischio.

 Acquisizione diretta di dati da DM di fabbricanti terzi a posto letto, comprensiva dell’hardware di collegamento necessario (apparati locali hardware) – importazione automatica e sicura del massimo contenuto informativo (eventi, forme onda, allarmi,..) univocamente associati al paziente corrente e destinati a popolare la base dati informativa della cartella “attiva”. Politiche configurabili di validazione. Dovrà essere prodotta una lista di compatibilità la cui ampiezza sarà oggetto di valutazione;

 Gestione avanzata della sicurezza informatica e privacy ad ogni livello (accesso, visualizzazione/modifica/inserimento, archiviazione, integrazione con applicativi terzi) allineata allo stato dell’arte e nel rispetto della normativa vigente, con separazione fisica e logica tra i dati clinici e i dati anagrafici dei pazienti, implementata in modo da non consentire un’associazione tra tali dati;

 Disponibilità funzione di integrazione con le policy di autenticazione aziendali tipiche (LDAP, Active Directory..) con funzione Single Sign On. Gestione privilegi di gruppo, preferibilmente specializzabili sul singolo utente;

 Gestione delle prescrizioni mediche orientata alla minimizzazione del rischio di errore con particolare riferimento alla prescrizione della terapia infusionale;

 Documentazione della somministrazione dei farmaci gestibile tramite archivio centralizzato, con gestione policy di controllo/validazione;

 Calcolo di scores e dell'indice di gravità secondo linee guida internazionali aggiornabili;

 Gestione dei presidi monouso;

 Soluzioni specifiche a supporto della gestione del controllo delle infezioni;

 Calcolo massimamente automatizzabile del bilancio idrico giornaliero;

 Gestione della firma digitale con soluzione di equivalenza certificabile alla firma autografa;

 Comprensiva della possibilità di integrazioni esterne automatizzate con tracciato record configurabile (debito informativo regionale, Pro SafeGiViti,..);

 Configurazione con criteri di ridondanza orientati alla massima continuità di servizio su guasto singolo. Il sistema dovrà nel suo complesso essere progettato per garantire valori minimi di Recovery Point Objective e Recovery Time Objective. Tali valori dovranno essere esplicitamente dichiarati e giustificati in offerta tecnica;

 Comprensiva dell’hardware locale necessario (server locali) per rispettare quanto indicato nel presente capitolato in termini di esigenze architetturali (rif. Art. 5, Appendice. 12, Appendice. 16, Appendice. 17);

 Comprensiva, in aggiunta a quanto esplicitamente indicato nelle apposite appendici al presente documento, di gestione integrata di chiamate di contesto ad applicativi terzi (es. PACS, Order Entry,..) in ambiente operativo unificato;

 Comprensiva di pacchetto formativo completo;

 Comprensiva della garanzia di almeno 12 mesi su tutte le componenti della fornitura;

 Post vendita:

o Servizio di assistenza continuo durante tutto l’anno 24H/7gg, con modalità di attivazione rapida. Tempi di intervento e risoluzion e ridotti. Soluzioni avanzate e flessibili di intervento da remoto;

o Formazione ricorrente;

o Si richiede di minima disponibilità di corsi abilitanti per funzioni di amministrazione tecnica e clinica, configurazione di base, primo intervento;

o Disponibilità a soluzioni di risorse on-site su richiesta per installazioni complesse;

o Dovrà essere garantito e incluso, da parte dell’Impresa aggiudicataria, al termine del periodo di fornitura, l’eventuale avvicendamento con sistema fornito da diversa Impresa con relativa migrazione dei dati clinici- amministrativi.

Art. 4. Caratteristiche auspicabili

 Compatibilità con gestione completamente paperless;

 Certificabilità estesa secondo il nuovo regolamento 745/2017 e linee guida MDCG;

 Predisposizione per colloqui bidirezionali con DM integrabili;

 Predisposizione per gestione sistemi di identificazione automatici (es: braccialetto,..);

 Predisposizione funzione “silent ICU” – la cartella clinica come aggregatore di segnali e allarmi con funzione di sorveglianza primaria;

 Gestione licensing flessibile e compatibile con rapide evoluzioni organizzative per esempio in situazione di emergenza con particolare riferimento a scalabilità orizzontale e/o verticale;

 Soluzioni integrate certificate di Business Intelligence/Machine Learning/Intelligenza artificiale sui dati acquisiti (Es: identificazione pattern, funzioni predittive o adattive);

 Disponibilità di pacchetti di configurazione specifica per lo scenario COVID a rapida implementazione con possibilità di personalizzazione successiva; tale disponibilità, se offerta, deve essere chiaramente descritta nello specifico allegato (A2) con indicazione delle funzionalità e integrazioni minime garantite all’avvio; si precisa che non saranno considerate accettabili, come risposta all’esigenza specifica, soluzioni stand alone, ma che tali configurazioni dovranno comunque prevedere le integrazioni minime (es. Anagrafica, SIO, altro) e le funzionalità di base (es. diario clinico, terapia, collegamento al monitoraggio, altro) necessarie a garantirne l’uso corretto e sicuro;

 Disponibilità di modulo integrato per la gestione del flusso di lavoro di sala operatoria;

 Disponibilità di modulo integrato per la gestione della cartella anestesiologica di sala;

 Disponiblità di modulo integrato per la gestione della cartella di Terapia Intensiva Neonatale;

 “Refresh” formativi on demand superiore a quanto richiesto nelle caratteristiche funzionali minime.

Art. 5. Modalità, tempi di implementazione, installazione e collaudo

La ditta fornitrice, a seguito dell’aggiudicazione, dovrà nominare un Responsabile referente del progetto e comunicarlo via posta o mezzo elettronico, alle seguenti UU.OO. delle aziende committenti:

 U.O. Ingegneria Clinica, per quanto di competenza dell’AOU di Modena;

 U.O. Innovazione e Valutazione delle Tecnologie, per quanto di competenza dell’Azienda USL della Romagna.

La fornitura deve comprendere tutto quanto è necessario ad installare "a regola d'arte" le tecnologie sanitarie ed informatiche offerte, comprese tutte le predisposizioni necessarie per il corretto funzionamento delle stesse, nonché tutte le operazioni di messa in funzione e collaudo.

Devono pertanto essere compresi senza esclusione alcuna:

 Infrastruttura HW (predisposta per la gestione del totale dei posti letto, rif. Tabella 1);

 HW posto letto inclusi in fornitura;

 Infrastruttura SW (predisposta per la gestione del totale dei posti letto, rif. Tabella 1);

 Server locali necessari

 SW posto letto inclusi in fornitura;

 Tutti gli ulteriori moduli richiesti e inclusi in fornitura.

Tutte le tecnologie sanitarie ed informatiche fornite al momento della installazione devono rappresentare l’evoluzione aggiornata equivalente dei sistemi proposti in fase di gara, senza modifica delle condizioni contrattuali.

Nel prezzo devono essere comprese anche le spese di spedizione, imballo, scarico, trasporti interni (anche ai piani), montaggio, allontanamento materiali di risulta e pulizia, compresa manovalanza, nonché gli oneri assicurativi che sono a carico dell’aggiudicatario.

Il sistema offerto dovrà essere installato presso i siti indicati alle Appendici 16 e 17. È onere a carico della ditta offerente, e quindi del fornitore, verificare la compatibilità dei sistemi offerti con i siti di destinazione sia dal punto di vista fisico (pesi, dimensioni ed ingombri), sia dal punto di vista impiantistico (tipo di alimentazione elettrica, tipo di prese ecc.). Inoltre, i sistemi offerti dovranno essere compatibili con i percorsi interni sia verticali sia orizzontali delle sedi di destinazione indicate.

La proposta tecnica del fornitore dovrà descrivere l’architettura e le relative funzionalità dell’impianto in rapporto alla dislocazione logistica e ai requisiti di connettività.

Rimangono a carico delle Aziende committenti le seguenti predisposizioni impiantistiche:

 alimentazioni elettriche 220V – 50-60Hz;

 prese di rete dati (RJ45).

Rimane a carico delle Aziende committenti, come meglio precisato alle Appendici 16 e 17:

 l’hardware necessario all’installazione del Software offerto e i relativi S.O., solo se Open Source (ad es. Linux CentOS) e database Oracle, per il livello centrale e distaster recovery;

 i S.O., solo se Open Source (ad es. Linux CentOS) e database Oracle, per i livelli locali.

Si precisa che tutte quanto non specificato nei predetti articoli ed eventuali ulteriori licenze necessarie per il corretto funzionamento del sistema offerto, sia lato server, sia lato client, sono a carico del fornitore (ad esempio sistemi operativi non open source, CAL, add-on,..). Tutta l’infrastruttura software deve basarsi sulle ultime versioni disponibili e supportate dei prodotti (sistemi operativi, framework,..); su tutti i software offerti dovranno essere installate e manutenute le eventuali patch rilasciate da parte del produttore.

L’installazione dell’hardware e del software dovrà essere certificata conforme ai requisiti di installazione previsti nella documentazione annessa al/i prodotto/i certificati CE secondo la legislazione Dispositivi Medici.

È competenza dei tecnici dell’azienda committente:

 l’installazione e la configurazione del sistema operativo secondo le richieste del fornitore e rispettando i requisiti di sicurezza aziendali;

 l’assegnazione di credenziali personali ai tecnici del fornitore incaricati delle operazioni di installazione/aggiornamento dei vari software;

 l’intervento sul contenitore VMware;

 la gestione dei backup dei sistemi e dei dati secondo le politiche aziendali;

 il supporto alla configurazione e al setup dei servizi di autenticazione e bilanciamento.

È competenza dei tecnici del fornitore tutto quanto non compreso nel precedente elenco, tra cui:

 l’installazione, configurazione e messa in produzione dei DB;

 la risoluzione di qualsiasi problematica relativa al contenuto e al funzionamento del DB (lock, rallentamenti, integrazioni con altre procedure,..).

In riferimento alle esigenze e condizioni imposte dall’attività sanitaria, la ditta fornitrice dovrà garantire:

 disponibilità all’esecuzione di determinati lavori, a richiesta dell’Azienda committente, eventualmente anche in orario prefestivo/festivo/notturno, osservando i tempi che verranno dettati da esigenze di carattere sanitario e/o tecnico, senza avanzare diritti di compenso alcuno per eventuali maggiori costi derivanti da interruzioni, frazionamenti e sospensioni temporanee;

 che durante lo svolgimento dei lavori, gli stessi non recheranno intralci al normale espletamento delle attività sanitarie;

 che i lavori siano assoggettati a limitazioni di orario o ad eventuali sospensioni, qualora si rendessero indispensabili per il funzionamento delle attività suddette;

 che qualsiasi intervento che possa influire sull’attività sanitaria sia preventivamente concordato con la Direzione Sanitaria;

 che fuori dall’orario di apertura dei servizi coinvolti (servizi sanitari e tecnici/informatici – Ingegneria clinica (AOU Modena) – Innovazione e Valutazione delle Tecnologie (AUSL Romagna)), come pure nei giorni festivi, non farà eseguire, a suo arbitrio, lavori che richiedano la sorveglianza da parte dell’appaltatore.

Dovranno inoltre essere rispettate tutte le condizioni nel seguito esplicitate.

a. Tempi di consegna, installazione e avvio in uso clinico

Le consegne dovranno essere effettuate a cura, rischio e spese del fornitore.

La fornitura sarà attivata dal ricevimento del formale ordine emesso dalle Aziende Committenti, inviato e/o trasmesso a mezzo fax, o altro mezzo anche elettronico.

Nell’ordine sarà specificato il luogo di consegna.

Dal momento del ricevimento dell’ordine, la fornitura dovrà avere inizio entro e non oltre 30 gg solari, ed essere ultimata (avvio del periodo di prova in uso clinico) entro il termine massimo di 120 giorni solari dall’ordine o entro il termine indicato nell’offerta, se migliorativo, salvo diversa indicazione da parte delle Aziende committenti (ognuna rispettivamente per la fornitura di propria competenza) o mancata messa a disposizione dei locali.

Le Tecnologie Sanitarie ed Informatiche dovranno essere consegnate ed installate a regola d’arte ed in conformità alla offerta aggiudicata; l'OE dovrà assumere a proprio carico e rischio tutte le spese di ogni natura (imballi e loro smaltimento, assicurazione, facchinaggio ecc…).

Tali operazioni dovranno avvenire senza soluzione di continuità, ovvero in modo da non interferire sulla operatività dell’Azienda ed in particolare sul servizio fornito all’utenza e nei tempi indicati nel tempogramma previsto in offerta.

Tempogramma

Il fornitore deve indicare in dettaglio un piano corredato di un chiaro cronogramma (es. Gantt). Tale piano (Allegato R della documentazione di gara) deve rispondere a requisiti di chiarezza e fattibilità e deve comprendere:

 Fasi di implementazione del sistema offerto;

 Attività per ciascuna fase;

 Tempistica di progetto;

 Sequenza delle attività e relative interdipendenze, con indicazione chiara di eventuali vincoli (es. attivazione integrazioni, disponibilità risorse informatiche, ecc..);

 Specificazione della responsabilità (commitente o fornitore) per ciascuna attività.

L’installazione e configurazione delle singole componenti costituenti l’intero sistema dovrà avvenire rispettando le tempistiche indicate nel tempogramma, eventualmente modificato in sede di offerta aggiudicata previo accordo fra le Aziende committenti e la ditta fornitrice.

Il tempogramma dovrà prevedere, per singola azienda committente, un massimo di 120 giorni solari consecutivi complessivi dall’emissione dell’ordine all’inizio della prova in uso clinico; il suddetto termine massimo previsto si riferisce all’avvio del sistema per tutte le UU.OO. coinvolte, comprensivo, per ogni sito di installazione, di un giorno per le procedure di controllo operativo prestazionale e per dare avvio al periodo di prova in uso clinico.

In caso di disponibilità offerta di pacchetto a rapida configurazione per lo scenario COVID, il tempogramma dovrà prevedere un massimo di 60 giorni solari consecutivi, dall’emissione dell’ordine, per l’avvio in uso clinico di tale configurazione, e 60 giorni solari consecutivi da tale avvio, per le attività di completamento e personalizzazione della fornitura.

L’avvio del periodo di prova in uso clinico è in ogni caso subordinato al superamento di tutte le fasi previste dal tempogramma (attività centrali, recupero precedenti, formazione,..) opportunamente documentate e deve necessariamente essere autorizzato dalle UU.OO.:

 U.O. Ingegneria Clinica, per quanto di competenza dell’AOU di Modena;

 U.O. Innovazione e Valutazione delle Tecnologie, per quanto di competenza dell’Azienda USL della Romagna.

	Tempogramma Fornitura Installazione Avvio in uso Clinico Tempi di esecuzione posti a riferimento (indicati i valori massimi da non superare) I tempi indicati si riferiscono alla singola azienda committente
In assenza di “pacchetto Covid”	120 giorni solari consecutivi dall’ordine	Periodo di prova in uso clinico di 60 giorni solari continuativi	Collaudo e attivazione del contratto di manutenzione
	 Attività preliminari e preparatorie  Attività centrali  Recupero dei precedenti  Installazione, formazione, e avvio in uso clinico
In presenza di “pacchetto Covid”	60 giorni solari consecutivi dall’ordine	60 giorni solari consecutivi dal termine di installazione del “pacchetto Covid”	Collaudo e attivazione del contratto di manutenzione
	 Attività preliminari e preparatorie  Attività centrali	 Completamento installazione fornitura e attività di personalizzazione/configurazione/f ormazione

 Recupero dei precedenti

 Installazione, formazione e avvio in uso clinico “pacchetto Covid”

Prova in uso clinico di 60 giorni solari continuativi

Nota: il verificarsi di condizioni, imputabili esclusivamente all’Azienda committente, e comunicate ufficialmente dall’Azienda stessa alla ditta aggiudicataria, che dovessero impedire il rispetto dei tempi dichiarati in offerta, non darà origine al pagamento di penali; il rispetto dei tempi deve comunque sempre intendersi per singolo ambito/sito di installazione e singola attività.

Il completamento dell’installazione e della configurazione dell’intero sistema in tutte le sue componenti dovrà essere comunicato a mezzo dichiarazione scritta indirizzata alla:

 U.O. Ingegneria Clinica, per quanto di competenza dell’AOU di Modena

 U.O. Innovazione e Valutazione delle Tecnologie, per quanto di competenza dell’Azienda USL della Romagna

in cui la Ditta attraverso il proprio incaricato per la fornitura certifica che i lavori sono ultimati e che il sistema è perfettamente funzionante e pronto al collaudo.

Al fine del riscontro del rispetto dei tempi previsti relativamente a quanto dichiarato dalla ditta nel cronoprogramma, farà fede la data di ricevimento delle dichiarazioni. Sarà compito delle rispettive UU.OO. di riferimento verificare e riscontrare tali dichiarazioni; in particolare:

 U.O. Ingegneria Clinica, per quanto di competenza dell’AOU di Modena

 U.O. Innovazione e Valutazione delle Tecnologie, per quanto di competenza dell’Azienda USL della Romagna

Il completamento del recupero e migrazione dei precedenti dovrà essere comunicato a mezzo dichiarazione scritta all’U.O. Innovazione e Valutazione delle Tecnologie, in cui l’OE attraverso il proprio incaricato di fornitura certifica che la migrazione risulta ultimata e attesta il risultato finale della migrazione in riferimento ai dati che sono stati migrati nel data base del nuovo sistema e a tutti gli eventuali dati che non sarà stato possibile trasferire dai vecchi data base.

Il sistema consegnato in tutte le sue componenti dovrà essere quelle oggetto dell’accordo contrattuale posto in essere con la Ditta aggiudicataria.

Non si accettano forniture parziali e non si procederà alla emissione di collaudi parziali. La fornitura si potrà considerare completata solo quando tutti i suoi componenti saranno perfettamente installati ed attivati e saranno conclusi tutti i livelli di collaudo, come definito nell’apposito articolo dedicato al collaudo per tutti i siti previsti.

b. Formazione ed affiancamento

L'OE deve presentare proposte formative sia per il personale sanitario sia per il personale tecnico, con l’obiettivo di rendere autonomi, all’uso corretto e sicuro del sistema fornito, tutti gli utilizzatori.

I servizi relativi alla formazione dovranno permettere l’inserimento graduale del nuovo sistema informatico, sostituendo i sistemi attualmente in uso ove presenti.

La proposta formativa dovrà contemplare un piano di formazione e di affiancamento adeguato al numero di utilizzatori coinvolti, alle diverse tipologie di utente e allo svolgimento dell’attività lavorativa su turni; il numero di ore di formazione non dovrà essere inferiore a quello riportato nelle tabelle sottostanti e dovrà comunque rispondere alle eventuali ulteriori richieste formative che gli utilizzatori dovessero presentare dall’avvio della prova in uso clinico alla conclusione della stessa. La formazione del personale dovrà riguardare, per ogni sessione, un numero di persone tale da non interrompere lo svolgimento delle attività sanitarie.

In particolare, dovra essere evidenziato il supporto e l’affiancamento degli utenti durante la fase di avvio del sistema. Le attivita di formazione dovranno essere concluse prima dell’avvio della prova in uso clinico.

Il personale utilizzatore dovrà essere reso autonomo all’utilizzo dell'applicativo prima della messa in uso clinico del sistema offerto.

La ditta offerente dovrà indicare nella documentazione presentata (rif. Allegato A2 – Relazione requisiti), un piano formativo che contempli la descrizione dei corsi previsti per ciascuna figura professionale coinvolta (medici, infermieri, altre firgure sanitarie, tecnici, ) indicando:

1. la quantita di ore di formazione e addestramento, suddivise per tipologia

2. le modalita di erogazione dei corsi

3. il numero minimo e massimo di discenti previsto per ciascun corso

4. l’impegno a fornire la formazione negli orari e nei giorni e luoghi concordati

5. i metodi per la verifica dell’apprendimento

6. la descrizione del materiale formativo che verrà consegnato

7. il profilo del docente di ciascun corso e le ore di impegno della singola figura

8. quanto altro ritenuto utile a descrivere il percorso formativo

Si richiedono, per ogni figura professionale sotto riportata, le ore minime di formazione indicate nella tabella seguente:

Tipologia professionale	Numero ore di formazione per operatore	Numero operatori per posto letto
Medico	12	n. 1 per posto letto
Infermiere	12	n. 3 per posto letto
Altro personale sanitario	4	n. 4 per sito di installazione
Amministratore di sistema	12	n. 2 per sito di installazione
Ingegneri/tecnici	5	n. 4 per sito di installazione

All'atto esecutivo, i contenuti, le modalità ed i tempi di esecuzione dei corsi dovranno essere

concordati ed approvati dai responsabili delle UU.OO. coinvolte e ai responsabili dei servizi dell'Area Tecnica preposti alla gestione della tecnologia oggetto di fornitura.

Ogni corso dovrà prevedere un'attestazione, volta a certificare l'avvenuta formazione.

L'effettivo svolgimento di tutte le attività previste nei piani di formazione dovrà essere documentato dalla completa compilazione del modulo predisposto dell’Azienda USL di riferimento, controfirmato dal personale che avrà ricevuto l’istruzione; la mancata presentazione di tale documentazione verrà considerata motivo di non rispondenza ai requisiti di collaudo.

Se il progetto prevede l’individuazione di utenti designati come amministratori di sistema, dovrà essere prevista, prima del collaudo di accettazione, una formazione specifica in loco.

La formazione dovrà essere certificata dalla completa compilazione del modulo di collaudo dell’Azienda USL di riferimento, controfirmato dal personale che avrà ricevuto l’istruzione.

Nella proposta di formazione devono chiaramente essere individuati i corsi da svolgere prima della messa in servizio del sistema e quelli da svolgere nelle fasi successive, lungo tutto l'arco di durata del contratto di manutenzione come formazione ricorrente e come formazione per nuovi assunti.

Per garantire una maggiore fruibilità e ripetibilità dei corsi, si deve prevedere la preparazione di servizi di formazione in modalità e-learning (attività formative fruibili tramite rete Internet o Intranet in modo autonomo o assistito). La documentazione elettronica dovrà comunque essere messa a disposizione di tutti gli utenti, in modo da costituire una fonte formativa sempre disponibile.

L'OE aggiudicatario dovrà rendersi disponibile a fornire supporto e materiali informativi, anche in formato multimediale, per la preparazione di un corso di formazione da erogare in modalità di Formazione a Distanza (FAD) su piattaforma Aziendale già attiva.

L'OE aggiudicatario dovrà collaborare col Servizio Formazione dell'Azienda appaltante per integrare i corsi nel sistema dei crediti ECM e, possibilmente, CFP.

Formazione del personale tecnico

Ancorché la manutenzione sia interamente a carico del fornitore secondo la modalità full risk tutto compreso descritta nell'art. Art. 6 del presente Capitolato tecnico, è richiesto per il personale tecnico delle UU.OO. responsabili della gestione del sistema offerto, un corso di formazione tecnico sul sistema fornito e sulle tecnologie che lo compongono. I contenuti del corso di formazione e gli ambiti di intervento devono essere descritti in fase di offerta e devono rispondere all’esigenza di attuazione di una corretta gestione di tale sistema. Detto corso deve prevedere il rilascio di un attestato nominativo che certifichi che il personale che lo ha frequentato è abilitato ad effettuare specifiche operazioni (a titolo esemplificativo e se ritenuto applicabile: spegnimento e riavvio dei server, aggiornamento antivirus se utilizzato quello aziendale, ecc.) sulle tecnologie oggetto della fornitura limitatamente ai livelli di intervento definiti. I contenuti specifici del corso di formazione dovranno comunque essere concordati.

Affiancamento del personale sanitario

La fornitura deve comprendere un periodo di affiancamento, diverso e successivo alla formazione richiesta ai punti precedenti, durante lo svolgimento delle attività cliniche a partire dal periodo di

prova in uso clinico del nuovo sistema, da parte di tecnici della ditta fornitrice in grado di intervenire in qualunque punto del flusso di lavoro gestito dal nuovo sistema.

L’affiancamento dovrà essere garantito, almeno durante l’orario di lavoro diurno dei giorni feriali, per un minimo di 14 giorni lavorativi totali per sito di installazione.

La programmazione delle giornate di affiancamento che, a secondo delle specifiche esigenze delle UU.OO. coinvolte, potranno essere continuative o meno, deve essere concordata con le predette UU.OO..

c. Prove di Accettazione e Collaudo

Il collaudo tecnico amministrativo sul sistema e su tutte le sue componenti hardware e software prevede cinque livelli sequenziali per la fornitura nel suo complesso.

La ditta dovrà comunicare alle UU.OO. di riferimento, in particolare:

 U.O. Ingegneria Clinica, per quanto di competenza dell’AOU di Modena

 U.O. Innovazione e Valutazione delle Tecnologie, per quanto di competenza dell’Azienda USL della Romagna

con almeno 7 giorni di anticipo, la data di disponibilità all’avvio del collaudo. Il collaudo potrà avviarsi al completamento dell’installazione secondo i criteri generali di seguito definiti.

La modalità di svolgimento del collaudo in termini generali è articolata in diversi livelli come riportato nella seguente tabella:

Primo livello	Controllo documentale
Secondo livello	Controlli sulla corretta esecuzione dell'installazione
Terzo livello	Controllo operativo prestazionale
Quarto livello	Verifica nell’utilizzo operativo della durata di 60 giorni solari consecutivi
Quinto livello	Verifica del raggiungimento degli obiettivi

L’esito positivo di ciascuno livello, ovvero il superamento del processo completo del collaudo tecnico-amministrativo (cinque livelli), sancirà l’effettivo completamento della fornitura e l’avvio del periodo di garanzia.

Il collaudo è da considerarsi unico per l’intera fornitura e potrà ritenersi completato solo quando l’intera fornitura in ogni sua singola componente sarà stata collaudata.

Il collaudo verrà effettuato dal personale incaricato dalle aziende committenti, in particolare delle seguenti UU.OO.:

 U.O. Ingegneria Clinica, per quanto di competenza dell’AOU di Modena

 U.O. Innovazione e Valutazione delle Tecnologie, per quanto di competenza dell’Azienda USL della Romagna

Le condizioni indicate sono vincolanti per la buona riuscita del collaudo. La mancanza di una o più

condizioni di collaudo, valutata caso per caso dal personale incaricato avrà le conseguenze seguenti:

 Sospensione del COLLAUDO con divieto di utilizzo per gravi non conformità rispetto alle condizioni contrattuali di fornitura;

 Sospensione del COLLAUDO ed emissione di un’autorizzazione provvisoria all’uso.

In ogni caso, la durata massima della sospensione è fissata in 30 giorni solari consecutivi dalla data di notifica della stessa, avvenuta a mezzo fax su moduli predisposti dalle UU.OO. incaricate dell’esecuzione del collaudo.

Nel periodo intercorrente fra la consegna delle apparecchiature ed il collaudo definitivo (compreso periodo di prova in uso clinico), la ditta aggiudicataria dovrà comunque provvedere a sua cura e spese alla sostituzione, riparazione e manutenzione di qualsivoglia componente che dovesse risultare difettoso o non adatto all’uso, compresa la sostituzione di quelle parti che dovessero deteriorarsi per il normale uso.

Di seguito si riportano sommariamente la descrizione dei cinque livelli che il collaudo deve comprendere con l’indicazione delle attività previste per ognuno di questi.

Procedure di collaudo - Controllo documentale

1. Verifica rispondenza della fornitura a quanto ordinato;

2. Verifica esistenza dell'autocertificazione del Fornitore che dichiari la rispondenza del prodotto fornito, individuato dal numero di serie, alla normativa vigente;

3. Verifica della fornitura in due copie del manuale d’uso in lingua italiana contenente tutte le istruzioni necessarie per la corretta conduzione e l'uso giornaliero delle Tecnologie Sanitarie e Tecnologie Informatiche fornite;

4. Verifica della fornitura del manuale tecnico di servizio in lingua italiana o inglese (service) contenente tutte le istruzioni necessarie per la manutenzione correttiva e preventiva delle apparecchiature fornite, comprensivo di tutto quanto è necessario per qualsiasi procedura di manutenzione;

5. Conferma dei corsi di addestramento all'uso del sistema fornito per il personale sanitario tramite evidenza del calendario dei corsi secondo quanto previsto dal piano formativo presentato e da quanto richiesto nel presente capitolato;

6. Conferma dei corsi di addestramento alla manutenzione correttiva e preventiva del sistema fornito per il personale tecnico tramite evidenza del calendario dei corsi secondo quanto previsto dal piano formativo presentato e da quanto richiesto nel presente capitolato.

Procedure di collaudo - Verifica della corretta installazione

1. Verifica corretta installazione e rispetto dei requisiti di installazione del fabbricante.

Procedure di collaudo - Controllo operativo prestazionale

1. Controllo di sicurezza fisica (elettrica, meccanica, ecc..) dei dispositivi installati;

2. Controllo di sicurezza e funzionalità;

3. Verifica della corrispondenza alle normative specifiche dichiarate dalla Ditta Aggiudicataria ed a quelle applicabili per i dispositivi dello specifico settore;

4. Corrispondenza dei dati tecnici dichiarati in offerta;

5. Valutazione della conformità delle prestazioni richieste nei documenti di gara e di quelle dichiarate in offerta, con riferimento ai flussi di lavoro ed alle integrazioni con i sistemi informativi Aziendali (SIO, LDAP,..). In particolare dovrà essere svolta la seguente attività:

o 5.a Verifica della capacità del sistema di rispondere a situazioni di guasti tecnici;

o 5.b Verifica delle prestazioni dichiarate;

o 5.c Esecuzione di test di funzionalità, tramite simulazione (Allegato F2 – casi d’uso);

6. Verifica del ritiro da parte del Fornitore dell’imballaggio utilizzato al trasporto dei sistemi forniti.

Per l’esecuzione di parte delle attività di cui ai punti precedenti, il nuovo sistema dovrà presumibilmente essere stato interfacciato ai sistemi informativi in uso. Al fine di realizzare tali collegamenti e relative interfacce, sarà onere delle ditta aggiudicatrice contattare le aziende fornitrici e pianificare le attività necessarie per le integrazioni, in maniera da minimizzare le ripercussioni sull’attività clinica ed i tempi di fermo delle attività cliniche.

A seguito del superamento dei livelli sopra descritti, verrà rilasciato un documento di autorizzazione all’uso clinico.

Procedure di collaudo - Verifica in uso clinico

Verifica di funzionamento del sistema e delle sue prestazioni in uso clinico mediante un periodo di prova, che dovrà dar modo agli utilizzatori di valutare i sistemi forniti e riscontrare quanto dichiarato in offerta, anche sotto il profilo dell’affidabilità e del servizio di assistenza. Presupposto indispensabile per poter procedere a questa fase è che tutte le altre siano state superate con esito positivo. L’avvio di tale fase sarà stabilito tramite apposito documento (autorizzazione all’uso clinico) redatto dalla:

 U.O. Ingegneria Clinica, per quanto di competenza dell’AOU di Modena

 U.O. Innovazione e Valutazione delle Tecnologie, per quanto di competenza dell’Azienda USL della Romagna

in un formato dalla stessa definito a propria totale discrezione. La durata di tale periodo è fissata in un minimo di 60 giorni solari consecutivi per ognuno dei siti di installazione.

Nel caso in cui siano previste modalità di fornitura, e avvio in uso clinico, in tempi successivi nei vari siti di produzione, considerato che il collaudo della fornitura, per singola Azienda USL, deve essere unico e che non si rilasciano collaudi parziali, i diversi siti di produzione avranno periodi di prova in uso clinico di durata variabile dovendo garantire per ogni sito, e quindi anche per l'ultimo attivato, un periodo minimo di 60 giorni solari consecutivi. Il periodo di prova in uso clinico pertanto terminerà, per l'intera fornitura, al termine del periodo di prova in uso clinico previsto per l'ultimo sito di installazione attivato.

La procedura sopra esposta si applica anche nel caso di avvio in uso clinico del pacchetto “Covid”,

pertanto le fasi di collaudo precedenti all’avvio devono essere correttamente superate seppure ridimensionate alla configurazione specifica; in questo caso, il completamento della fornitura che dovrà avvenire parallelamente alla prova in uso clinico, comporterà la ripetazione dei primi tre livelli di collaudo per le nuove funzionalità/integrazioni introdotte.

Procedure di collaudo - Verifica del raggiungimento degli obiettivi

Al termine della verifica in uso clinico verranno eseguiti i controlli relativi al conseguimento degli obbiettivi complessivi generali e particolari del progetto, secondo quanto definito dalla documentazione di gara e dal progetto-offerta presentato.

Al superamento con esito positivo dell'ultima fase di collaudo (verifica del raggiungimento degli obiettivi), la U.O. incaricata del collaudo redigerà il verbale finale di collaudo, in un formato dalla stessa definito a propria totale discrezione, che sarà firmato da un rappresentante della stessa

U.O. e dovrà essere controfirmato dalla ditta fornitrice. La data della firma di detto verbale sancirà la conclusione della fornitura e l’inizio del contratto di manutenzione.

Se le tecnologie sanitarie ed informatiche fornite o parti di esse non dovessero superare le prescritte prove funzionali e di utilizzo clinico, la verifica dovrà essere ripetuta con le stesse condizioni e modalità, con eventuali oneri a carico della ditta.

Se la fornitura o le prestazioni previste, a giudizio della U.O. incaricata del collaudo, dovessero risultare in tutto o in parte di qualità inferiore e/o effettuate in modo difforme rispetto a quanto stabilito, la ditta sarà tenuta a provvedere affinché vengano apportate le necessarie correzioni a proprie spese entro i termini stabiliti dalla sopra citata U.O..

Si ribadisce che, solo a collaudo completamente superato, compreso quindi anche il periodo di prova in uso clinico e la verifica del raggiungimento degli obbiettivi, avrà conclusione la fornitura e inizio il periodo di garanzia che darà diritto al fornitore di procedere con la fatturazione secondo le modalità stabilite. Sempre dallo stesso momento dovranno altresì essere garantiti tutti i servizi e le prestazioni che la fornitura comprende (compreso ad esempio la garanzia su downtime ed outage) ai livelli assicurati e dichiarati in offerta.

Art. 6. Servizi di Assistenza e Manutenzione

Dovrà essere proposto e descritto un progetto di manutenzione e assistenza dimensionato per garantire la continuità di funzionamento e la massima disponibilità del servizio mediante la gestione, sotto il profilo del coordinamento, dell’assistenza tecnica (ai vari livelli applicativi, sistemistico, database, livello utilizzatore) e tutte le operazioni preventive necessarie. Il servizio di assistenza dovrà essere garantito 24/7 (24h 7 giorni su 7), con modalità di attivazione rapida; i tempi di intervento e risoluzione dovranno essere ridotti e dichiarati; dovranno essere previste e comprese soluzioni avanzate e flessibili di intervento onsite e da remoto, con possibilità di interazione con la sessione utente corrente; dovrà essere prevista la disponibilità a soluzioni di risorse on-site su richiesta per installazioni complesse ela proposta dovrà essere articolato come da fac-simile offerta economica..

a. Caratteristiche del Servizio di Manutenzione ed Assistenza Tecnica

Per ciascun componente del sistema offerto (hardware e software compresi) facenti parte della fornitura, la ditta aggiudicataria dovrà garantire, per tutto il periodo di garanzia, il servizio di manutenzione ed assistenza tecnica di tipo “full risk” omnicomprensiva (nulla escluso). Successivamente al periodo di garanzia la ditta deve proporre un servizio di manutenzione ed assistenza tecnica di tipo full risk omnicomprensiva (nulla escluso), un servizio manutenzione con primo intervento ingegneria clinica (sempre full risk ma con la gestione della prima disamina delle problematiche tecniche sempre a cura del servizio ingegneria clinica), un servizio di manutenzione solo manutenzione preventiva e un servizio con solo manutenzione correttiva su chiamata. In ogni caso deve sempre essere prevista la manutenzione evolutiva necessaria per assicurare il mantenimento del sistema al massimo dell’efficienza e della sicurezza, secondo le specifiche del fabbricante.

L'eventuale sostituzione dei componenti dovrà essere eseguita sia per guasto (non funzionamento), sia per deterioramento delle prestazioni.

Il servizio richiesto come FR e come primo intervento IC dovrà avere copertura 365gg/anno e 24h/gg comprensivo, ove necessario, anche di interventi on site.

Per le chiamate di qualsiasi genere inerenti alla segnalazione di guasti e malfunzionamenti o alle richieste di assistenza, deve essere definito un riferimento unico e indistinto per le varie componenti software di pertinenza del sistema oggetto della fornitura

I servizi di assistenza FR e primo intervento IC dovranno garantire, in modo proattivo o su richiesta esplicita delle Committenti (Manutenzione Correttiva; chiamata da parte di personale specifico concordato, e con modalità concordate):

 Manutenzione Preventiva: il monitoraggio del funzionamento del sistema e la sostituzione

/ evoluzione /riconfigurazione di qualsiasi modulo software di cui siano note problematiche che ne potrebbero compromettere la stabilità o il corretto funzionamento, pur non essendosi ancora manifestato alcun malfunzionamento;

 Manutenzione Correttiva: il ripristino di qualsiasi componente software (incluse le configurazioni dei medesimi) alla funzionalità originale o alle specifiche definite in fase di offerta o progetto. Tale ripristino può avvenire a seguito di guasto o malfunzionamento, o a seguito di individuazione di non conformità alle specifiche rilevate anche dopo l’attivazione del sistema;

 Assistenza: la risposta a qualsiasi richiesta di informazione sul sistema;

Nel caso di primo intervento IC la prima disamina delle problematiche sarà sempre a carico della struttura di ingegneria clinica.

Modalità di contatto da parte delle Committenti:

 Contatto telefonico: la ditta fornitrice deve istituire un servizio di Help Desk attraverso l’istituzione di un numero unico per la ricezione delle chiamate. Tale servizio deve essere facilmente fruibile e strutturato su più livelli di gestione in relazione alla complessità. Il servizio di ricezione delle chiamate deve funzionare 24/24 h 7/7. Tale servizio dovrà essere anche gestire il call back e infine la chiusura della chiamata registrandone di riferimenti temporali e l’esito;

 Contatto tramite mezzo elettronico prodotto dai sistemi di monitoraggio aziendali ove presenti;

 Contatto tramite mezzo elettronico (e‐mail o altro strumento indicato dal fornitore).

Erogazione Attività di Manutenzione Preventiva e Correttiva

 Intervento in loco di personale tecnico abilitato del fornitore;

 Intervento in remoto tramite connessione VPN resa disponibile dalle Committenti;

Erogazione Attività di Assistenza

 Assistenza telefonica;

 Assistenza via e‐mail (o sistemi di conferenza elettronica indicati dal fornitore).

I tempi di intervento per servizi di manutenzione correttiva e assistenza (SLA) dichiarati in offerta devono essere descritti come da tabella seguente, ed essere uguali od inferiori ai tempi ivi indicati.

Il servizio di assistenza e manutenzione dovrà garantire il perfetto funzionamento del sistema. anche ai fini delle specifiche e dei requisiti espressi dal contesto normativo. Nel servizio, pertanto, dovranno essere comprese tutte le attività necessarie ad assicurare gli adeguamenti normativi del software, con riferimento a tutta la normativa europea, nazionale e regionale.

L’intervento di assistenza e manutenzione deve sempre includere tutte le attività necessarie per garantire il completo ripristino dell’operatività incluse analisi e diagnosi dei malfunzionamenti e dovrà svolgersi in collaborazione con il personale della Committenza o di altre ditte o personale da essa incaricati, quando necessario.

Gli interventi di assistenza e manutenzione si riferiscono anche all’hw e sw necessario alle integrazioni.

Gli interventi, a partire dall’attivazione, devono necessariamente essere risolutivi.

Per qualunque motivo si rendesse necessario un blocco programmabile del sistema, questo dovrà necessariamente essere concordato con i tecnici della committente, e andrà eseguito avendo cura di ridurre al minimo eventuali disservizi.

Il fornitore non potrà sospendere l'erogazione delle prestazioni contrattualmente definite, con decisione unilaterale, in nessun caso, neppure quando siano pendenti controversie con la committente.

Si considera la ditta aggiudicataria quale unico interlocutore per tutte le attività previste dal presente capitolato.

Qualora si pervenisse a risoluzione contrattuale per inadempienza del fornitore, sullo stesso graverebbero tutti gli oneri e le conseguenze anche legali.

La ditta dovrà dichiarare di poter garantire almeno i seguenti servizi nei contratti FR e primo intervento IC:

1. ATTIVITÀ DI MANUTENZIONE CORRETTIVA E ASSISTENZA

tempi di intervento su chiamata: la ditta dovrà garantire tempo di intervento entro massimo 4 ore solari dal ricevimento della chiamata (anche solo telefonica) in caso di malfunzionamento/guasto non bloccante ed entro massimo 1 ora solare dal ricevimento della chiamata (anche solo telefonica) in caso di malfunzionamento/guasto bloccante.

tempi di risoluzione del guasto e rimessa in servizio: la ditta dovrà garantire la riduzione al minimo possibile del fermo tecnico del sistema offerto e dovrà garantire la sua rimessa in servizio:

 entro massimo 8 ore solari dal ricevimento della chiamata (anche solo telefonica), inclusi i casi ove sia necessario reperire pezzi di ricambio, per guasti non bloccanti.

 entro massimo 4 ore solari dal ricevimento della chiamata (anche solo telefonica), inclusi i casi ove sia necessario reperire pezzi di ricambio, per guasti bloccanti.

Per eventuali deroghe sui tempi, anche se concordate con il reparto, la ditta dovrà ricevere formale autorizzazione dalla struttura tecnica Titolare del Budget del contratto.

SLA – Manutenzione
Tipo Malfunzionamento/Non conformità	Tempo massimo di intervento	Tempo massimo di risoluzione
Grave malfunzioamento: blocco di una funzionalità con conseguente blocco dell’operatività clinica	1h (solare)	4 ore (solari)
Malfunzionamento: blocco di funzionalità senza blocco dell’operatività clinica	4h (solare)	8h (solare)

Definizioni:

 Blocco Operatività Clinica: si ha un blocco di operatività clinica quando viene compromessa una funzionalità necessaria per svolgere una attività di tipo sanitario sul paziente, e tale attività non sia clinicamente differibile, con conseguente obbligo da parte dell’operatore sanitario di passare a strumenti cartacei o sistemi informativi alternativi; non genera pertanto blocco della operatività clinica qualsiasi compromissione di funzionalità per cui l’operatore sanitario possa rinviare le attività connesse;

SLA – Assistenza

Ogni ulteriore richiesta di assistenza da parte delle Committenti (ad eccezione di quelle relative a segnalazioni di malfunzionamenti, per cui valgono i tempi definiti in tabella precedente) dovrà essere presa in carico entro 48 ore.

2. ATTIVITÀ DI MANUTENZIONE PREVENTIVA

manutenzione preventiva e verifiche di sicurezza: la ditta dovrà garantire l’esecuzione delle manutenzioni preventive previste dal costruttore sull’hardware e sul software (dovrà essere specificato il numero di manutenzioni preventive annue che verranno effettuate) e l’effettuazione con periodicità almeno annuale delle verifiche di sicurezza (anche informatica) secondo la normativa vigente, sulla base di una pianificazione concordata, con le UU.OO.:

 U.O. Ingegneria Clinica, per quanto di competenza dell’AOU di Modena

 U.O. Innovazione e Valutazione delle Tecnologie, per quanto di competenza dell’Azienda USL della Romagna

3. RAPPORTI DI INTERVENTO

la ditta dovrà far pervenire una copia (anche per e-mail) dei rapporti di intervento, debitamente controfirmati da un referente del reparto. Tale documentazione dovrà risultare completa ed esaustiva e sarà vincolante per il pagamento del canone di noleggio. A tal fine si precisa che:

 il verbale degli interventi di manutenzione correttiva dovrà riportare almeno: il numero (interno dell’Azienda USL di competenza) di chiamata di intervento, la data/ora inizio e fine intervento, la chiara indicazione delle operazioni svolte e l’esito finale;

 il verbale degli interventi di manutenzione preventiva e di verifiche sicurezza dovrà riportare almeno: il numero di inventario dell’Azienda USL di competenza, la data/ora inizio e fine intervento, la chiara indicazione delle operazioni svolte e l’esito finale; dovrà inoltre essere allegata copia della stampa della verifica di sicurezza elettrica, se eseguita.

4. MANUTENZIONE EVOLUTIVA

Manutenzione Evolutiva. Per ciascun componente del sistema installato, il Fornitore, a proprio carico onere e spese, dovrà erogare il servizio di manutenzione evolutiva, volto ad aggiornare l’hardware e il software, comprendendo sia gli aggiornamenti major release sia gli aggiornamenti minor release, in conformità ad eventuali aggiornamenti normativi comunitari e/o nazionali e/o regionali, ovvero ad aggiornamenti evolutivi prescritti dalla casa produttrice, salvo quanto diversamente concordato per iscritto con le Commitenti. Ogni volta che sarà effettuato un aggiornamento software dovrà essere fornito quanto necessario per il ripristino del sistema e dei software applicativi (su CD o altro supporto). Terminata ciascuna attività di aggiornamento evolutivo, il Fornitore dovrà rilasciare alle Committenti una copia dei supporti di installazione dei suddetti software aggiornati e quanto necessario per il ripristino del sistema operativo e dei software applicativi.

Al termine dell’attività di aggiornamento evolutivo, il Fornitore, a propria cura, onere e spese, deve svolgere un’attività di formazione/affiancamento agli utenti al fine di consentire il corretto funzionamento del sistema aggiornato.

Il servizio manutenzione tutto compreso (FR) si intende compreso nel costo della fornitura dal momento dell’inizio della stessa (prima consegna/installazione) fino al termine del periodo di garanzia (12 mesi almeno dal completamento del collaudo); lo stesso servizio, fornito

successivamente al periodo di garanzia, dovrà invece essere quotato nella documentazione di gara.

Il canone annuale di manutenzione FR non può superare il 15% del valore della fornitura

5. PROGRAMMA DI ADDESTRAMENTO PER IL PERSONALE POST VENDITA

Programma di addestramento ricorrente per il personale. Il Fornitore, a propria cura, onere e spese, dovrà svolgere, per tutta la durata del Contratto di Assistenza, un’opportuna attività di formazione e di affiancamento volta ad addestrare il personale dell’Azienda USL al corretto utilizzo del sistema;

L’Impresa aggiudicataria si impegna a fornire programma continuativo di training (FAD - Formazione a Distanza attraverso Web Based Learning System) al fine di poter garantire un continuo ed adeguato percorso formativo al personale ospedaliero durante il periodo di fornitura.

6. MODALITÀ DI INOLTRO DELLA RICHIESTA

I numeri di telefono e di fax dovranno essere: "Numeri per servizi di addebito al chiamato" denominati, secondo una terminologia di uso comune, numeri verdi, secondo quanto definito dall'art. 16 della Delibera n.9/03/CIR della AGCOM "Piano di numerazione nel settore delle telecomunicazioni e disciplina attuativa" (pubblicata sulla Gazzetta Ufficiale della Repubblica Italiana del 1° agosto 2003, n. 177); ovvero, in alternativa numeri geografici di rete fissa nazionale.

N.B.: Qualora l’offerente presenti offerta solo o anche per apparecchiature di altro fabbricante o non effettui direttamente la manutenzione, dovrà comunque assumersi la responsabilità del rispetto delle condizioni contrattuali ed adempiere agli obblighi della normativa comunitaria (DIR. 93/42 e s.m.i. e DIR 98/79 e s.m.i.) relativamente all’abilitazione, da parte del fabbricante, all’intervento tecnico ed all’utilizzo di ricambi originali, presentando idonea documentazione.

La ditta offerente dovrà descrivere per ogni rete di assistenza dedicata le caratteristiche del servizio prestato.

Nella suddetta ipotesi, su tali contratti si applicherà la disciplina del subappalto di cui all’art. 105 del D.Lgs. 50/2016.

NB: l’eventuale subappalto deve essere dichiarato al momento della presentazione dell’offerta.

b. Service Level Agreement (SLA)

I Livelli di Servizio Garantito secondo quanto richiesto al presente articolo si applicheranno, con tutte le sue conseguenze, dal giorno in cui verrà sottoscritta l’autorizzazione all’uso clinico del sistema, ovvero dal momento in cui la ditta aggiudicataria adempirà alle prescrizioni presentate in sede di collaudo.

c. Performance fornitura: Uptime, Downtime, Outage

Si richiede che il fornitore elabori un progetto che garantisca, per quanto di propria pertinenza,

elevata affidabilità e quindi tempi di indisponibilità del sistema complessivo (downtime, outage) che non superino le 20 ore solari all'anno.

Nel calcolo del downtime o outage si considerano i tempi di fermo determinati da eventi pianificati o imprevisti riconducibili al fornitore ed alla fornitura; sono invece escluse cause esterne, ovvero che vanno oltre il controllo del fornitore, e verificatisi senza colpa e negligenza del medesimo.

Ogni ditta concorrente dovrà quindi presentare apposita dichiarazione relativa al livello di servizio garantito nei termini sopra descritti per l’intero sistema offerto da integrare nella documentazione di gara.

d. Gestione avvisi di sicurezza e segnalazioni di incidenti

Con riferimento alle specifiche Direttive Europee sui Dispositivi Medici ed ai Regolamenti Europei sui Dispositivi Medici (vedasi sezione relativa alle normative di riferimento), nonchè alle specifiche Linee Guida MedDEV (Guidance document - Market surveillance - Guidelines on a Medical Devices Vigilance System - MEDDEV 2.12/1 rev.8) si definiscono i seguenti oneri a carico del fornitore in materia di Vigilanza sui Dispositivi Medici.

Tracciabilità: per tutti i prodotti forniti ed in particolare quelli classificati come Dispositivi Medici e Medico-Diagnostici in vitro, l'OE dovrà garantire un sistema di rintracciabilità che consenta una rapida individuazione per l'esecuzione di eventuali azioni di correttive (RECALL, FSA, FSCA, etc.).

L'OE è tenuto a tutte le azioni correttive previste da eventuali Avvisi di Sicurezza compresa la sostituzione, senza alcun onere aggiuntivo.

Avvisi di Sicurezza: L'OE Aggiudicatario si impegna a notificare al Responsabile della UO IVT ogni richiamo, alert o difetto di qualsiasi componente delle TS incluse nella fornitura nulla escluso, entro cinque (5) giorni dal primo annuncio in qualsiasi Nazione. L'OE si impegna altresì a mettere a disposizione le necessarie risorse per minimizzare le conseguenze conseguenti agli Avvisi.

Segnalazione di Incidente:

 nel caso di segnalazione di incidente riguardante la fornitura di cui al presente CSA da parte di operatori della Azienda USL di competenza, l'OE Aggiudicatario si impegna a fornire all’Azienda USL stessa nella figura del Responsabile della:

◦ U.O. Ingegneria Clinica, per quanto di competenza dell’AOU di Modena

◦ U.O. Innovazione e Valutazione delle Tecnologie, per quanto di competenza dell’Azienda USL della Romagna

i rapporti conseguenti elaborati per il Ministero della Salute (intendendosi per rapporti quello: iniziale, follow up e di chiusura relativi all'incidente segnalato: Report Form Manufacturer'sIncident Report Medical Devices Vigilance System - MIR);

 nel caso l'OE ravvisi situazioni di incidente presso questa Azienda per cui sia necessaria la segnalazione alla AC, questi è tenuto altresì a darne immediata notifica anche all’Azienda USL di competenza nella figura del Responsabile della:

◦ U.O. Ingegneria Clinica, per quanto di competenza dell’AOU di Modena

◦ U.O. Innovazione e Valutazione delle Tecnologie, per quanto di competenza dell’Azienda

USL della Romagna

nella figura del Responsabile della UO IVT fornendo altresì il relativo MIR;

I prodotti classificati come Dispositivi Medici, a norma della Direttiva n. 93/42 CE recepita dal D.lgs

n. 46 del 24.02.97 e Dispositivi Medico-diagnostici in vitro, a norma della Direttiva n. 98/79 CE recepita dal D.lgs. n. 332 del 08/09/2000, possono essere acquistati, utilizzati, dispensati nell’ambito del Servizio Sanitario Nazionale se in possesso del numero identificativo di iscrizione nel Repertorio dei dispositivi medici di cui al decreto 21 dicembre 2009 "modifiche ed integrazioni al decreto 20 febbraio 2007 recante" Nuove modalità per gli adempimenti previsti per la registrazione dei dispositivi impiantabili attivi nonché per l'iscrizione nel Repertorio dei dispositivi medici". Pertanto la Ditta dovrà riportare in offerta il numero di Repertorio e l’indicazione della relativa Classificazione Nazionale Dispositivi Medici (CND). La Ditta dovrà garantire un sistema di rintracciabilità che consenta un rapido blocco del lotto oggetto della segnalazione ed una rapida sostituzione dello stesso, senza alcun onere aggiuntivo.

La Ditta Aggiudicataria inadempiente incorrerà nelle penalità previste all'apposito articolo.

e. Condizioni di fine contratto

Al termine del contratto, la ditta fornitrice dovrà farsi carico di eseguire le operazioni atte a recuperare e rendere disponibili tutti i dati e i documenti presenti negli archivi del sistema realizzato. A tale proposito, a completamento della fase di deployment e attivazione sistema offerto, l’aggiudicatario della gara dovrà fornire un documento in cui siano esplicitate le operazioni necessarie a consentire l'esportazione dei dati finalizzata all’importazione in un diverso sistema, ed una stima del tempo necessario ad eseguire tali operazioni allo scadere del contratto. Si precisa che l’onere relativo a tale attività è incluso nei costi contratto e nessun altro costo od onere potrà essere richiesto o imputato al committente. Tale impegno dovrà essere esplicitato chiaramente nell’offerta.

Inoltre la ditta aggiudicataria dovrà rendersi disponibile a un periodo di transizione di un congruo numero di giorni, necessari e sufficienti per completare l’operazione o rendere autonomo il fornitore subentrante al completamento di tale attività, durante il quale affiancare l’impresa subentrante per la presa in carico da parte di quest’ultima di tutti i servizi, tale onere relativo a tale attività dovrà essere incluso nei costi della fornitura.

Al fine di rendere il più efficace possibile l’avvicendamento contrattuale al termine del periodo contrattuale, la ditta aggiudicataria dovrà garantire la reversibilità completa dei dati e la documentazione tecnica necessaria alla loro trasferibilità entro due mesi dall’aggiudicazione ad altro fornitore.

Art. 7. Penali

La Committenza effettuerà verifiche finalizzate a monitorare/controllare gli SLA previsti ed in generale le modalità di fornitura dei servizi. Qualora venissero riscontrate inadempienze rispetto al valore degli indicatori e dei livelli di servizio richiesto, la Committenza, nel rispetto delle norme

vigenti e secondo le condizioni, le modalità, i termini e le prescrizioni contenute nel presente capitolato, potrà richiedere l’applicazione delle seguenti penali.

FATTISPECIE

IMPORTO

Per ogni giorno solare di ritardo rispetto al tempo massimo di

consegna/installazione indicato nel crono programma

€ 1.000,00

Per ogni orga di ritardo nella risoluzione in caso di Grave Malfunzionamento: il sistema è indisponibile o funzionalità

critica indisponibile

€ 100,00

Per ogni giorno di ritardo nella risoluzione in caso di

Malfunzionamento: Il sistema è parzialmente indisponibile in funzionalità non critiche

€ 300,00

Per ogni giorno di ritardo nella risoluzione per tutti gli altri casi

non precedentemente compresi

€ 100,00

Per ogni controllo di qualità/funzionali/verifica di sicurezza

elettrica previsto e non effettuato

€ 500,00

Per ogni manutenzione preventiva prevista e non effettuata

€ 1.000,00

Per ogni giorno lavorativo di fermo macchina ulteriore a quelli

indicati

€ 1.000,00

Per ogni inadempienza rispetto a quanto previsto dal capitolato

e dalla documentazione di gara (es: rispetto agli obblighi in tema di Vigilanza sui DM)

€ 1.000,00

Nota: si considerano i ritardi anche rispetto ai tempi di attuazione intermedi previsti per le singole fasi/attività indicate nel crono programma.

Art. 8. Configurazione

Il contenuto della configurazione deve coincidere qualitativamente con quanto riportato in Allegato J Fac simile offerta economica.

Di seguito un quadro di contesto con le esigenze relative alla procedura in corso (“Q.tà minima garantita”) e le esigenze a tendere (100% dei posti letto intensivi delle rispettive AUSL/AOU)

Tabella 1 - Quadro esigenziale posti letto

Ambito Territoriale

Posti Letto

da garantire come quantità minima in fornitura

Ulteriori Posti Letto opzionali

AUSL

Romagna

AOU Modena

AUSL

Modena

Di cui il dettaglio

Ambito Territoriale	Sede	Posti Letto	Modalità Introduzione CCE secondo la presente gara di fornitura
AUSL Romagna	Totale Posti Letto	114
Rimini	Rimini - HUB COVID Ospedale "Infermi"	34	Quantità minima da garantire in fornitura
	Rimini Ospedale "Infermi"- Terapia Intensiva	15	opzionali
	Rimini Ospedale "Infermi" - Recovery Room	4	opzionali
	Riccione Ospedale "Ceccarini" Terapia Intensiva	10	opzionali
Ravenna	Ravenna Ospedale Terapia Intensiva	12	opzionali
	Faenza Ospedale Terapia Intensiva	8	opzionali
	Lugo Ospedale Terapia Intensiva	6	opzionali
Xxxxx	Xxxxx Xxxxxxxx Xxxxxxx Xxxxxxxxx	0	opzionali
Xxxxxx	Xxxxxx Xxxxxxxx Xxxxxxx Xxxxxxxxx	00	opzionali
AOU Modena	Totale Posti Letto	82
Policlinico	HUB Covid	30	Quantità minima da garantire in fornitura
Policlinico	Rianimazione	10	opzionali
Baggiovara	HUB Covid	18	Quantità minima da garantire in fornitura
Baggiovara	Rianimazione	24	opzionali
AUSL Modena	Totale Posti Letto	10
Carpi	Rianimazione Ospedale Ramazzini	10	opzionali

La configurazione deve essere strutturata come segue:

 Componenti base (infrastruttura e moduli richiesti). Quantità di fornitura

 Componenti opzionali (moduli integrativi e posti letto aggiuntivi)

Art. 9. Componenti BASE

Per ogni Azienda:

 Infrastruttura HW (predisposta per la gestione del totale dei posti letto, rif. Tabella 1);

 HW posto letto inclusi in fornitura (Q.tà minima garantita);

 Infrastruttura SW (predisposta per la gestione del totale dei posti letto, rif. Tabella 1);

 SW posto letto inclusi in fornitura (Q.tà minima garantita);

 HW per Server/DB a livello locale;

 Moduli richiesti: Il sistema offerto, oltre alla cartella clinica per terapia intensiva oggetto di gara, deve comprendere, in riferimento alle esigenze dichiarate nella tabella sottostante, i moduli seguenti:

Tabella 2 - Moduli

Modulo	AOU Modena	Riferimento Specifiche	AUSL Romagna	Riferimento Specifiche
Cartella clinica anestesiologica di sala operatoria	Opzionale		Non richiesto
Gestione flusso sala operatoria	Opzionale		Non richiesto
Cartella clinica Terapia Intensiva Neonatale	Opzionale		Opzionale
Integrazione Anagrafica Aziendale	Richiesto	Appendice. 1.a	Richiesto	Appendice. 1.b
Integrazione ADT	Richiesto	Appendice. 2.a	Richiesto	Appendice. 2.b
Integrazione Order Entry	Richiesto	Appendice. 3.a	Richiesto	Appendice. 3.b
Integrazione RIS- PACS	Richiesto	Appendice. 4.a	Richiesta	Appendice. 4.b

Integrazione archivio farmaci di reparto e centrale	Richiesto	Appendice. 5.a	Richiesto	Appendice. 5.b
Integrazione Laboratorio Analisi	Richiesto	Appendice. 6.a	Richiesto	Appendice. 6.b
Integrazione anatomia patologica	Opzionale	Appendice. 7.a	Richiesto	Appendice. 7.b
Emoteca Trasfusionale	Opzionale	Appendice. 8.a	Richiesto	Appendice. 8.b
Integrazione DM a posto letto	Richiesto	0	Richiesto	0
Gestione Privacy e Sicurezza Informatica	Richiesto	Appendice. 10.a	Richiesto	Appendice. 10.b
LDAP/Active Directory	Richiesto	Appendice. 11.a	Richiesto	Appendice. 11.b
Soluzione di business continuity e disaster recovery con definizione dei tempi di ripristino e livello di perdita dati accettabile	Xxxxxxxxx	Appendice. 12	Richiesto	Appendice. 12
Integrazione HL7 outbound (referti, report)	Richiesto	Appendice. 13	Richiesto	Appendice. 13
Funzionalità di Business Intelligence	Richiesto	Appendice. 14	Richiesto	Appendice. 14
Recupero dei precedenti	Non richiesto		Xxxxxxxxx	Appendice. 15

Appendice. 1. Gestione e Integrazione Anagrafica

In linea generale, traendo spunto anche dalla Linee Guida della Regione Xxxxxx Xxxxxxx per l’implementazione della Cartella Clinica Elettronica, si indicano come auspicabili le seguenti caratteristiche:

o Anagrafica Parziale (gestione delle sole posizioni con dati clinici presenti sul sistema; senza replica dell’anagrafe totale);

o Ricezione Variazioni Anagrafiche (da applicare a posizioni presenti sul sistema);

o Ricezione Fusioni Anagrafiche (da applicare a posizioni presenti sul sistema).

Di seguito sono rappresentate le specifiche per singola azienda sanitaria.

a. Specifiche Anagrafica AOU Modena

Riferimento:

Allegato T3: AGORA' - Integrazione Anagrafica - Specifiche HL7_v.1

Allegato T4: AGORA' - Integrazione Anagrafiche di Base - Specifiche HL7_v.1.0

b. Specifiche Anagrafica AUSL Romagna

Ambito	Destinazione	Software	Protocolli	Note
Cesena – Forlì		People	Chiamata di
– Ravenna -			contesto o
Rimini			attraverso
			integrazione con
			ADT Engineering

Appendice. 2. Integrazione ADT

‐ Integrazione ADT – ricezione e gestione delle seguenti tipologie di messaggio:

o Accettazione;

o Dimissione;

o Trasferimento;

o Annullamento Accettazione;

o Annullamento Dimissione;

o Annullamento Trasferimento;

o Spostamento Episodio ADT su anagrafica differente.

Di seguito sono rappresentate le specifiche per singola azienda sanitaria.

a. Specifiche ADT AOU Modena

Riferimento: Allegato T2: AGORA' - Integrazione ADT - Specifiche HL7_v.1.0

Possibilità di integrazione con gli applicativi aziendali anche mediante chiamata di contesto, configurabile per stabilimento ospedaliero.

b. Specifiche ADT AUSL Romagna

La gestione del paziente, dall’accettazione alla dimissione o trasferimento, deve avvenire tramite la cartella clinica informatizzata di Terapia Intensiva; la stessa cartella deve gestire tutto il percorso clinico del paziente durante tale periodo di ricovero.

i. Ammissione al reparto

Ambito

Provenienza

Software di

interfacciamento

Protocolli di

interfacciamento

Note

Cesena – Forlì

– Ravenna - Rimini

Pronto Soccorso

ADT di Engineering

‐ Chiamate di contesto

‐ Web service

‐ Messaggistica HL7

‐ Vista

Necessario acquisire direttamente in cartella:

‐ Anamnesi

‐ lettera di dimissione

.pdf

‐ altri dati ritenuti di

Percorso post

operatorio

Trasferimento da

reparto stesso ospedale

Trasferimento da altri ospedali aziendali

			interesse e memorizzati in box testuali (liquidi assunti, terapie eseguite, …)
	Trasferimento da provenienza esterne all'azienda	Chiamata di contesto con caricamento anagrafica
	Accesso diretto
All’accettazione del paziente dovrà essere effettuata chiamata di contesto al TAB Privacy di ADT per raccogliere il consenso del paziente ed eventuali riferimenti telefonici a cui dare informazioni sul paziente. La cartella TI non dovrà assolutamente raccogliere in locale numeri di telefono per dare comunicazioni sul paziente. Le informazioni sul consenso saranno visibili in apposita vista in sola lettura.

Oltre le richieste indicate è da prevedere la possibilità di integrazione con gli applicativi aziendali specifici anche mediante chiamata di contesto, configurabile per ambito territoriale.

ii. Trasferimento dalla Terapia Intensiva – Dimissione

La dimissione deve essere effettuata tramite il programma di cartella clinica di terapia intensiva. In fase di configurazioni saranno definiti i passaggi “informativi” necessari alla conclusione della procedura di dimissione verso altri sistemi informativi coinvolti e la definizione di quali dati archiviaare, e della destinazione di archiviazione, della cartella del paziente.

Ambito	Destinazione	Software di interfacciamento	Protocolli di interfacciamento	Note
Cesena – Forlì – Ravenna - Rimini	Sala operatoria	ADT di Engineering	‐ Chiamate di contesto ‐ Web service ‐ Messaggistica HL7 ‐ Vista	Necessario trasferire: ‐ lettera di dimissione .pdf ‐ altri dati ritenuti di interesse e memorizzati in box testuali
	Sub Intensiva
	Reparto stesso ospedale o altro ospedale aziendale
È Necessario l’invio verso il backbone di Sole dei documenti di dimissione: l’invio verso Sole deve avvenire 24h dopo la conclusione del percorso clinico del paziente; l’invio dei documenti verso altri reparti deve avvenire contestualmente al trasferimento.

Mediante chiamata di contesto in ADT dovrà essere compilata da parte del medico la SDO.

A completamento e a conferma dell'inserimento delle informazioni il sistema di Xxxxxxxx TI dovrà inviare un messaggio HL7 per dimissione paziente.

La chiamata di contest ad ADT dovrà essere utilizzata per completare le informazione anagrafiche necessarie alla compilazione della SDO quali ad es titolo di studio, stato civile, ecc., quando mancanti nei ricoveri di PS.

Oltre le richieste indicate è da prevedere la possibilità di integrazione con gli applicativi aziendali specifici anche mediante chiamata di contesto, configurabile per ambito territoriale.

Appendice. 3. Integrazione Order Entry

o Ove disponibile sistema di Order Entry generalista interfacciabile a servizi, integrazione a servizi allo scopo di trasmettere ordini di qualsiasi tipo tra quelli previsti presso la strututra sanitaria per l’unità di terapia intensiva

o Ove non disponibile sistema di Order Entry generalista interfacciabile a servizi, integrazione a servizi o tramite apertura di contesto verso singoli sistemi di Order Entry dipartimentali (specialistici)

o Ove disponibile, ricevere referti/documentazione clinica tramite notifica attiva da CDR o singoli sistemi dipartimentali; tali documenti devono essere inclusi in cartella (materializzazione firmata)

o Ove disponibile sistema RIS/PACS o CDR adeguati, prevedere integrazione per accesso diretto agli studi radiologici associati ai referti, tramite opportuno client del sistema o tramite integrazione con passaggio di contesto

Le funzionalità minime richieste sono:

 Gestione richieste verso erogatori di servizi/reparti;

 Gestione messaggi di ritorno;

 Visualizzazione referti.

Di seguito sono rappresentate le specifiche per singola azienda sanitaria.

a. Specifiche Order Entry AOU Modena

Riferimento :Allegato T1: AGORA' - Integrazione Order Entry - Specifiche HL7_v.1.0

Possibilità di integrazione con gli applicativi aziendali anche mediante chiamata di contesto, configurabile per stabilimento ospedaliero.

b. Specifiche Order Entry AUSL Romagna

Gestione richieste da Terapia Intensiva – Order Entry

La gestione del paziente deve avvenire tramite la cartella clinica informatizzata di Terapia Intensiva; la stessa cartella deve gestire tutto il percorso clinico del paziente durante tale periodo di ricovero: tutte le richieste di consulenza o prestazioni esterne al reparto che richiedono l’immissione di ordini e la produzione di referti, devono potere essere gestite, e i referti visualizzati, tramite tale strumento informatico.

Deve essere possibile inserire richieste di esami e consulenze direttamente dalla Cartella clinica, ricevere informazioni riguardo lo stato della richiesta, la presenza del referto e la visualizzazione dello stesso.

Ambito	Destinatario della richiesta	Software di interfacciamento	Protocolli di interfacciamento	Note
Cesena – Forlì – Ravenna - Rimini	Radiologia	SIO Aziendale		L’interfacciament o deve prevedere la gestione dei messaggi di ritorno per il cambio di stato della richiesta (richiesta, erogata, refertata) e la visualizzazione dei referti
	Anatomia Patologica
	Altri reparti per consulenze
	Microbiologia Pievesestina	DNLAB – Dedalus Italia SpA	Integrazione diretta HL7 (Specifiche documento DEDALUS: OP-OM-OF_LIS Integrazioni HL7 ver. 1.2)	L’interfacciament o deve prevedere la gestione dei messaggi di ritorno per il cambio di stato della richiesta (richiesta, erogata, refertata) e la visualizzazione dei referti

Cesena	Cardiologia (ECG, Angiografie, Ecocardio, Elettrofisiologia)	SIO Aziendale		Quando disponibile su SIO aziendale

Forlì	Cardiologia (ECG, Angiografie, Ecocardio, Elettrofisiologia)	SIO Aziendale		Quando disponibile su SIO aziendale

Ravenna

Cardiologia (ECG, Angiografie, Ecocardio,

Elettrofisiologia)

SIO Aziendale

Quando disponibile su SIO aziendale

Rimini

Cardiologia (ECG, Angiografie, Ecocardio,

Elettrofisiologia)

SIO Aziendale

Quando disponibile su SIO aziendale

Oltre le richieste indicate è da prevedere la possibilità di integrazione con gli applicativi aziendali specifici anche mediante chiamata di contesto, configurabile per ambito territoriale.

Appendice. 4. Integrazione RIS-PACS

Le funzionalità minime richieste sono:

 Gestione richieste verso Radiologia;

 Gestione messaggi di ritorno;

 Visualizzazione referti e immagini.

Di seguito sono rappresentate le specifiche per singola azienda sanitaria

a. Specifiche RIS-PACS AOU Modena

Oltre le richieste generali è da prevedere la possibilità di integrazione con gli applicativi aziendali specifici anche mediante chiamata di contesto, configurabile per stabilimento ospedaliero.

b. Specifiche RIS-PACS AUSL Romagna

La gestione del paziente deve avvenire tramite la cartella clinica informatizzata di Terapia Intensiva: tutte le richieste di consulenza o prestazioni esterne al reparto che richiedono l’immissione di ordini e la produzione di referti, devono potere essere gestite, e i referti visualizzati, tramite tale strumento informatico.

Ambito

Destinatario

della richiesta

Software di

interfacciamento

Protocolli di

interfacciamento

Note

Cesena – Forlì

– Ravenna - Rimini

Radiologia

SIO Aziendale

L’interfacciament o deve prevedere la gestione dei messaggi di ritorno per il cambio di stato della richiesta (richiesta, erogata, refertata) e la visualizzazione dei referti e immagini (queste

ultime attraverso

visualizzatore in uso presso AUSL

Romagna)

Oltre le richieste indicate è da prevedere la possibilità di integrazione con gli applicativi aziendali specifici anche mediante chiamata di contesto, configurabile per ambito territoriale.

Appendice. 5. Integrazione Archivio farmaci di reparto

Di seguito sono rappresentate le specifiche per singola azienda sanitaria.

a. Specifiche Archivio farmaci di reparto AOU Modena

Possibilità di integrazione con gli applicativi aziendali anche mediante chiamata di contesto e web service, configurabile per stabilimento ospedaliero.

b. Specifiche Archivio farmaci di reparto AUSL Romagna

Ambito

Destinatario

della richiesta

Software di

interfacciamento

Protocolli di

interfacciamento

Note

Cesena – Forlì

– Ravenna - Rimini

Farmacia (eventuale opzione) Gestione Farmaci Dispositivi Medici et.

Inserimento della sola anagrafica – GAAC - Farmadati

Oltre le richieste indicate è da prevedere la possibilità di integrazione con gli applicativi aziendali specifici anche mediante chiamata di contesto e web service, configurabile per ambito territoriale.

Appendice. 6. Integrazione Laboratorio Analisi

Le funzionalità minime richieste sono:

 Gestione richieste verso Laboratorio Analisi;

 Gestione messaggi di ritorno;

 Visualizzazione referti.

Di seguito sono rappresentate le specifiche per singola azienda sanitaria.

a. Specifiche Laboratorio Analisi AOU Modena

Oltre le richieste generali è da prevedere la possibilità di integrazione con gli applicativi aziendali specifici anche mediante chiamata di contesto, configurabile per stabilimento ospedaliero.

b. Specifiche Laboratorio Analisi AUSL Romagna

Ambito

Destinatario

della richiesta

Software di

interfacciamento

Protocolli di

interfacciamento

Note

Cesena – Forlì

– Ravenna - Rimini

Laboratorio Analisi

DNLAB – Dedalus Italia SpA

Integrazione diretta HL7 (Specifiche documento DEDALUS:

OP-OM-OF_LIS

Integrazioni HL7 ver. 1.2)

L’interfacciament o deve prevedere la gestione dei messaggi di ritorno per il cambio di stato della richiesta (richiesta, erogata, refertata) e la visualizzazione

dei referti

Oltre le richieste indicate è da prevedere la possibilità di integrazione con gli applicativi aziendali specifici anche mediante chiamata di contesto, configurabile per ambito territoriale.

Appendice. 7. Integrazione Anatomia Patologica

Le funzionalità minime richieste sono:

 Gestione richieste verso Anatomia Patologica;

 Gestione messaggi di ritorno;

 Visualizzazione referti.

Di seguito sono rappresentate le specifiche per singola azienda sanitaria.

a. Specifiche Anatomia Patologica AOU Modena

Oltre le richieste generali è da prevedere la possibilità di integrazione con gli applicativi aziendali specifici anche mediante chiamata di contesto, configurabile per stabilimento ospedaliero.

Al momento non presente in AOU Modena.

b. Specifiche Anatomia Patologica AUSL Romagna

Ambito

Destinatario

della richiesta

Software di

interfacciamento

Protocolli di

interfacciamento

Note

Cesena – Forlì

– Ravenna - Rimini

Anatomia Patologica

SIO Aziendale

L’interfacciament o deve prevedere la gestione dei messaggi di ritorno per il cambio di stato della richiesta (richiesta, erogata, refertata) e la visualizzazione

dei referti

Oltre le richieste indicate è da prevedere la possibilità di integrazione con gli applicativi aziendali specifici anche mediante chiamata di contesto, configurabile per ambito territoriale.

Appendice. 8. Integrazione Emoteca Trasfusionale

Le funzionalità minime richieste sono:

 Gestione richieste verso Emoteca Trasfusionale;

 Gestione messaggi di ritorno.

Di seguito sono rappresentate le specifiche per singola azienda sanitaria.

a. Specifiche Emoteca Trasfusionale AOU Modena

Oltre le richieste generali è da prevedere la possibilità di integrazione con gli applicativi aziendali specifici anche mediante chiamata di contesto, configurabile per stabilimento ospedaliero.

Al momento non disponibile in AOU Modena.

b. Specifiche Emoteca Trasfusionale AUSL Romagna

Ambito

Destinatario

della richiesta

Software di

interfacciamento

Protocolli di

interfacciamento

Note

Cesena – Forlì

– Ravenna - Rimini

Emoteca Trasfusionale

Order Entry - Log80

Chiamata di contesto (riferimento procedura aziendale: PA184 Gestione approvvigionamen to, conservazione, stoccaggio e distribuzione dell'Emoteca Unica della Romagna rev. 0

del 14-12-2018 e

PA139 Gestione della terapia trasfusionale- AUSL Romagna rev. 0 del 13-12-

2018)

L’interfacciament o deve prevedere la gestione dei messaggi di ritorno per il cambio di stato della richiesta

Oltre le richieste indicate è da prevedere la possibilità di integrazione con gli applicativi aziendali specifici anche mediante chiamata di contesto, configurabile per ambito territoriale.

Appendice. 9. Integrazioni con Dispositivi Medici

Il sistema offerto deve comprendere un numero adeguato di strumenti per integrazione/interfacciamento con apparecchiature elettromedicali, a posto letto e di reparto; tali dispostivi possono essere di qualsiasi tipologia quali, ad esempio (a titolo esemplificativo ma non esaustivo):

 Elettrocardiografi;

 Ventilatori polmonari;

 Pompe infusionali (singola o rack);

 Pompe a siringa;

 Pompe per alimentazione enterale;

 Monitor multiparametrici;

 Sistemi per monitoraggio emodinamico;

 Letti per terapia intensiva – letti bilancia;

 ..

Lo strumento di integrazione deve consentire l’interfacciamento, a posto letto, di un numero minimo di dispositivi come sotto riportato; deve comunque essere possibile aumentare, per specifiche necessità del reparto o del singolo posto letto, il numero di dispositivi contemporaneamente integrabili.

Tipologia	AOU Modena		AUSL Romagna
Tipologia	Xxxxxxxxx	N x Posto letto	Richiesto	N x Posto letto
Ventilatore Polmonare	No (tramite Monitor multiparametrico)	-	Sì	1
Monitor multiparametrico	Sì (1)	1	Sì	1
Rack pompe	Sì (2)	1	Sì	2
Letto elettrico/bilancia	Sì	1	Sì	1
Ingresso per altra strumentazione	Sì	2	Sì	2

(apparecchiature emodialisi/Arco a C/..)
N. Totale ingressi (minimo)	5		6

(1): l’integrazione può avvenire anche attraverso la centrali di monitoraggio che collega i monitor multiparametrici posto letto.

(2): riferimento allegato T5 BBRAUN - SOLUZIONE PROGETTUALE PER L’INTEGRAZIONE CON LA CARTELLA CLINICA

Il sistema offerto deve inoltre garantire, senza oneri aggiuntivi, il collegamento e l’interfacciamento/integrazione di apparecchiature di reparto quali ad esempio sistemi per tromboelastometria/trombelastografia, POCT (Analisi Point of Care), ecc..

La modalità di integrazione Interoperabilità devono avvenire nel rispetto dei principi definiti dalla normativa sui dispositivi medici ed in particolare si riportano le definizioni del regolamento UE 745/2027 art. 2 punti 18 e 19:

18) «compatibilità»:la capacità di un dispositivo, compreso il software, quando utilizzato insieme a uno o più altri dispositivi, conformemente alla sua destinazione d'uso, di: a) conseguire le prestazioni senza perdere né compromettere la capacità di funzionare come previsto; e/o b) essere integrato e/o funzionare senza che sia necessario modificare o adattare alcuna parte dei dispositivi combinati; e/o c) essere utilizzato insieme ad altri dispositivi senza conflitti/interferenze o reazioni avverse.

19) «interoperabilità»:la capacità di due o più dispositivi, compreso il software, dello stesso fabbricante o di fabbricanti diversi di: a) scambiare informazioni e utilizzare le informazioni scambiate ai fini della corretta esecuzione di una funzione specifica senza modifica del contenuto dei dati; e/o b) comunicare tra di loro; e/o c) funzionare congiuntamente come previsto;

l’integrazione deve avvenire inoltre:

 mediante soluzioni riconosciute come standard (reale o de facto) come ad esempio quelli promossi dalle organizzazioni: XX0, XXXX, DICOM, IHE;

Il livello di interoperabilità da garantire inoltre deve comprendere:

‐ visualizzazione ed archiviazione;

‐ interpretazione ed analisi delle informazioni;

Appendice. 10. Gestione Privacy e Sicurezza Informatica

Il sistema offerto deve garantire quanto segue:

‐ Aderenza norme di legge;

‐ Il sistema applicativo deve essere in grado di assicurare, a livello di storage, la pseudonimizzazione e la cifratura dei dati personali;

‐ Il sistema applicativo deve assicurare su base permanente la riservatezza, l'integrità, la disponibilità e la resilienza delle funzionalità offerte;

‐ Il fornitore delle funzionalità applicative è in grado di fornire, relativamente alla propria parte di competenza, la necessaria documentazione per permettere al titolare di definire una procedura per testare, verificare e valutare regolarmente l'efficacia delle misure tecniche e organizzative al fine di garantire la sicurezza del trattamento;

‐ Qualora vi siano interconnessioni telematiche fra il fornitore delle funzionalità applicative e gli enti fruitori (per fini di assistenza, manutenzione, ecc…), il fornitore delle funzionalità applicative deve essere in grado di garantire un livello adeguato di protezione della propria infrastruttura tale da minimizzare il rischio di violazioni di sicurezza che provengano da tale canale;

‐ Deve essere disponibile documentazione che attesti le misure tecniche di implementazione architetturale di

o privacy by design

o privacy by default

Se non fosse possibile rispettare qualche aspetto della normativa sulla privacy in quanto in contraddizione con la certificazione CE del prodotto come Dispositivo Medico in funzione della destinazione d’uso e dell’analisi del rischio del prodotto del fabbricante motivarla su documento specifico.

a. Specifiche Gestione Privacy e Sicurezza Informatica AOU Modena

Nulla di aggiuntivo, rispetto a quanto sopra.

b. Specifiche Gestione Privacy e Sicurezza Informatica AUSL Romagna

Ambito

Destinazione

Software

Protocolli

Note

Cesena – Forlì

– Ravenna - Rimini

ADT di Engineering

Chiamata di contesto tab

privacy

Appendice. 11. LDAP/Active Directory

Il sistema offerto deve apporggiarsi su sistema di gestione delle credenziali aziendali.

a. Specifiche LDAP/Active Directory AOU Modena

Deve supportare la funzione single sign on mediante integrazione con AD/LDAP di Azienda da cui ereditare credenziali di accesso, configurabile per Azienda sanitaria.

Il Sistema di autentificazione di dominio è basato su Active Directory di Microsoft, accessibile tramite uno o più LDAP aziendale.

b. Specifiche LDAP/Active Directory AUSL Romagna

Deve supportare la funzione single sign on mediante integrazione con AD/LDAP di Azienda da cui ereditare credenziali di accesso e abilitazioni funzionali.

Il Sistema di autentificazione di dominio è basato su Active Directory di Microsoft, accessibile tramite LDAP, separato e distinto fra i quattro ambiti territoriali dell'Azienda (Rimini, Xxxxxx, Xxxxx, Xxxxxxx).

Nel valutare questo aspetto si deve considerare la complessità del sistema Romagna nella sua articolazione per ambiti territoriali.

Appendice. 12. Soluzione di Business Continuity e Disaster Recovery

a. Caratteristiche generali dell’architettura

La proposta tecnica del fornitore deve contenere una analisi del rischio sulla assoluta continuità di servizio e indicativamente contemplare un progetto basato su un’architettura HW/SW con le seguenti caratteristiche:

 garantire il funzionamento ottimale del sistema senza rallentamenti e difficoltà di accesso di alcun tipo;

 essere dimensionato in funzione del carico di lavoro (posti letto) indicati nel presente documento;

 essere costantemente aggiornato e conforme a quanto richiesto dagli adeguamenti normativi di AGID, GDPR, legislazione DM e dai regolamenti interni attualmente in vigore nelle aziende interessate;

 non deve prevedere solo storage locale per dati in versione unica, ivi compresi i settings della specifica macchina, se presenti.

 l’applicativo deve avere modalità di aggiornamento, al primo utilizzo e in seguito facilmente fruibili. Se è necessario (es. per aggiornamenti), che l’utente disponga di diritti di amministratore o power user del PC va specificato;

 deve essere possibile l’accesso all’applicativo ad un numero di utenti concorrenti potenzialmente illimitato;

 deve garantire indipendenza da applicativi locali ad esclusione di applicativi comuni distribuibili senza vincoli di licenza onerosa (es. Acrobat Reader, ecc.);

 deve permettere di tracciare ogni modifica alle informazioni gestite. La tracciabilità deve comprendere la possibilità di attribuire la paternità di ogni modifica;

 la base dati deve disporre di funzionalità di replica per la sicurezza dei dati e per le copie dei dati aggiornate a scopi di reportistica e business intelligence (per es. in caso di indagini epidemiologiche e di ricerca) senza impatto per le performance del sistema in produzione;

 deve essere implementabile sulle infrastrutture di rete ospedaliere e del territorio delle aziende committenti, le cui caratteristiche di banda sono riportate in Appendice. 16 e Appendice. 17 del presente documento ed essere conforme alla norma IEC 80001 ove applicabile. Devono comunque essere fornite le specifiche della banda dati necessaria all’utilizzo ottimale del sistema sia nella rete locale LAN, sia nella rete geografica WAN;

 deve essere implementabile in modo tale da garantire un’eventuale espansione del sistema in termini di posti letto e ulteriori siti attivabili;

 deve essere rispondente alle specifiche riportate anche in Appendice. 16 e Appendice. 17.

La ditta offerente dovrà proporre un’architettura, clusterizzata e/o ridondata, con implementazione del fail-over attivo, che consenta la centralizzazione a livello aziendale del sistema (dati e funzionalità) ma che garantisca al contempo accessibilità al sistema e continuità clinica anche in situazioni critiche (es. rallentamenti o inaccessibilità alla rete geografica WAN, interventi manutentivi con sostituzione di componenti a caldo,…). La soluzione proposta deve essere indicativamente costruita su più livelli:

 livello locale: dedicato al singolo presidio ospedaliero/Unità Operativa;

 livello centrale: installazione presso Data Center indicato dall’azienda committente;

 Disaster recovery: installazione presso sito dedicato.

Livello locale: le componenti HW e SW, ad esclusione di quanto indicato anche nelle Appendici 16 e 17, devono essere ricomprese nell’offerta.

Livello centrale: le componenti HW (Server) saranno messe a disposizione delle aziende committenti; le componenti SW, ad eccezione di quanto indicato anche nelle Appendici 16 e 17, devono essere ricomprese nell’offerta.

Disaster recovery: le componenti HW (Server) saranno messe a disposizione delle aziende committenti; le componenti SW, ad eccezione di quanto indicato anche nelle Appendici 16 e 17, devono essere ricomprese nell’offerta.

b. Business continuity e Disaster Recovery

Il sistema deve garantire adeguati livelli di sicurezza ed affidabilita per quanto riguarda accessibilita, riservatezza ed integrità dei dati, dovranno quindi essere previsti soluzioni di back- up/ridondanza e disaster recovery di adeguato livello.

L'architettura dovra assecondare l'organizzazione Aziendale e la distribuzione sul territorio dei punti in cui si svolge l'attività.

La ditta offerente dovrà presentare un progetto architetturale in grado di fornire, con adeguati livelli di ridondanza, il ripristino delle informazioni fino all’ultimo “commit”, per ogni funzionalità fornita. Il progetto dovrà essere dettagliato e documentato in ogni sua parte, includendo anche il ripristino

del sistema in produzione, e una stima dell’occupazione disco/risorse necessarie alla sua implementazione.

La ditta offerente dovrà proporre una soluzione per la gestione del Disaster Recovery il cui dimensionamento e architettura dovranno garantire adeguati SLA in merito alle tempistiche e alle modalità di ripristino.

Le aziende committenti mettono a disposizione, senza oneri aggiuntivi per l’aggiudicatario:

 Le infrastrutture presenti in un data center di Lepida, per ospitare l’infrastruttura del sistema di disaster recovery secondo l’architettura proposta. La relazione tecnica della ditta offerente dovrà riportare il dimensionamento complessivo delle macchine (CPU, RAM, disco) per soddisfare le esigenze del sistema di Disaster Recovery progettato;

 La connettività tra il data center primario e quello di Disaster Recovery;

 La connettività delle sedi della azienda sanitaria verso il sistema di Disaster Recovery, garantita attraverso la rete regionale Lepida;

La soluzione proposta dovrà essere caratterizzata da un’architettura che garantisca la continuità operativa (business continuity) in caso di rallentamento e/o malfunzionamento bloccante con interruzione del funzionamento di una parte qualsiasi del sistema.

Nell’ambito delle misure di continuità operativa è necessario che il sistema fornito preveda delle procedure atte a garantire la sicurezza del paziente in caso di indisponibilità del sistema informativo per qualsivoglia fattore, anche esterno al sistema stesso (es. rallentamenti e/o malfunzionamenti bloccanti legati alla connettività LAN e/o WAN, integrazioni con altri sistemi, servizi e/o componenti specifiche, ...). Tali procedure devono prevedere modalità e strumenti di accesso in lettura alle informazioni critiche delle pratiche della cartella in corso, da parte degli utenti abilitati: al fine di facilitarne la fruibilità, la lettura di tali informazioni dovranno essere aggregate per paziente o secondo criteri mirati alla specifica esigenza, con particolare attenzione alla gestione della terapia farmacologica.

In linea con tale esigenza si chiede che il sistema offerto, oltre al mantenimento di un’architettura a tre livelli, consenta il salvataggio, automatico e continuativo (con minimi intervalli definiti in fase di installazione), in formato leggibile standard (es. pdf) su una o più postazioni locali messe a disposizione dell’Azienda USL, del contenuto informativo delle cartelle in corso, facilmente visualizzabile o stampabile, direttamente nel sito di produzione. Di tali postazioni, la ditta fornitrice, deve indicare i minimi requisiti per supportare l’attività indicata.

Si riporta di seguito lo schema sintetico di quanto richiesto:

Livello	Sito installazione	A carico della ditta offerente	A carico della azienda committente	Da riportare nel progetto architetturale
Livello locale	Presidio	Componenti	Connettività	Specifiche
	Ospedaliero di	hardware (Macchine	LAN/WAN da e	dell’hardware e
	riferimento/Unità	server per	verso il sito di	del sw offerto e
	Operativa	installazione di	produzione.	dedicato a tale
		quanto necessario,	S.O. Open Source,	livello.

		SW, DB,..). Componenti SW specifiche e S.O. se non open source	Vmware	Specifiche e necessità impiantistiche
Livello centrale	Data Center indicato dall’Azienda committente	Componenti SW specifiche e S.O. se non open source	Connettività LAN/WAN S.O. Open Source, Vmware, Componenti Server	Specifiche del sw offerto e dedicato a tale livello. Specifiche delle componenti server richieste
Disaster Recovery	Data Center indicato dall’Azienda committente	Componenti SW specifiche e S.O. se non open source	Connettività LAN/WAN S.O. Open Source, Vmware,	Specifiche del sw offerto e dedicato a tale livello. Specifiche delle componenti server richieste
Postazioni locali di lettura	Presso il reparto di produzione	Componenti SW specifiche se non Open Source	Connettività LAN HW (PC) S.O.	Specifiche del sw offerto e dedicato a tale livello. Specifiche delle componenti hardware richieste

Tutte le scelte di progetto operate dovranno essere coniugate con un preciso piano di Business Continuity e Disaster Recovery riportato nella relazione tecnica (Allegato A1) con chiara ed esplicita descrizione dei sistemi di fail-over attivo e dichiarazione dei parametri RTO e RPO.

Il sistema di infrastruttura con i requisiti sopra indicati, dovrà essere progettato per garantire le migliori performance in termini di:

 usabilità, tempi di accesso ai dati e immagini

 recovery point objective (RPO)

 recovery time objective (RTO).

La descrizione della parte di progetto di cui a questa appendice può essere aggiuntiva alle 30 pagine di relazione tecnica generale.

Appendice. 13. Integrazione HL7 outbound (referti, report)

a. Specifiche HL7 outbound AOU Modena

Riferimento :Allegato T1: AGORA' - Integrazione Order Entry - Specifiche HL7_v.1.0

b. Specifiche HL7 outbound AUSL Romagna

Nulla di specifico.

Appendice. 14. Funzionalità di Business Intelligence

Il sistema dovrà fornire funzioni di Business Intelligence (BI) che consentano di analizzare e produrre report relativi a:

 prestazioni e performance delle UO:

o adempimento indicazioni accreditamento: visualizzazione, anche in tempo reale, ed estrazione delle informazioni richieste dalla procedura di accreditamento;

o reportistica per uso di presidi e farmaci; contabilità analitica per alcuni presidi e farmaci ad altro costo;

 casistica trattata dal punto di vista clinico – epidemiologico e relative performance di assistenza, con elaborazione di indicatori;

 prestazioni e performance a livello di azienda.

a. Specifiche Business Intelligence AOU Modena

Configurazione su database di tabelle in lettura dei dati presenti in cartella per accesso di sistemi terzi, sia in tempo reale che con aggiornamenti periodici non superiori alle 4 ore.

b. Specifiche Business Intelligence AUSL Romagna

Nulla di specifico.

Appendice. 15. Recupero dei precedenti

Non previsto.

a. Recupero precedenti AOU Modena

b. Recupero precedenti AUSL Romagna – ambito Rimini

Si chiede, per l’ambito territoriale di Rimini, una analisi dell’attuale sistema in uso ed una proposta sul recupero dei precedenti.

L’attuale sistema in uso presso gli ospedali di Rimini e Riccione è la cartella per Terapia Intensiva Innovian di Draeger.

La proposta di recupero dei dati deve comprendere:

1. analisi dei data base seguita da resoconto dettagliato che metta in evidenza tutti i dati che verranno migrati, gli eventuali dati che non potranno essere migrati ed eventuali altri limiti della migrazione;

2. definizione delle eventuali modifiche necessarie ai vecchi data base per assicurare la completa migrazione dei dati;

3. test di migrazione e revisione dei dati migrati nel test;

4. Migrazione finale del data base clinico entro l’avvio del periodo di prova in uso clinico del sistema;

5. Documento di relazione del risultato finale attestante tutti i dati che sono stati migrati nel data base del nuovo sistema e di tutti gli eventuali dati che non sara stato possibile trasferire dal vecchio data base;

Ognuno di questi punti deve essere dettagliatamente descritto nel progetto.

La migrazione dei data base dovra essere effettuata secondo quanto stabilito nel cronoprogramma delle attivita, comunque previa conferma della U.O. IVT.

Appendice. 16. AOU Modena: caratteristiche specifiche

Informazioni di tipo generale riguardanti l'AOU di Modena possono essere reperite sul sito web istituzionale: xxxxx://xxx.xxx.xx.xx .

a. Infrastruttura Server e DB

Tutto l’hardware necessario e i relativi S.O., solo se Open Source (ad es. Linux CentOS), saranno messi a disposizione dalla AOU di Modena .

Eventuali sistemi proprietari non di tipo Open Source sono da intendere a carico della ditta Aggiudicataria.

Il sistema offerto deve poter lavorare sia su infrastruttura fisica che virtuale. Ogni fornitore dovrà dettagliare le esigenze sia in termini di infrastruttura Hw che di Sistemi operativi necessari a garantire l’operatività del sistema.

Devono essere indicate le risorse impiegate dal sistema sia a livello di Application/web server che di Database server per ogni singola connessione dando la possibilità all’AOU di Modena di poter definire le risorse opportune dell’infrastruttura.

La configurazione del networking, degli instradamenti e della gestione dei DNS sarà a carico AOU di Modena. Si richiede al fornitore di specificare l’ambiente ed il protocollo utilizzato per la pubblicazione del sistema.

Sarà a carico della AOU Modena l’installazione dei Sistemi Operativi; sarà a carico della Ditta aggiudicataria la messa a punto del sistema comprensivo di: fornitura, installazione, configurazione, assistenza e manutenzione di ogni componente: sarà fornito dall’AOU di Modena un collegamento in VPN per l’accesso remoto.

Disaster Recovery: la ditta dovrà indicare una proposta di configurazione dell'infrastruttura atta a garantire la gestione clinica dei pazienti accettati ed in trattamento presso i reparti di Terapia Intensiva, fornendo tutte le informazioni utili al proseguimento delle cure in estemporanea ed al recupero successivo del flusso informativo dei singoli pazienti.

Tutti i dati e le informazioni memorizzate nei Data Base sono di proprietà dell’AOU di Modena che pertanto potrà accedere in qualunque momento agli archivi attraverso strumenti software già

acquisiti (basati su SQL standard) ovvero tramite DB Link; sarà cura del soggetto aggiudicatario attuare gli interventi necessari per garantire l'accesso ai DataBase mediante, ad es., creazione di viste, tabelle di appoggio, attribuzione di grant, etc.; l'accesso avverrà prevalentemente in lettura.

b. Postazioni di lavoro

La postazione di lavoro aziendale standard viene installata da immagine con sistema operativo Windows 10 64 bit.

Le caratteristiche di minima delle postazioni sono:

CPU: i3-i5 RAM: 4GB

HDD: 500GB SATA

Gli applicativi normalmente installati sono: Libre Office v.5 o superiore, Antivirus Kaspersky, Adobe Acrobat Reader, WinZip//Zip, Java versione 1.6 o superiore, browser Firefox/Chrome/IE11.

Si precisa che il parco delle postazioni di lavoro fisse e mobili è soggetto a continue evoluzioni e la scelta delle tipologie e dei modelli è vincolata, di prassi, alle convenzioni delle centrali di acquisto nazionali o regionali.

c. Specifiche Architetturali

L'Architettura proposta in particolare deve prevedere una completa autonomia operativa a livello delle diverse unità operative sia per quanto riguarda la parte HD, sia per quant o riguarda archivi, DB, etc; sia per quanto riguarda gli SW, licenze ed Applicativi.

In considerazione dell'obiettivo di una soluzione di Cartella Clinica esclusivamente elettronica (riferimento livello Himms EMRAM Stage 7 ) l'architettura proposta dovrà consentire e garantire adeguati livelli di sicurezza ed affidabilità per quanto riguarda accessibilità, riservatezza ed integrità dei dati.

Conseguentemente il sistema dovrà essere progettato per lavorare con soluzioni di business continuity e system redundancy di adeguato livello che comunque il progetto presentato dovrà preoccuparsi di definire, ancorchè l'hardware implicato non sia parte della fornitura da garantire.

Devono ad esempio essere definite le ridondanze infrastrutturali e di sistema necessarie per garantire:

- la continuità di alimentazione elettrica;

- disponibilità della rete dati;

- disponibilità dei dati (es: mediante copia periodica dei dati chiave su supporti di memoria di workstations - dotate di alimentazione elettrica da ups - di sola lettura e stampa - quando il sistema è non disponibile/ soluzioni active-active in grado di consentire failover immediati);

L'architettura dovrà assecondare l'organizzazione Aziendale e la distribuzione sul territorio dei punti in cui si svolge l'attività, garantendo una totale autonomia a livello della singola Unità Operativa, pertanto si individua una articolazione a livelli che comprenda:

1. Livello di Unità Operativa

La soluzione dovrà risultare a questo livello completamente autonoma ed indipendente. Le integrazioni da eseguire vanno dunque concepite con riferimento a questo contesto e livello così come applicativi, archivi.

2. Livello Aziendale

Questo livello deve garantire un livello di ridondanza rispetto a ciascuna Unità Operativa sia per i dati sia per gli applicativi, deve inoltre consentire una visione di governo a livello Aziendale delle risorse di dotazione dei posti letto di Terapia intensiva. Le soluzioni di Business Intelligence richieste devono essere disponibili ed applicabili anche a questo livello.

Appendice. 17. AUSL Romagna: caratteristiche specifiche

L’Azienda Unità Sanitaria Locale della Romagna è stata istituita con Legge regionale n. 22 del 21 novembre 2013, per fusione delle quattro Aziende Sanitarie Pubbliche di Cesena, Forlì, Ravenna e Rimini, il territorio della nuova Azienda coincide con quello dell'insieme delle province di Ravenna, Forlì-Cesena e Rimini, ovvero con la Romagna.

All'interno della nuova Azienda le aree di competenza delle Aziende originali sono definite Ambiti Territoriali: Ambito di Rimini, Cesena, Ravenna, Forlì.

Informazioni di tipo generale riguardanti l'Azienda USL Romagna possono essere reperite sul sito web istituzionale: xxxxx://xxx.xxxxxxxxxxx.xx/xx-xxxxxxx .

Il sistema informativo dell'Azienda USL Romagna non si può dire sia ancora omogeneo, ma risente in maniera importante delle realtà delle Aziende d'origine ed allo stesso modo anche gli applicativi possono pur per la stessa attività risultare diversi nei vari territori.

Nella considerazione che la soluzione richiesta per l'AUSL Romagna, oltre al centro Covid HUB Intensive Care di Rimini deve poter essere sviluppata anche per la realtà delle altre terapie intensive della Romagna, il progetto presentato deve opportunamente prendere in considerazione questo aspetto anche dal punto di vista delle integrazioni, dell’architettura server e di rete e dei vincoli esistenti. In questa ottica vengono fornite le specifiche relative nei successivi paragrafi.

a. Caratteristiche e vincoli di tipo generale

Il sistema offerto deve rispettare i seguenti vincoli di tipo generale:

 vincoli posti dalla rete informatica e dal sistema informativo aziendale esistenti. A tali sistemi dovrà interfacciarsi il sistema oggetto di fornitura secondo le specifiche del presente capitolato. Ove fossero necessari aggiornamenti della succitata rete informatica o del sistema informativo aziendale, essi dovranno essere preventivamente concordati con la Stazione Appaltante e saranno a carico della Ditta Aggiudicataria; l'attuale infrastruttura di rete si basa su collegamenti con banda di 1 Gbps in rete locale LAN e di 1 Gbps in rete geografica WAN.

 vincoli posti dalle dimensioni e dalle caratteristiche tecniche dei locali adibiti all’installazione della macchine Server e del sistema di archiviazione; ove fossero necessari aggiornamenti di tipo strutturale o impiantistico tali opere dovranno essere preventivamente concordate con la Stazione Appaltante e saranno a carico della Ditta Aggiudicataria. Il progetto deve essere impostato in modo tale che le specifiche richieste per la manutenzione delle attrezzature siano sempre rispettate, indipendentemente dalla qualità del contesto locale in

cui esse saranno installate. Non è ammesso, pertanto, che sia imputato all’Azienda USL della Romagna, in quanto eventualmente carente nelle proprie infrastrutture, il mancato rispetto delle specifiche sulle manutenzioni.

b. Infrastruttura Server e DB

Tutto l’hardware necessario, ad eccezione di quello indicato per il livello locale dell’architettura, e i relativi S.O., solo se Open Source (ad es. Linux CentOS), saranno messi a disposizione dalla AUSL della Romagna.

Eventuali sistemi proprietari non di tipo Open Source sono da intendere a carico della ditta Aggiudicataria.

Il sistema offerto deve poter lavorare sia su server fisici che su server virtuali. Ogni fornitore dovrà dettagliare le esigenze sia in termini di infrastruttura Hw che di Sistemi operativi necessari a garantire l’operatività del sistema.

Devono essere indicate le risorse impiegate dal sistema sia a livello di Application/web server che di Database server per ogni singola connessione dando la possibilità alla AUSL di poter definire le risorse opportune dell’infrastruttura.

La configurazione del networking, degli instradamenti e della gestione dei DNS sarà a carico AUSL della Romagna. Si richiede al fornitore di specificare l’ambiente e il protocollo utilizzato per la pubblicazione del sistema.

Sarà a carico della AUSL della Romagna l’installazione dei Sistemi Operativi; sarà a carico della Ditta aggiudicataria la messa a punto del sistema comprensivo di: fornitura, installazione, configurazione, assistenza e manutenzione di ogni componente: sarà fornito dall’ AUSL della Romagna un collegamento in VPN per l’accesso remoto.

Tutti i dati e le informazioni memorizzate nei Data Base sono di proprietà dell’Azienda USL della Romagna che pertanto potrà accedere in qualunque momento agli archivi attraverso strumenti software già acquisiti (basati su SQL standard) ovvero tramite DB Link; sarà cura del soggetto aggiudicatario attuare gli interventi necessari per garantire l'accesso ai DataBase mediante, ad es., creazione di viste, tabelle di appoggio, attribuzione di grant, etc.; l'accesso avverrà prevalentemente in lettura.

c. Postazioni di lavoro

La postazione di lavoro aziendale standard viene installata da immagine con sistema operativo Windows 10 64 bit.

Le caratteristiche di minima delle postazioni sono:

CPU: i3-i5 RAM: 4GB

HDD: 500GB SATA

Gli applicativi normalmente installati sono: Libre Office v.5 o superiore, Antivirus Kaspersky, Adobe Acrobat Reader, WinZip//Zip, Java versione 1.6 o superiore, browser Firefox/Chrome/IE11.

Si precisa che il parco delle postazioni di lavoro fisse e mobili è soggetto a continue evoluzioni e la scelta delle tipologie e dei modelli e vincolata, di prassi, alle convenzioni delle centrali di acquisto nazionali o regionali.

d. Specifiche Architetturali

La soluzione proposta deve riferirsi al livello Azienda ed alla organizzazione secondo le diverse unità operative presenti nell'Azienda.

Conseguentemente il sistema dovrà essere progettato per lavorare con soluzioni di business continuity e system redundancy di adeguato livello che comunque il progetto presentato dovrà preoccuparsi di definire, ancorchè l'hardware implicato non sia parte della fornitura da garantire. Devono ad esempio essere definite le ridondanze infrastrutturali e di sistema necessarie per garantire:

- la continuità di alimentazione elettrica;

- disponibilità della rete dati;

1. Livello di Unità Operativa

2. Livello Aziendale

Secondo questa esigenza e quanto espresso nei punti precedenti del presente capitolato, si chiede di prevedere un’architettura che contempli almeno:

‐ Livello locale che comporti l’installazione dell’hardware e del software necessario a garantire quanto richiesto al punto 1. Livello Unità Operativa; tali risorse, compreso l’hardware necessario (server), sono da considerarsi totalmente a carico del fornitore.

In previsione di possibili ampliamenti del sistema, pur dovendo mantenere le caratteristiche di affidabilità e continuità delle prestazioni, è facoltà del fornitore proporre l’installazione di hardware e software tale da garantire con la sola installazione presso l’Ospedale di riferimento per l’ambito, la copertura di tale livello anche per tutti i presidi ospedalieri afferenti allo stesso ambito; a titolo di esempio è possibile prevedere come Livello locale per le UU.OO. di Terapia Intensiva dei presidi di Rimini e Riccione, una sola installazione presso il presidio ospedaliero di Rimini. L’hardware fornito deve essere provvisto di bracci passacavi e collocabili in armadi rack standard 19”.

Ambito	Ospedale di riferimento per l’ambito	Ospedali/UU.OO. afferenti
Rimini	Rimini Ospedale "Infermi"	Rimini - HUB COVID Ospedale "Infermi"
		Rimini Ospedale "Infermi"- Terapia Intensiva
		Rimini Ospedale "Infermi" - Recovery Room
		Riccione Ospedale "Ceccarini" Terapia Intensiva
Ravenna	Ravenna Ospedale S. Xxxxx delle Croci	Ravenna Ospedale Terapia Intensiva
		Faenza Ospedale Terapia Intensiva
		Lugo Ospedale Terapia Intensiva
Forlì	Forlì Ospedale Morgagni Xxxxxxxxxx	Forlì Ospedale Terapia Intensiva
Cesena	Cesena Ospedale Bufalini	Cesena Ospedale Terapia Intensiva

‐ Livello centrale che comporti l’installazione dell’hardware e del software necessario a garantire quanto richiesto a livello aziendale. Si prevede che l’hardware necessario sarà messo a disposizione presso il Data Center Regionale Lepida;

‐ Disaster recovery: si prevede che l’hardware necessario sarà messo a disposizione presso un Data Center Regionale Lepida in un sito alternativo a quello dedicato per il livello centrale.

Document Metadata

Table of Contents

Cartella Clinica Informatizzata di Rianimazione/Terapia Intensiva - Requisiti di riferimento

Document Metadata