Specifiche Tecniche per la realizzazione di un Registro Centrale Esiti Dispositivi Impiantabili

INDICE

1.1 Premessa

Oggetto della fornitura è la realizzazione di un sistema informativo per la gestione e misurazione degli esiti dei pazienti che usufruiscono di dispositivi medici impiantabili. Il contratto prevede l’acquisto delle licenze d’uso e dei servizi di assistenza e manutenzione, questi ultimi per la durata di 12 mesi a decorrere dalla data di verifica di regolare esecuzione, con esito positivo, a cura del RES/DEC.

1.2 Definizioni

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

Termine	Descrizione del Termine
Aggiudicatario, Xxxxx Xxxxxxxxxxxxxx, Xxxxx appaltatrice, Ditta contraente, Contraente, Fornitore, Assuntore	Il fornitore aggiudicatario, che ha sottoscritto il contratto obbligandosi a quanto nello stesso previsto nei confronti dell’Azienda. Esso può identificarsi anche con un raggruppamento temporaneo di imprese o con il suo capofila.
Azienda Sanitaria, Azienda, Committente	Il complesso delle aziende sanitarie e gli enti del Servizio Sanitario della Regione Toscana che usufruiscono dei servizi oggetto dell’appalto.
Sistemi Serventi o Server	sottosistemi più o meno complessi, in grado di fornire servizi di tipo infrastrutturale di base o applicativi. Essi sono generalmente costituiti da hardware, software di base (sistemi operativi, driver di periferiche) e sistemi di memorizzazione interni o esterni, esclusivi o condivisi.
Unità Operativa (UO)	Struttura organizzativa professionale e/o funzionale dell’Azienda titolare di proprio budget assegnato

Terminologia, abbreviazioni

Glossario dei termini e delle abbreviazioni

Acronimo	Definizione
ESTAR	Ente di supporto tecnico-amministrativo regionale
XX.XX.	Aziende Sanitarie. Si Tratta di USL Toscana Nord Ovest, USL Toscana Centro, USL Toscana Sud Est
AA.OO.UU.	Aziende Ospedaliero Universitarie. Si Xxxxxx di AOU Pisana, AOU Careggi, AOU Meyer, AOU Senese
ISPRO	Istituto per lo Studio, la Prevenzione e la Rete Oncologica
FTGM	Fondazione Toscana Xxxxxxxx Xxxxxxxxxx
CART	Cooperazione Applicativa Regione Toscana
SLA	Service Level Agreement
RUP	Responsabile unico del procedimento (art. 31 D.Lgs 50/2016) nella fase che si chiude con la stipula del contratto
RES	Responsabile del procedimento per la fase di esecuzione del contratto (art. 2 comma 1.b DGRT 16/2014)
DEC	Direttore dell'Esecuzione del Contratto (art. 101 D.Lgs 50/2016)
ANAC	Autorità nazionale anticorruzione
RT	Regione Toscana
SSR	Servizio Sanitario Regionale
SSRT	Servizio Sanitario Regionale Toscano
SDA	Sistemi Dinamici di Acquisizione
SW	Software
RDA	Richiesta di Acquisto
DURC	Documento Unico di Regolarità Contributiva
PDI	Piano dettagliato di intervento

Tabella 2 - Glossario

1.3 Riferimenti Normativi

● Delibera della Giunta Regionale Toscana n. 638 del 20 luglio 2009

● European Medical Device Regulation (MDR), (EU) 2017|745

2. Oggetto della fornitura ed esclusioni

2.1 Contesto

Estar in qualità di centrale di committenza gestisce procedure di affidamento di vario genere finalizzate all’acquisto di Dispositivi Medici impiantabili. Tali dispositivi vengono poi utilizzati dal personale delle Aziende Sanitarie durante interventi chirurgici ed impiantati in pazienti. Per tali prodotti può rendersi necessaria una valutazione dell’esito dell’utilizzo dello stesso, valutazione che viene effettuata generalmente da personale sanitario, che deve essere raccolta a livello centrale e che costituisce parte integrante della fase di esecuzione contrattuale per i contratti con fornitori di Dispositivi Medici.

La definizione del processo di misura degli esiti da attivare per ogni sede di gara deve essere indicato da parte del collegio tecnico, supportato eventualmente da ARS secondo uno schema predefinito.

La registrazione dell’informazione relativa al legame PRODOTTO-PAZIENTE è effettuata sui software di Gestione del percorso chirurgico introdotti a seguito della Delibera della Giunta Regionale Toscana n. 638 del 20 luglio 2009.

Ciascun software che gestisce il percorso chirurgico nelle XX.XX. Toscane invierà le informazioni relative a ciascun intervento effettuato al Registro Centrale Esiti, oggetto della presente fornitura, che dovrà ricevere e memorizzare le informazioni che costituiranno la base informativa minima per la generazione delle Indagini sugli Esiti dei dispositivi Impiantabili.

È importante considerare l’evoluzione normativa relativa al European Medical Device Regulation (MDR), (EU) 2017|745 entrato in applicazione il 26/05/2021 che impone ai fornitori di Dispositivi Medici Impiantabili, oltre a varie disposizioni su formati di etichette dei prodotti, anche l’adozione di un identificativo unico per i dispositivi medici (UDI = Unique Device Identification). L’USO dell’UDI nel costituire il legame Prodotto-Paziente è considerato strategico.

2.2 Oggetto della fornitura

2.3 Obiettivi specifici della fornitura

Il registro centrale dovrà:

- Ricevere i dati relativi agli interventi e ai dispositivi impiantati attraverso l’esposizione di api REST specifiche;

- consentire la creazione e la gestione di specifici questionari associati ai prodotti impiantati sui pazienti;

- gestire la compilazione dei questionari da parte degli utenti del sistema sanitario;

- consentire la gestione delle informazioni e la creazione di report relativi alle informazioni contenute nel registro stesso;

3. Processi funzionali ed eventuali sistemi informatici correlati

3.1 Modello Applicativo

Il sistema registro oggetto della fornitura dovrà prevedere:

- un Api Gateway che consentirà di implementare servizi REST per le integrazioni con i sistemi terzi di gestione del percorso chirurgico, di gestire la mutua autenticazione con certificati client, di esporre api per le applicazioni di gestione del contenuto del registro;

- un database per la memorizzazione delle informazioni;

- una web app costituita da:

o un contenitore logico per gestire il frontend e gli elementi statici;

o una serie di funzioni applicative per la creazione di form, processare i dati, scrivere e leggere contenuto informativo sul database e tutte le altre operazioni necessarie;

3.2 Descrizione dei Processi

Il diagramma seguente mostra l’architettura generale di processo.

3.3 Integrazioni con sistemi interni ed esterni

Oltre ai servizi esposti verso l’esterno per la ricezione delle informazioni sugli interventi chirurgici il sistema dovrà interagire con il sistema ARPA di Regione Toscana per l’autenticazione degli operatori attraverso tutti i canali esposti.

Inoltre, per consentire una gestione corretta dei dati personali, il sistema in oggetto non conterrà in modo permanente i dati anagrafici dei pazienti ma solo le chiavi di anonimizzazione. Successivamente e solo per le utenze sanitarie in fase di utilizzo del software potranno essere richiamate specifiche funzioni di de-anonimizzazione per consentire la visualizzazione in chiaro di nomi e cognomi dei pazienti o degli operatori di sala.

Sistema Informatico	Note	RUOLO
Sw di registro operatorio, con api REST esposte	Endpoint con mutua autenticazione	Ricezione eventi sugli interventi
CAST/CART	RFC 85/249	Servizio SOAP di recupero sincrono informazioni anagrafiche su Pazienti- Operatori di Sala
Arpa RT		Autenticazione

4. Requisiti Funzionali e Tecnologici del sistema

La fornitura deve includere le funzionalità che seguono.

4.1 Requisiti Funzionali

Si riportano nel seguito le caratteristiche generali che il sistema deve avere oltre ai requisiti espressi nei capitoli precedenti. Tali caratteristiche hanno carattere obbligatorio eccetto quelle espressamente indicate come migliorative:

ID	Requisito	Obbligatorio/ Migliorativo
F0	Il sw dovrà avere una sezione amministrativa di gestione anagrafiche generali dove gli utenti potranno effettuare, su front- end full web, operazioni CRUD, rispettando i vincoli di integrità referenziale, su: - Le Unità Operative (UO) che raccolga il riferimento di Azienda \| Presidio \| Disciplina \| NomeUO \| E-mail di riferimento - L’anagrafica degli utenti, dei ruoli associati e l’appartenenza alle UO secondo il paradigma Role Based Access Control (alias RBAC) - Il sistema dovrà ricevere, attraverso i servizi REST, le anagrafiche del personale sanitario provenienti dai sistemi integrati; - Il catalogo dei Dispositivi Impiantabili; - Altri eventuali cataloghi ritenuti utili dal produttore o dal CT per la corretta gestione del sistema	Obbligatorio
F1	Il sistema dovrà gestire vari contratti. Per ciascun contratto sarà possibile avere uno o più prodotti forniti. Il sistema dovrà consentire la modifica dell’associazione tra i contratti e i prodotti/dispositivi associati a ciascun contratto.	Obbligatorio
F2	Il sistema deve consentire la creazione, per ciascun contratto, di una indagine strutturata in uno o più Questionari (Anamnestici, Operatori o follow up) ciascuno contenente una serie di Domande/Risposte. Le domande e risposte potranno essere visivamente strutturate in sezioni. Per ciascuna indagine il prodotto è valutato nello stesso modo (con lo stesso set di questionari: 1 mese, 1 anno, 5 anni...)	Obbligatorio

F2.1	In alcuni casi (reintervento) dovrà essere possibile creare un legame tra una scheda intervento “padre” ed una “figlia” inserito sulla base di un giudizio di un operatore.	Obbligatorio
F2.2	Le Domande del Questionario dovranno essere creabili in libero formato testuale direttamente dagli utenti abilitati, utilizzando un modulo messo a disposizione dal software con interfacce web.	Obbligatorio
F2.3	Le Risposte del Questionario potranno essere della seguente tipologia: ● Risposta vincolata ad uno degli elementi proposti fino a un massimo di 20 valori diversi (radiobutton o dropdownlist) ● Risposta vincolata a più elementi tra quelli proposti fino a un massimo di 20 valori diversi (check box multipla) ● Risposta numerica vincolata ad un determinato range (es. da 0 a 10) ● Risposta contenente una data ● Risposta contenente un testo libero	Obbligatorio
F3	Per ciascun prodotto impiantato su un paziente (occorrenza di legame paziente-dispositivoImpiantato), il Medico/responsabile UO compila le risposte ai Questionari. In alternativa il Medico può vedere l’elenco degli interventi potenzialmente oggetto di indagine navigando per Prodotto Impiantato, per data intervento, per ICD9CM dell’intervento.	Obbligatorio
F4	Il sistema dovrà rendere disponibile una interfaccia che consenta di ricercare e navigare all’interno delle informazioni di interventi e indagini esclusivamente a livello di U.O.	Obbligatorio
F5	Il sistema dovrà essere dotato di una dashboard dedicata al personale ABS in grado di restituire, aggregata o filtrata almeno per Azienda, periodo temporale, tipologia di dispositivo, contratto, UO, dati di tipo statistico utili all'analisi dell'outcome in formato strutturato stampabile ed esportabile.	Obbligatorio
F6	I valori di Azienda \| Presidio \| Disciplina, obbligatori per la trasmissione dell’intervento, dovranno essere inseriti nel DB al momento della ricezione di una risorsa intervento (surgery) se non già presenti.	Obbligatorio
F7	L’utente con ruolo amministratore di sistema per ciascuna AA. SS. potrà configurare utenze e ruoli per la propria azienda, completare con i dati mancanti per poter utilizzare la UO come destinataria di una review ed effettuare altre eventuali azioni amministrative su oggetti non trasversali alle aziende.	Obbligatorio


F8	In alternativa alle credenziali come metodo di autenticazione si potrà utilizzare un token legato alla e-mail di invio ai pazienti- operatori dell’invito alla compilazione che si esaurisce con la conferma della compilazione del Questionario oppure trascorso un determinato intervallo temporale. In questo caso, chi riceve l’e- mail di invito cliccando sul link potrà attivare lo specifico questionario e fornire le risposte. In caso di risposta tramite link l’utente associato è quello che detiene l’indirizzo email associato al token.	Migliorativo
F9	Il sistema dovrà mostrare per ciascuna UO, i Questionari già compilati e quelli da compilare, con una visione d’insieme che consenta di capire le scadenze di compilazione previste nel periodo temporale di riferimento.	Obbligatorio
F10	Il sistema potrà gestire tramite invio di email alcune messaggi di reminder per ricordare le scadenza di compilazioni di questionari secondo una configurazione prestabilita.	Migliorativo
F11	Il sistema potrà fornire un template in formato standard (es. Excel) per la creazione del singolo questionario e consentirne l’upload verso il sistema, la validazione e l’associazione ad uno specifico contratto.	Migliorativo
F12	Il sistema dovrà consentire operazioni CRUD sugli interventi con associazione del legame paziente-dispositivo impiantato e del contenuto informativo della risorsa surgery, registrando data, ora e utente che ha effettuato la modifica in apposito logfile.	Obbligatorio

Legenda:

Obbligatorio: requisito indispensabile pena l’esclusione

Migliorativo: requisito non indispensabile sarà valutato come proposta migliorativa

4.2 Requisiti interfacce

Nel documento allegato RCE_Api_Definition.yaml sono definite le specifiche in formato OpenApi che costituiscono una base per una migliore comprensione del dominio dati e delle interazioni necessarie. L’operatore economico può estendere e modificare (in modo migliorativo per la Stazione Appaltante), in fase di proposta tecnica, il contenuto del file. Ciò non costituisce tuttavia un elemento preferenziale dell’offerta.

4.3 Requisiti tecnologici

Nel rispetto delle disposizioni espresse dal Dipartimento Tecnologie Informatiche di Estar in materia di caratteristiche tecnologiche dei software di nuova acquisizione, il sistema dovrà rispettare la tecnologia web “zero footprint” per essere fruibile via browser da tutte

le postazioni di lavoro che saranno individuate sul territorio regionale e dovrà essere installato sul data center regionale della Sanità Toscana.

4.4. Ambienti operativi

L’infrastruttura tecnologica messa a disposizione dall’operatore economico dovrà prevedere di operare almeno nei seguenti distinti ambienti:

Ambiente di PRODUZIONE;

Ambiente di STAGING (pre-produzione); Ambiente di TEST;

L’operatore economico dovrà farsi carico senza oneri aggiuntivi per l’Ente di:

- Fornire accesso ai sistemi di Test, Staging e Produzione;

- Aggiornare (all’ultima versione stabile rilasciata e delle patch di aggiornamento) gli ambienti sopra elencati, per tutti i software installati, per l’intera durata contrattuale;

- Acquistare le eventuali licenze di aggiornamento, degli ambienti sopra elencati, per tutti i software installati, per l’intera durata contrattuale.

4.5 Dimensionamento

Di seguito si riportano elementi utili al dimensionamento dell’infrastruttura. Numero di interventi annui: 300.000

Numero di Operatori backend: 10 Numero di UO coinvolte: 100

Numero di utenti complessivi: 1000, contemporanei 20

4.6 Recupero di dati storici

Non è necessario alcun recupero dei dati storici relativo alle indagini passate.

4.7. Documentazione del sistema

L’operatore economico è tenuto, per l’intera durata del contratto, a produrre e a mantenere aggiornata la seguente documentazione:

- Manuale utente;

- Elenco e documentazione tecnica delle interfacce e protocolli utilizzati;

- Documentazione e struttura della base dati installata ed in esercizio;

- Documentazione degli utenti e profili impiegati e loro correlazione degli accessi alle risorse ed ai dati del sistema.

L’operatore economico dovrà mettere a disposizione, per l’intera durata del contratto, una video-guida sull’utilizzo del software strutturata su più sezioni in formato .mp4, con video ciascuno di peso inferiore a 50 Mb e durata non superiore ai 5 minuti. Tale video guida costituisce formazione per l’utenza.

4.8 Disponibilità del codice sorgente

Al termine del periodo contrattuale, ai sensi dell’art.69 comma 2 del CAD e salvo che ciò non risulti eccessivamente oneroso per comprovate ragioni di carattere tecnico-economico, l’amministrazione acquisirà la proprietà del software o di singoli moduli appositamente sviluppati per essa, alle condizioni che saranno proposte dall’aggiudicatario, rendendo disponibile il relativo codice sorgente sulla piattaforma Developers Italia, in uso gratuito, ad altre pubbliche amministrazioni o a soggetti giuridici che intendono adattarli alle proprie esigenze. In ordine al presente argomento si rinvia agli articoli 68 e 69 del CAD ed alle Linee Guida Agid per “Acquisizione e Riuso di software per le Pubbliche Amministrazioni” pubblicate su GU Serie G. n.119 del 23.05.2019

4.9 Fase di Implementazione - definizione dei vincoli e penali

Nella predisposizione del Gantt relativo alle attività oggetto della fornitura il concorrente, dovrà rispettare i seguenti vincoli:

- V1 Collaudo della nuova piattaforma e delle sue integrazioni entro 6 mesi dall’ordine

- priorità ALTA

- V2 Verifiche di conformità non esitate positivamente e che non impediscono l’avvio in uso del sistema, risolte entro 30 gg dalla formalizzazione del DEC - priorità MEDIA

- V3 Predisposizione della documentazione, help on line, ecc. entro i 20 gg precedenti la formazione di cui al precedente punto 4.7 e l’avvio - priorità MEDIA

- V4 Aggiornamento semestrale della documentazione e dell’help on line - priorità BASSA

Nota in merito ai vincoli: Le attività che normano la Verifica e Collaudo del Software, con i rispettivi requisiti, sono descritte nella “PA47-2018 Rev01 Verifiche di Conformità”, cui il RES e il DEC faranno riferimento per l’eventuale valutazione del rispetto dei vincoli sopra riportati nonché dell'applicazione delle relative penali. È facoltà del Concorrente proporre Gantt che prevedano la riduzione dei vincoli sopra indicati. Ciò non costituisce tuttavia un elemento preferenziale dell’offerta.

In caso di non rispetto delle condizioni sui vincoli sopra riportati, saranno applicate le seguenti penali:

- V1: € 2.000,00 al mese per ogni mese di ritardo;

- V2 e V3: € 1.000,00 al mese per ogni mese di ritardo;

- V4: € 500,00 per ogni semestre di non rispetto del vincolo

5. Supporto e Manutenzione post-verifica di regolare esecuzione

5.1 Fase di Supporto e Manutenzione (post-verifica regolare esecuzione)

Si precisa che per questo software si intendono coperte le seguenti fasce:

- supporto esteso lunedì – venerdì dalle ore 8 alle ore 18

Per l’erogazione dei servizi di assistenza e manutenzione del sistema informatico oggetto del capitolato, che dovranno essere garantiti nel rispetto della copertura standard come definita al paragrafo E.1 dell’Allegato 1 “Linee Guida per l’assistenza e la manutenzione dei software”, valgono gli SLA che sono illustrati e normati nel documento stesso, che è parte integrante del presente capitolato. Si precisa che tali servizi possono essere erogati anche in collegamento remoto da parte del fornitore la cui richiesta andrà inoltrata al RES/DEC di riferimento.

Oltre al servizio di help desk e manutenzione ordinaria, normativa e correttiva per 12 mesi, il contratto prevede la realizzazione di manutenzione evolutiva sulla piattaforma in oggetto

In merito ad essa si descrive la modalità di erogazione:

● Manutenzione evolutiva standard da erogarsi a consumo mediante moduli MEV come da procedura PA 45 2018 REV02 SOFTWARE CHANGE REQUEST (ALLEGATO 3) ed attingendo ad una previsione di giornate annuali inserita nella scheda offerta economica; si precisa che non vi è alcuna garanzia di acquisizione di queste evoluzioni;

● Rientrano in questa tipologia le giornate previste per: servizio DBA a consumo, sviluppo software (gg in house), consulenza ed evoluzioni (gg on site).

6. Allegati

6.1 Sono di seguito riportati gli allegati standard contrattuali per Assistenza e Manutenzione Software e le procedure standard ESTAR a supporto del ciclo di vita del software:

All. 1 Linee Guida per l’assistenza e la manutenzione dei software

Delinea le caratteristiche del servizio di assistenza e manutenzione che l’Aggiudicatario dovrà garantire per tutta la durata dell’appalto. Illustra le peculiarità di un servizio di assistenza e manutenzione per un software gestionale, sia in termini di manutenzione ordinaria, sia in termini di manutenzione correttiva ed evolutiva. Esplicita i livelli di servizio attesi e la modalità di misurazione dei Service Level Agreement (SLA). Definisce le penali che il Cliente può applicare in caso di non rispetto dei livelli di servizio contrattualizzati. Specifica le modalità di interazione nel caso di disservizi che abbiano un impatto rilevante ai fini del rischio clinico.

All.2 Procedura Lifecycle Management

La procedura definisce il ciclo di vita del software

All.3 Procedura Change Request

La procedura definisce le modalità di gestione delle CHANGE REQUEST sui software in uso in ESTAR e nelle XX.XX., evidenziando il processo da attuare per la gestione delle attività che rientrano nell'ambito dei servizi di Manutenzione Evolutiva (MEV) sul software aggiudicatario per tutta la durata dell’appalto. Rientrano in questa procedura anche le

attività eseguite dai fornitori che, seppur non sempre inquadrabili nella tipologia ‘CHANGE REQUEST’, hanno un impatto sulla gestione organizzativa delle manutenzioni evolutive (es. attività sistemistiche, estrazioni ad hoc, migrazioni di infrastrutture e DB, formazione, modifiche ai flussi DOC e RFC, ecc.), pertanto la presente procedura sarà applicata ad ogni ambito di utilizzo delle giornate on site e in house comprese nella fornitura

All.4 Modulo per MEV

Modulo allegato da utilizzare per la definizione e quotazione delle attività di manutenzione evolutive (Change Request)

All.5 Procedura Collaudi Forniture Software e relativi allegati

La procedura definisce le modalità con cui verranno eseguite le fasi di collaudo di una fornitura di software, definendo sia le fasi di collaudo relative alla realizzazione iniziale del progetto, sia quelle delle successive fasi di manutenzione evolutiva.

All.6 Compliance Sicurezza e Privacy

Il documento illustra le peculiarità dei progetti tecnologici in ambito sanitario, in merito alle problematiche di privacy imposte dalle normative vigenti. In particolare, per i software sanitari, stabilisce buone pratiche evidenziando la necessità di evoluzione verso sistemi nativamente sviluppati secondo i principi di ‘privacy by design’ e ‘privacy by default’. Attenzione: è richiesta la compilazione della “Scheda Check Compliance e privacy applicativi software” ad ogni concorrente, come indicato al punto B.4 della Lettera di invito.

All 7 PA 90/2020 gestione accessi da remoto e relativi allegati

La procedura definisce le modalità con cui saranno gestite le richieste di collegamento da remoto alle reti che ospitano le risorse ICT del SSR amministrate da ESTAR

All. 8 RCE_Api_Definition.yaml

Nel documento sono definite le specifiche in formato OpenApi che costituiscono una base per una migliore comprensione del dominio dati e delle interazioni necessarie.

6.2 Documenti di definizione ambiente tecnologico

Si ritengono parte integrante del presente capitolato i seguenti documenti di definizione dell’ambiente tecnologico di riferimento pubblicati alla pagina Web di ESTAR xxxx://xxxxxxx.xxxxx.xxxxxxx.xx/xxxxx.xxx/xxxxxxxxxxxxxx-xxx/0-xxxxxxxxxxxx-xxx-xxxxxxxx;

si deve far riferimento all’ultima release vigente alla data di pubblicazione del presente bando:

● Regole di utilizzo della rete InterSST

● Linee Guida Tecnologiche

● CAST Descrizione del Modello

● CAST Specifiche Funzionali Interoperabilità ESB

● CAST Registry OID

● CAST Specifica Interfaccia Applicativa EventHandler

Document Metadata

Table of Contents

Specifiche Tecniche per la realizzazione di un Registro Centrale Esiti Dispositivi Impiantabili

Document Metadata