Software Cardiology Information System
Software Cardiology Information System
Capitolato Tecnico di Gara
INDICE
1. Introduzione 3
2. Oggetto della fornitura ed esclusioni 5
3. Contesto 11
4. Processi funzionali ed eventuali sistemi informatici correlati 14
5. Requisiti Funzionali e Tecnologici del sistema 23
6. Offerta Tecnica - Predisposizione e Vincoli 31
7. Allegati di Gara 34
Appendice A – Penali 36
1.1 Premessa
L’oggetto della fornitura nasce dall’esigenza delle XX.XX. di Area Vasta Sud-Est nello specifico per l’Azienda Ospedaliera Universitaria Senese e l’Azienda Sanitaria Locale Territoriale Sud Est (potenzialmente riscontrabile presso le altre Aziende del S.S.R. Toscano) per l'informatizzazione del Dipartimento Cardio- Toraco-Vascolare tramite l'implementazione di un'unica piattaforma Cardiology Information System (di seguito CIS) dotata delle integrazioni necessarie con il Sistema Informativo Ospedaliero (SIO), con particolare riferimento all'ambiente RIS-PACS, alla cartella clinica elettronica ed a tutti gli apparati biomedicali opportunamente individuati nel Dipartimento (ecocardiografi, angiografi) oltre che agli applicativi aziendali in uso.
La presente gara si riferisce ad una acquisizione in locazione operativa di tutte le componenti software.
1.2 Obiettivi
Obiettivo fondamentale è quello di attivare un vero e proprio CIS, integrato con il PACS e con tutti gli altri sistemi aziendali che garantiscano l’implementazione di un workflow strutturato che assicuri la massima riduzione del rischio clinico e, al contempo, agevoli le attività dei professionisti coinvolti.
1.3 Definizioni
Nel testo che segue, oltre che alle definizioni contenute nelle norme UNI 11063 (Tutte le definizioni delle norme di riferimento per la manutenzione), viene fatto riferimento alle seguenti denominazioni e definizioni:
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 del contratto. |
Ente Appaltante, Stazione Appaltante | Ente che assegna la convenzione. |
Ditta concorrente, Ditta offerente | Impresa singola, raggruppamento temporaneo di imprese costituito o costituendo, consorzio o altro soggetto partecipante alla gara. Essa può identificarsi anche con il capofila di un raggruppamento temporaneo di imprese |
Help Desk | Struttura che ha il compito di dare il supporto di primo livello a fronte di una richiesta di assistenza; qualora non sia possibile trovare una soluzione al problema via assistenza di primo livello, l’Help Desk ha il compito scalare il problema sia verso il supporto tecnico avanzato o verso un eventuale fornitore terzo che eroga il supporto tecnico specifico |
Service Level Agreement (SLA) | in italiano: Accordo sul livello del servizio, in sigla SLA, è uno strumento contrattuale attraverso il quale si definiscono le metriche di servizio che devono essere rispettate da un fornitore di servizi. |
Sistemi Serventi o Server | sottosistemi più o meno complessi, in grado di fornire servizi di tipo infrastrutturale di base o applicativi. Essi sono generalmente costituiti da hardware, software di base (sistemi operativi, driver di periferiche) e sistemi di memorizzazione interni o esterni, esclusivi o condivisi. |
Unità Operativa (UO) | Struttura organizzativa professionale e/o funzionale dell’Azienda titolare di proprio budget assegnato |
1.4 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 |
ASL TSE | Azienda Sanitaria Locale Territoriale Sud Est |
AOUS | Azienda Ospedaliera Universitaria 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 di Convenzione |
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 |
GDPR | General Data Protection Regulation, il Regolamento Ue 2016/679 relativo alla protezione delle persone fisiche con riguardo al trattamento e alla libera circolazione dei dati personali |
DURC | Documento Unico di Regolarità Contributiva |
PDI | Piano dettagliato di intervento |
CIS | Cardiology Informatio System |
SIO | Sistema Informativo Ospedaliero |
RIS | Radiology Information System |
PACS | Picture archiving and communication system |
IDM | Identity Management System |
ADT | Software per la gestione di ricoveri Ammissioni Dimissioni Trasferimenti |
CCE | Cartella Clinica Elettronica |
GR | Grosseto Ospedale della Misericordia |
AR | Arezzo Ospedale San Donato |
Tabella 2 - Glossario
1.5 Standard di riferimento e Vincoli Normativi
La fornitura, che dovrà essere adeguata dal punto di vista funzionale e di aderenza alle prescrizioni normative ad un impiego in ambiente sanitario, dovrà altresì garantire aderenza a standard internazionali ed essere dotato di funzionalità di integrazione in rete con adeguato controllo degli accessi, tracciabilità degli interventi e gestione avanzata dei referti con disponibilità anche di interfaccia ad alto livello (XML) per agevolare future integrazioni con altre risorse di un Sistema Informativo Ospedaliero.
Il prodotto dovrà essere dotato delle funzionalità necessarie a consentire il trattamento dei dati nel rispetto del Regolamento UE 679/2016 relativo alla disciplina sulla protezione dei dati personali (GDPR) .
Il sistema deve essere certificato come dispositivo medico, preferibilmente in classe IIa.
2. Oggetto della fornitura ed esclusioni
2.1 Oggetto della fornitura
Il presente Capitolato disciplina la fornitura, comprensiva dell’installazione, formazione, avviamento e manutenzione di un sistema CIS occorrente al Dipartimento Cardio-Toraco-Vascolare di AOUS e al Dipartimento Cardio-Neuro-Pneumo-Vascolare di USL TSE.
Il sistema informatico dovrà essere in grado di acquisire, visualizzare, confrontare, refertare, archiviare, distribuire le immagini, i video, i referti e i dati identificativi del paziente.
Le informazioni utilizzate nella pratica clinica per la diagnosi ed il trattamento dei pazienti affetti da malattie cardiovascolari sono di vario tipo e comprendono semplici annotazioni, derivanti dalla raccolta della storia clinica del paziente e dall’esame obiettivo, segnali, nel caso dell’elettrocardiogramma, immagini e filmati, derivanti da esami tipo ecocardiografia, angiografia, tomografia, scintigrafia, risonanza magnetica oltre ai referti degli esami effettuati. Questa mole di dati viene gestita attualmente da sistemi informatici dedicati ad ogni singola disciplina: una tale frammentazione delle informazioni inevitabilmente determina un considerevole dispendio di tempo e risorse ogni qual volta si verifica la necessità di estrapolare, analizzare, confrontare e condividere le informazioni di un paziente.
L’esigenza dei suddetti Dipartimenti delle XX.XX. dell’Area Vasta Sud-Est è quindi quella di disporre di un sistema informatico in grado di archiviare le informazioni provenienti dalle diverse aree diagnostiche e interventistiche di pertinenza cardiovascolare, di consentirne la revisione, l’analisi e la condivisione tra i vari presidi ospedalieri dell’Area Vasta.
Il sistema Informatico dovrà essere composto dai seguenti elementi:
- Sistema di gestione delle immagini e dei video integrato con il PACS aziendale, inteso come componente software, in grado di trasferire le immagini prodotte dalle strumentazioni a cui fanno riferimento adeguati sistemi di visualizzazione e stazioni di lavoro per la gestione, l’elaborazione e la trasmissione digitale delle immagini cardiologiche;
- Sistema gestionale per il Servizio di Cardiologia, inteso come componente software, perfettamente integrato col sistema descritto al punto precedente e al Software di Cartella Clinica in uso presso le XX.XX. nonché all’anagrafe centrale, finalizzato a supportare i processi ed il flusso di lavoro (prenotazione, accettazione, esecuzione, refertazione, ecc.) delle U.O. facenti parte dei dipartimenti specificati.
Nel dettaglio si richiede, che il sistema CIS preveda quanto segue:
- Applicativi e di post-processing per Workstations di refertazione con capacità di visualizzazione diagnostica delle bioimmagini, secondo architettura Web. Di seguito sono riportate le Workstations messe a disposizione dall'amministrazione nel seguente dettaglio esemplificativo, fermo restando che il numero effettivo sarà dimensionato in base alle abilitazioni connesse ad ogni licenza:
o N. 3 GR + 3 AR + 4 AOUS Workstations refertazione Ecocardiografie
o N. 3 GR + 3 AR + 3 AOUS Workstations di refertazione Emodinamica;
- Visualizzazione dei referti, delle immagini e dei video tramite applicativo web, oltre all’integrazione con Repository e Registry aziendali;
- Gestione automatica del magazzino dell’emodinamica con immediata evidenza del materiale a disposizione tramite integrazione con il magazzino aziendale (opzionale vedi paragrafo 4.4.15):
• Scorte di materiale acquistato
• Scorte del materiale in conto visione
• Scadenza del materiale acquistato (per utilizzare prima quello con scadenza più vicina)
• Scadenza del materiale in conto deposito (per consegnarlo e chiedere che venga sostituito prima che scada)
• Storicizzazione dei costi del materiale (per valutare l’andamento dei prezzi)
• Rintracciabilità dei lotti (per recuperare facilmente eventuali lotti difettosi)
• Tracciabilità del materiale: magazzino - paziente e paziente - vaso trattato (es. utile in caso di follow up specifici cui sottoporre il paziente) ;
- Possibilità di discussione di specifici casi tra i professionisti con modalità di teleconsulto o heart-team con produzione di referto condiviso e firmato dai membri del team dislocati anche in sedi diverse;
- Collegamento di tutte le apparecchiature di indagine clinica attualmente in uso presso le U.O. facenti parte dei dipartimenti specificati in modalità DICOM per la gestione delle liste di lavoro e ricevere le immagini e le misure (si rimanda agli elenchi allegati per il dettaglio dei macchinari descritti nel capitolo 3 in “La strumentazione clinica di base”). Si precisa che gli eventuali costi di adeguamento DICOM delle modalità diagnostiche (licenze software, componenti hardware e servizi) saranno a carico dell’Ente Appaltante;
- Gli applicativi Software forniti devono essere rispondenti alla Direttiva Comunitaria 93/42/CEE e successive versioni per dispositivi medici e possedere la relativa marcatura. Per il sistema offerto dovrà essere allegata Copia delle Certificazione CE relativa ai DM (Medical Device Directive) secondo la direttiva Europea 93/42/CEE nonché Declaration Of Conformity del produttore;
- Installazione, avviamento a regola d’arte e messa in opera dell’intero sistema e degli archivi nei locali e sui dispositivi hardware messi a disposizione dall’Azienda;
- Servizio di formazione ed addestramento degli utenti del sistema fornito sia all’avvio sia in concomitanza di importanti upgrade;
- Personalizzazione del software e la parametrizzazione/configurazione dei sistemi forniti, secondo le esigenze del personale clinico e amministrativo;
- Recupero completo del data base storico laddove esistente e secondo le specifiche / vincoli descritti nell’apposito paragrafo;
- Realizzazione e trasmissione di manuali (in formato elettronico) tecnico operativi di gestione e di amministrazione del sistema scritti in lingua italiana;
- Costante periodico aggiornamento di tutti i sistemi forniti all’ultima release disponibile per tutta la durata del contratto;
- Costante adeguamento del software fornito rispetto a quanto previsto dall’evoluzione della normativa regionale e nazionale senza oneri aggiuntivi (vedi Manutenzione Normativa pag.3-4 Allegato 1 Linee Guida Assistenza e Manutenzione Software v1.40);
- Servizio di manutenzione H24 full risk (nessun onere escluso), per l’intera durata contrattuale, preventiva e correttiva sul sistema fornito da erogare nei modi e tempi dettagliati come in seguito meglio descritto. Questo servizio deve essere offerto con quotazione economica separata. Il contratto di manutenzione deve comprendere anche i servizi di assistenza e manutenzione sistemistica per tutte le componenti del software di base (s.o, dbms, etc);
- In particolare devono essere descritte e presidiate con particolare cura le procedure di:
• sicurezza;
• riattivazione del sistema in seguito a incidente con indisponibilità dello stesso.
2.2 Obiettivi specifici della fornitura
Il progetto e la relativa realizzazione devono prevedere il raggiungimento degli obiettivi prefissati dalle XX.XX. e XX.XX. e, pertanto, permettere l’analisi e la condivisione delle informazioni cliniche tra i vari operatori nonché fornire gli standard necessari per assicurare l’interconnessione delle strumentazioni disponibili con i PACS di entrambe le aziende tramite standard.
Altri obiettivi sono i seguenti:
• Ottimizzazione dei flussi di lavoro
• Disponibilità delle immagini diagnostiche in tempo reale in modalità film-less
• Minimizzazione del rischio di errori nella gestione del workflow clinico attraverso un elevato livello di automatizzazione ed integrazione informatica sia a livello dipartimentale che aziendale ed interaziendale
• Gestione filmless e paperless delle prestazioni cardiologiche
• Riduzione dei tempi del ciclo di esecuzione e refertazione delle prestazioni erogate
• Miglioramento del processo diagnostico attraverso la disponibilità immediata delle immagini di precedenti indagini cardiologiche
• Aumento del grado di appropriatezza nell’erogazione di prestazioni cardiologiche, evitando la ripetizione di prestazioni
• Ottimizzazione delle risorse umane e tecnologiche a disposizione
• Disponibilità di immagini e referti cardiologici nel dossier clinico informatizzato aziendale ove previsto
In generale la proposta progettuale presentata da ciascuna ditta concorrente dovrà essere coerente ai Documenti di definizione ambiente tecnologico specificati al paragrago 7.2 del presente capitolato tecnico,
che dovrà essere completamente recepito dall’offerente salvo diversa esplicita indicazione riportata nel presente capitolato tecnico.
2.3 Elementi non compresi nella fornitura
Si precisa che le componenti hardware verranno messe a disposizione da Estar.
L’infrastruttura di rete, di storage, di elaborazione dedicate al funzionamento dei servizi implementati nell’ambito di questa fornitura saranno in gestione della stazione appaltante, che garantirà l’operatività delle risorse tecnologiche necessarie al corretto funzionamento di tali infrastrutture, dimensionandole in diretta collaborazione dell’aggiudicatario, che dovrà prevedere tutte le necessità per l’intero periodo contrattuale e descriverle in offerta tecnica.
Il sistema sarà ospitato presso i data center aziendali o presso il data center regionale TIX: l’hardware lato server su cui installare il sistema fornito sarà messo a disposizione dalla stazione appaltante. Le ditte partecipanti dovranno esplicitare nell’offerta tecnica le caratteristiche delle componenti hardware che dovranno essere messe a disposizione affinché ne sia garantito il corretto funzionamento. La stazione appaltante garantisce l’affidabilità, le performances e la sicurezza, sia in termini di protezione perimetrale da indebito accesso, sia in termini di continuità di servizio dei sistemi in caso di malfunzionamenti.
Le componenti a carico delle Aziende e/o di ESTAR saranno:
• la rete locale e geografica;
• i server, di cui devono essere indicate le specifiche tecniche con criteri di ridondanza e gli spazi disco necessari;
• le postazioni di lavoro nei reparti e ambulatori utilizzate per la gestione dei software di reparto o ambulatorio con caratteristiche standard
• le workstation di refertazione con le caratteristiche sotto riportate. Si chiede ai fornitori di specificare in sede di offerta eventuali requisiti necessari per il loro sistema:
Caratteristica tecnica | Valore minimo |
Unità centrale | |
Sistema operativo | Microsoft 10 Pro for Workstation |
Interruttore di accensione | Frontale |
Quantità di memoria RAM supportata (GB) | 64 |
Quantità di memoria RAM installata (GB) | 32 |
Scheda madre in modo supportare memora RAM Error- correcting Code (ECC) | Sì |
Tipolgia memoria RAM da installare | RAM Error-correcting code (ECC) |
Numero di alloggiamenti per ospitare la memoria RAM | 4 |
Supporto RAID controller I/O drive | 0,1 |
Capacità unità Storage #1 (GB) | 500 |
Tipologia Unità Storage #1 | SSD M.2 NVMe |
Capacità Unità Storage #2 (TB) | 1 |
Tipologia Unità Storage #2 | HDD SATA 6.0Gb/s, da 2.5“ o 3.5“, da 5400 rpm o 7200 rpm |
I/O S-ATA 6 Gbit/sec | 4 |
Possibilità di installare Unità Storage #3 all‘intrno del cabinet su porta 6Gbps SATA | Sì, con HDD avente le stesse caratteristiche dell‘Unità Storage #2 |
Slot di espansione di tipo PCI Express o altre tecnologie con banda superiore, al netto degli slot occupati dalle schede necessarie a soddisfare la configurazione base | 2 |
Scheda Audio | stereo |
Alimentatore | con sistema alimentazione con scheda aggiuntiva |
Potenza alimentatore | 400W |
Media Card Reader | |
Integrato nel cabinet | Sì |
Numero di tipologie di schede gestite | 4 |
Tipologia di schede gestite | in grado di supportare almeno 3 tipologie di schede, tra SD, SDHC, SDXC, Micro SD, Micro SDHC |
Controllore grafico integrato | |
Risoluzione | In grdo di supportare monitor offerti alla loro risoluzione massima |
Numero di uscite video digitali (DisplayPort e/o HDMI) | 2 |
Numero di Monitor indipendenti contemporaneamente supportati da uscite video digitali | 2 |
Interfacce Input / Output | |
interfacce udio in/out (anche combo) | Frontali |
interfacce esterne (USB 3.0, USB 2.0) | 2, 4 |
interfaccia Ethernet RJ45 | 1 |
Conformità ISO 8802-3 | IEEE 802.3 (10Base-T), 802.3u (100Base-TX), 802.3ab (1000Base-T) |
Tastiera | Italiana estesa, QWERTY, con tasto funzione di Windows®, tastierino numerico separato |
Mouse | di tipo ottico, a due p tre pulsanti e con rotella per lo scrolling, risoluzione almeno 800 dpi e lunghezza cavo almeno 1,5 m |
Gestione da remoto | |
Scheda madre in grado di intercettare un impulso Wake On LAN | Sì |
Controllo da remoto della configurazione hw del pc | Sì |
Controllo da remoto dello stato di accensione del pc | Xx |
Controllo da remoto della configurazione BIOS del pc | Sì |
Prestazioni del sistema | |
PCMark 10 Extended score (v. par. 4.9) | 3.100 |
Monitor di fascia A e di fascia B a seconda della funzionalità richiesta:
Caratteristica tecnica | Valore minimo |
Fascia A | |
Diagonale | 27” |
Angolo di visualizzazione (orizzontale e verticale) | 178° |
Luminosità (cd/mq) | 300 |
Schermo antiriflesso | Sì |
Risoluzione nativa | 2560x1440@60Hz |
Ingressi (DisplayPort , HDMI) | 1 DP, 1 HDMI |
Interfacce USB | 4 |
Connettività in uscita (daisy chain) | Sì |
On-screen-display | Sì |
Picture in Picture | Sì |
Audio I/O | Sì |
Fascia B | |
Diagonale | 31.5” |
Angolo di visualizzazione (orizzontale e verticale) | 178° |
Luminosità (cd/mq) | 350 |
Schermo antiriflesso | Sì |
Risoluzione nativa | 1980x1920@60Hz |
Ingressi (DisplayPort , HDMI) | 1 DP, 1 HDMI |
Interfacce USB | 4 |
On-screen-display | Sì |
Picture in Picture | Sì |
Audio I/O | Sì |
Sistema di montaggio | VESA |
Cavo di alimentazione | per presa Schuko |
Certificazione | TCO Cerified Display 7.0 (o superiore) o certificazione equivalente |
Nel presente capitolo si riportano alcuni dati relativi all’ambito di riferimento con particolare focus sulle informazioni utili a definire il dimensionamento dell’ambito di applicazione e ad inquadrare la situazione in essere :
Unità operative di interesse del Dipartimento in AOUS Presidio Struttura
AOUS UOC Anestesia e Rianimazione cardio-toraco-vascolare
UOC Cardiologia clinico-chirurgica (UTIC)
UOC Diagnostica Cardiovascolare
UOSA Cardiologia Interventistica
UOC Cardiochirurgia
UOSA Chirurgia dei Grossi Vasi
Unità operative di interesse del Dipartimento in ASL TSE Presidio Struttura
Arezzo
UOC Cardiologia
Grosseto
Arezzo UOSI Terapia intensiva cardiologica
Arezzo
UOSD Interventistica Cardiovascolare
Grosseto
Grosseto SEZIONE Cardiologia clinica
Grosseto SEZIONE Elettrofisiologia
Grosseto UOSI Diagnostica cardiovascolare del paziente con cardiopatia complessa
Attuali sw in uso
Azienda | Presidio | Reparto | Software | Fornitore |
AOUS | AOU Siena | Emodinamica | Suite-Extensa | Ebit |
Emodinamica | Sala Operatoria Ormaweb | Dedalus |
Azienda | Presidio | Reparto | Software | Fornitore |
Diagnostica Cardiovascolare universitaria | EchoPAC | GE Healthcare | ||
Tutti i reparti | CCE Pleiade | Estar | ||
ADT AuroraWeb | Exprivia | |||
ASL TSE | Ospedale San Donato - Arezzo | Emodinamica | Cardio | GPI |
Tutti i reparti | ADT - Degenze | GPI | ||
Cartella ambulatoriale Ambu | GPI | |||
ASL TSE | Ospedale Misericordia - Grosseto | Emodinamica | Cardioplanet | Ebit |
Ambulatori di Ecografie | Refertazione Q-Station | Philips | ||
Tutti i reparti | ADT GSO-web | Data Processing |
Dotazione organica del personale
Ospedale | Medici | Infermieri Professionali | OSS/OTA |
Xxxxxx - Xxx Xxxxxx | 00 | 40 | 8 |
Grosseto - Misericordia | 21 | 61 | 5 |
Siena - AOUS | 59 | 134 | 0 |
Volumi di attività / prestazioni eseguite nel corso dell’anno 2019
Fonti UOC Controlli di Gestione aziendali e attività interna al reparto che effettua l'esame o comunque non contabilizzata c ome prestazione
Ospedale | Esami angiografici (emodinamica) | Procedure Ecocardiografiche |
Arezzo - San Donato | 1.718 | 13.000 |
Grosseto - Misericordia | 1.200 | 16.300 |
Siena - AOUS | 3.344 | 20.000 |
La strumentazione clinica di base in dotazione è riportata nei seguenti allegati rispettivamente per ogni azienda e ospedale:
Ospedale | File |
Arezzo - San Xxxxxx Xxxxxxxx - Misericordia USL TSE | Strumentazione clinica di base _Cardiologia_USLTSE.xls |
Siena - AOUS | Strumentazione clinica di base _Cardiologia_AOUS.xls |
Le apparecchiature diagnostiche sopra riportate, e la relativa produttività (esami/anno), dovranno essere considerate nel dimensionamento del sistema PACS aziendale, per cui si chiede una valutazione dei volumi in offerta tecnica.
4. Processi funzionali ed eventuali sistemi informatici correlati
4.1 Modello Applicativo e Descrizione dei Processi
Si riporta di seguito una definizione dei processi che il software dovrà supportare suddiviso nelle macro-fasi principali che il sistema offerto dovrà gestire nell’ambito del flusso di lavoro implementato.
4.1.1 Accettazione del paziente, lista di lavoro ed esecuzione dell’esame
Deve essere gestita la possibilità di accettare il paziente all’esecuzione dell’esame con conseguente invio della lista di lavoro ai macchinari che permettano di implementare tale funzionalità, in modo che l‘operatore non sia costretto ad inserire manualmente i dati del paziente e della prestazione nel sistema.
Deve essere possibile ricercare un paziente o un esame con query e filtri (per nome, per data, per reparto, ecc.). Deve essere possibile ordinare l’elenco degli esami con varie modalità. Il sistema dovrà, altresì, consentire all’operatore di far passare l’esame nello stato di erogato in modo da rendere disponibil i le immagini al medico refertante.
4.1.2 Archiviazione
La archiviazione delle immagini nativamente in formato digitale elaborabile deve mantenere il medesimo formato, tranne per lo storico preesistente che può essere in formato immagine, PDF o similari. Per l’archiviazione delle immagini e dei filmati con i relativi referti dovrà essere utilizzata l’infrastruttura registry- repository, già in dotazione/in fase di acquisizione delle AAOO e AASS impostata secondo l’architettura XDS di IHE, che fa pieno riferimento per le specifiche di integrazione al Technical Framework IHE per il dominio IT_Infrastructure.
L’architettura XDS prevede che le prestazioni sanitarie (tracciati e referti) vengano depositate nell’XDSREPOSITORY; questo archivio viene quindi indicizzato in un XDSREGISTRY che viene consultato per evidenziare gli episodi clinici che hanno generato la prestazione. Il Registry indicherà la posizione di recupero, ovvero in quale Repository è memorizzato l’esame di interesse, e lo renderà fruibile su un “visualizzatore” chiamato XDSCONSUMER. L’XDS consumer rispetto alla documentazione (referti e tracciati) che sarà gestita dal sistema dovrà essere fornito dalla ditta aggiudicataria e dovrà consistere in un visualizzatore che permetta di consultare (ed, eventualmente, effettuare le misurazioni/valutazioni del caso) il suddetto sistema registry-repository rispetto ai documenti di propria competenza, secondo quanto stabilito dalle regole stabilite nell’Affinity Domain.
I referti archiviati dovranno essere quelli firmati digitalmente dall’operatore refertante.
4.1.3 Refertazione
Il sistema deve garantire vari protocolli di visualizzazione anche predefiniti in base alla profilatura dell’utente. Le visualizzazioni richieste sono quelle tipiche (zoom, scroll, ecc.), compresa la visualizzazione di più immagini simultaneamente per permetterne il confronto (traccia a traccia, esame a esame, ecc.).
Il sistema deve gestire la refertazione in modo semplice ed efficace con tools appropriati (frasi predefinite, shortcut, diciture personalizzabili, ecc.).
Al termine della refertazione il sistema deve poter consentire all’operatore di firmare digitalmente il referto mediante l’uso della Carta Operatore della Regione Toscana in dotazione al personale del SSR (i certificati digitali non sono oggetto della fornitura).
In considerazione dell’obiettivo del SSR di evolvere verso una architettura di firma digitale e marcatura temporale centralizzati e di livello regionale, le ditte concorrenti dovranno far evolvere il sistema offerto verso tali tecnologie senza oneri aggiuntivi.
I documenti sottoscritti digitalmente dovranno essere archiviati e resi disponibili per successiva consultazione da parte degli operatori abilitati rispetto alla specifica profilatura utente. Sarà considerata condizione preferenziale la possibilità per il medico refertante di comporre automaticamente un referto strutturato comprensivo del testo del referto stesso e del tracciato ad esso relativo.
4.1.4 Statistiche
Nella fornitura dovrà essere prevista l’attivazione di un modulo specifico di estrazione di statistiche sui dati di attività. Su tale modulo, utilizzabile solo da specifici profili che saranno individuati in fase di configurazione, dovrà essere possibile impostare statistiche sia standard sia personalizzabili da parte di utenze con privilegi di amministratore di sistema. Dovrà essere possibile esportare i risultati di tutte le estrazioni statistiche in formati fruibili con strumenti di office automation di tipo open source.
4.2 Contesto Strutturale ed Organizzativo
Il flusso che si auspica di potere realizzare vede la gestione del paziente dal momento in cui viene in contatto con la Cardiologia sino a quando vengono completate le informazioni cliniche e la stesura del referto; ne consegue che maggiore è il numero di moduli di refertazione specifici, maggiore saranno i benefici dell’implementazione di un sistema informatico di questa portata. Il sistema per la visualizzazione e la refertazione, strutturato in un’unica piattaforma fornirà pertanto tutte le funzionalità caratteristiche e dettagliate per la condivisione degli strumenti di refertazione.
Il sistema offerto deve prevedere la possibilità di archiviazione su PACS ed il recupero dallo stesso degli studi prodotti secondo lo standard DICOM, implementando almeno i servizi DICOM STORE e DICOM QUERY/RETRIEVE e l’archiviazione dei referti prodotti, nonché dei relativi riferimenti KOS (secondo quanto previsto dallo standard XDS di IHE, per il recupero da PACS delle immagini prodotte) sull’infrastruttura registry-repository, già in dotazione/in fase di acquisizione da parte delle AASS/AAOO destinatarie della fornitura, impostata secondo l’architettura XDS di IHE, che fa da riferimento per le specifiche di integrazione al Technical Framework IHE per il dominio IT_Infrastructure.
In entrambe le Aziende Sanitarie/Ospedaliere coinvolte fin da subito nella fornitura (AOUS e AUSLTSE) è ad oggi implementato il sistema registry-repository XDS SilverXDS della ditta GMED, in eventuale sostituzione con la piattaforma Healthshare di Intersystems acquisita mediante procedura di gara indetta con Determinazione EstaR N° 612 del 18/04/2017 (consumer XDS per gli studi DICOM è l’applicativo Engage Suite di Agfa), che prevede l’implementazione di un repository per ciascuna Azienda Sanitaria/Ospedaliera di regione Toscana e un unico registry regionale.
Di seguito si riporta l’attuale distribuzione dei sistemi PACS rispetto alle XX.XX/A.O. coinvolte fin da subito nella fornitura (AOUS e AUSLTSE):
• AOUS: PACS di fornitura Philips (ex Carestream Health)
• AUSL zone Senese e Grossetana: PACS di fornitura Philips (ex Carestream Health)
• AUSL zona Senese Aretina: PACS di fornitura GE Medical System
Presso tutte le Aziende Sanitarie e Ospedaliere della Regione Toscana è attualmente in fase di dispiegamento, inoltre, un sistema centralizzato (acquisito anch’esso mediante procedura di gara aggiudicata con Determinazione EstaR N° 1485/2019) di gestione dematerializzata dei consensi espressi dal paziente nel corso del processo assistenziale.
Tale sistema, interagendo con l’infrastruttura IHE-XDS attiva sul territorio regionale, è in grado di gestire il valore "Confidentiality Code" e di modificarlo sulla base delle volontà del paziente come previsto dalle vigenti norme inerenti la gestione della privacy. Esso può integrarsi con molteplici ambiti di applicazione che siano in grado di dialogare con l’infrastruttura XDS ed implementa idonea tecnologia di acquisizione dematerializzata dei consensi (FEA grafometrica).
Pertanto, rispetto a quest’ultimo punto, il sistema offerto in gara dovrà interfacciarsi secondo la progettazione regionale ed i tempi organizzativi di ciascuna azienda con:
• il sistema centralizzato di gestione dei consensi informati (MeView/MeDMaker/MeCom della ditta Medas) utilizzando metodi web service esposti da quest’ultimo che gli consentiranno di interagire con gli applicativi di gestione della banca dati centralizzata dei modelli dei consensi, inviando ad essa i dati necessari per la compilazione del documento di consenso che restituirà al chiamante;
• il sistema centralizzato di firma digitale per apporre la FEA grafometrica o la firma digitale sul documento di consenso prodotto.
Ai fini del consumo del documento clinico archiviato sul repository XDS aziendale, l’interrogazione del registry XDS regionale risponde fornendo la posizione del documento e gli estremi per effettuare il relativo retrieve solo nel caso di consenso espresso alla consultazione del medesimo da parte del paziente. In caso contrario viene restituito al sistema richiedente una risposta negativa alla richiesta di accesso.
Il sistema offerto in gara dovrà, inoltre, interfacciarsi, per la sottoscrizione digitale dei referti prodotti, con il sistema centralizzato di firma digitale Scryba Sign di Medas in uso presso le XX.XX./AAOO della Regione Toscana.
Inoltre, dal momento che obiettivo ultimo del processo evolutivo dell’impianto di conservazione digitale in uso presso le AASS/AAOO di Regione Toscana è di addivenire alla situazione in cui sia attivo un canale per ciascun repository XDS unico a livello di Azienda Sanitaria/Ospedaliera, disattivando progressivamente canali diretti dalle sorgenti documentali (applicativi versanti in conservazione) verso il sistema di conservazione, l’archiviazione sul repository XDS Aziendale dei documenti firmati digitalmente (XDS document source) da parte del sistema oggetto di gara dovrà comportare, previa definizione della specifica regola sull’Affinity Domain, l’automatico invio in conservazione degli stessi.
Per la conservazione a norma è necessario che ciascun documento, generato dai sistemi versanti nei formati previsti dall’ Allegato 2 DPCM 3 dicembre 2013 – Regole Tecniche per la Conservazione Digitale, venga corredato di “Dati Archivistici” o “metadati” che indicizzano in maniera esaustiva ed univoca il documento in registrazione e ricerca. La normativa vigente impone un set minimo di “metadati” (Allegato 5 DPCM 3 dicembre 2013 – Regole Tecniche per la Conservazione Digitale) oltre i quali nel sistema di conservazione possono essere definite classificazioni archivistiche “standard” con metadati aggiuntivi ed accessori i cui campi dovranno essere presenti sul sistema versante oggetto della presente gara.
Le informazioni sopra riportate sono state inserite a scopo indicativo e rispecchiano la situazione previsionale al momento della redazione del presente capitolato tecnico.
4.3 Integrazione con le apparecchiature sanitarie
Il sistema deve essere in grado di collegarsi con le apparecchiature dei principali produttori presenti sul mercato con particolare riferimento a quelli presenti in AOUS e ASL TSE in prima istanza e di eventuali altre Aziende Sanitarie/Ospedaliere che aderiscano alla presente Convenzione successivamente e ai macchinari che saranno acquisiti per l’intero periodo contrattuale, purché dotati delle necessarie interfacce.
L’integrazione nel sistema di apparecchiature acquisite successivamente o già presenti in azienda ma non inserite all’avvio del contratto di adesione, purché dotati delle necessarie interfacce , potranno essere collegate al sistema opzionalmente dalle XX.XX in base al listino prezzi inserito in offerta.
Le ditte concorrenti dovranno fornire in offerta tecnica una lista dettagliata dei modelli collegabili, con particolare riferimento agli elenchi della dotazione strumentale presente nelle Aziende. Nel caso di modelli dotati di interfaccia DICOM, su cui non siano stati attivati i moduli necessari per implementare l’integrazione, inseriti dalla ditta aggiudicataria tra quelli integrabili nel sistema, sarà facoltà dell’Azienda Sanitaria/Ospedaliera decidere se investire o meno sugli apparecchi interessati. Nel caso l’offerente ritenga necessario introdurre un sistema di acquisizione/conversione, la gestione completa del sistema in questione (manutenzione, back up, ecc.) è inclusa nel contratto.
In considerazione dell’obiettivo della stazione appaltante, descritto nei documenti di definizione ambiente tecnologico paragrafo 7.2, di far evolvere le integrazioni degli apparati biomedicali verso una logica di accessi ai dati da essi prodotti secondo logiche a servizi, le ditte concorrenti dovranno esplicitamente riportare in offerta tecnica la disponibilità e l’impegno a far evolvere il sistema offerto verso tale approccio, senza oneri aggiuntivi. Per meglio specificare tale richiesta si riporta la definizione di evento sanitario di tipo diagnostico: evento sanitario che caratterizza interoperabilità fra applicativi gestionali ed apparati diagnostici, ovvero segnalazione di cambiamento di stato di indagine diagnostica supportata strumentalmente comprendente dati elettromedicali in formato raw. Il disegno e la messa in opera di una rete di trasporto di eventi di tipo diagnostico è attività determinante per favorire una crescita coerente ed efficace delle interoperabilità in ambito sanitario, dato il legame ineludibile con apparati diagnostici biomedicali. L’evento sanitario di tipo diagnostico ed una infrastruttura che ne garantisca il trasporto da/per tutti gli attori interoperanti nel SSR è elemento garante che gli investimenti nel settore della diagnostica biomedicale risultino pienamente efficaci non solo dal punto di vista clinico, ma anche da quello dell’ormai indifferibile necessità di fruire pienamente ed efficacemente delle risultanze informatiche generate dagli apparati.
4.4 Integrazioni con sistemi interni ed esterni
Tutte le integrazioni di seguito descritte dovranno comunque essere implementate nel rispetto di quanto indicato nel paragrafo 7.2 Documenti di definizione ambiente tecnologico (verificando l’esistenza di eventuali versioni aggiornate al momento dell’avvio del progetto). I dettagli tecnici delle integrazioni devono essere oggetto dell’offerta tecnica al presente capitolato in termini di soluzione proposta e secondo le modalità di integrazione rese necessarie sulla base dei fornitori dei servizi invocati.
In considerazione dell’obiettivo della stazione appaltante, descritto nel Documenti di definizione ambiente tecnologico, di implementare un modello di tipo service-oriented abbandonando progressivamente logiche application-oriented, le ditte concorrenti dovranno considerare di redigere offerte tecniche coerenti con tali indicazioni; qualora il sistema offerto non sia, nella sua prima installazione, pienamente aderente al modello service-oriented, dovranno essere indicate le tempistiche, a partire dall’ordine di fornitura, entro cui il sistema offerto evolverà verso tale approccio, senza oneri aggiuntivi. Tali tempistiche non potranno essere superiori a 240 giorni solari.
Lo sviluppo e l’implementazione delle integrazioni in oggetto lato fornitore si intende a carico della ditta aggiudicataria, mentre lato applicativi integrati sarà da considerarsi a carico della stazione appaltante che prenderà accordi specifici con i relativi fornitori.
Rappresenta condizione preferenziale la fornitura in offerta anche di un sistema Data Entry, con licenze d’uso illimitate, che verrà utilizzato dagli operatori che non hanno la possibilità di utilizzare altri sistemi per inserire i dati personali del paziente e della prestazione. Tale Data Entry trasmetterà le richieste di erogazione di esami al sistema di refertazione che reinvierà al Data Entry l’informazione di erogato dell’esame, il relativo referto e il collegamento alle specifiche immagini. Dovrà, comunque, essere possibile anche l’inserimento sia manuale sia con lettura mediante barcode di nuovi pazienti non presenti nell’anagrafica centrale. L’attivazione/disattivazione di tale funzione deve poter essere configurabile da utenza di amministratore.
Viene schematizzato di seguito in modo esemplificativo il flusso delle integrazioni descritte di seguito:
4.4.1 Cataloghi aziendali
E' richiesta l'integrazione con i seguenti cataloghi centralizzati minimali:
• RCT - tabelle di riferimento di regione toscana, fra queste si evidenziano in particolare:
◦ COMUNI
◦ STATI
◦ INTERVENTI
◦ DIAGNOSI_ICD9_CM
◦ ESENZIONI
◦ AZIENDECOMUNI
◦ FARMACI
◦ AZIENDE_SANITARIE
• Catalogo unico prestazioni
• Discipline
• Medici interni, esterni e convenzionati
• Elenco personale medico e sanitario
• Centri di Costo, specialità
La modalità di integrazione prevista dovrà essere realizzata a servizi entro i termini di completamento dell’avvio: se non immediatamente possibile, previo accordo con l’ente, potranno essere utilizzate modalità legacy, in via comunque temporanea.
In ogni caso tutti i dati dei cataloghi devono essere, all'occorrenza, gestibili tramite interfacce software disponibili per operatori abilitati.
4.4.2 Anagrafe unica regionale
Il sistema deve prevedere un unico archivio anagrafico per la gestione dei pazienti e consentire di disporre subito di tutte le informazioni raccolte nella storia del paziente.
Il sistema utilizzerà l'Anagrafe Unica Regionale come archivio dei dati anagrafici degli assistiti e più in generale di tutti i soggetti, correttamente identificati, che vengono a contatto con il dipartimento.
La comunicazione con tale archivio è definita secondo gli scenari dell'RFC 249 di Regione Toscana.
4.4.3 Anagrafe operatori
Il software dovrà integrarsi con il sistema LDAP per l’ autenticazione. E’ richiesta la predisposizione di almeno 5 funzionalità:
- Inserimento nuovo utente (delegata IDM)
- Abilitazione utente
- Disabilitazione utente
- Reset password utente (solo tramite integrazione con IDM)
- Verifica scadenza password
Tali funzionalità dovranno essere implementate con servizi invocabili direttamente dal sistema IDM.
Il sistema dovrà consentire la gestione dei ruoli, attribuibili a ciascun utente, e l’associazione dell’accesso alle funzionalità per ogni ruolo con interfacce applicative e attribuibili a ruoli che non siano obbligatoriamente di amministratore.
Dovranno inoltre essere realizzate almeno due report con l'elenco degli utenti e l'elenco dei profili. L’accesso al sistema deve essere garantito anche in assenza di integrazione con i sistemi sopra menzionati.
4.4.4 ADT
In caso di pazienti ricoverati, il sistema interagisce con il gestionale ADT con questa modalità:
• Acquisizione del numero nosologico del ricovero generato da ADT
• Diagnosi accettazione
• Dati del ricovero o dell’accesso in DH
Il sistema deve sottoscrivere o comunque essere in grado di ricevere RFC-123 anche invocando apposito servizio, di cui si allegano le specifiche in RFC-123_ADT-ver02_14.pdf.
4.4.5 Cartella Clinica Elettronica Ospedaliera
Il sistema deve interagire con la CCE aziendale con questa modalità:
• per l’interscambio di informazioni cliniche
• gli eventi sanitari (esami diagnostici, terapie, procedure, trasfusioni e consulenze) effettuati durante l’accesso
• consulenze: recupero del referto in risposta alla consulenza richiesta
4.4.6 Cartella Clinica Elettronica Ambulatoriale
La cartella ambulatoriale trasmetterà le richieste di erogazione di esami al sistema di refertazione che reinvierà alla cartella l’informazione di erogato dell’esame, il relativo referto e il collegamento alle specifiche immagini. Questa integrazione si ritiene opzionale in quanto le XX.XX. avranno la facoltà di decidere se gestire tale processo all’interno del software oggetto di gara o con la cartella ambulatoriale eventualmente già in uso negli ambulatori con cui si dovrà integrare.
4.4.7 Registry/repository XDS e fornitura dell'XDS consumer
Integrazione necessaria per:
• Recupero referti esami (XDS)
• Trasmissione referti esami (XDS)
• Condivisione di qualsiasi documento di altri sistemi al fine di facilitare le operazioni di consultazione interdisciplinare
• Recupero cartella Clinica (quando sarà tutta digitalizzata)
L’architettura XDS prevede che le prestazioni sanitarie vengano depositate nell’XDSREPOSITORY; questo archivio viene quindi indicizzato in un XDSREGISTRY che viene consultato per evidenziare gli episodi clinici che hanno generato la prestazione. Il Registry indicherà la posizione di recupero, ovvero in quale Repository è memorizzato l’esame di interesse, e lo renderà fruibile su un “visualizzatore” chiamato XDSCONSUMER. L’XDS consumer rispetto alla documentazione che sarà gestita dal sistema oggetto della presente gara dovrà essere fornito dalla ditta aggiudicataria e dovrà consistere in un visualizzatore che permetta di consultare (ed, eventualmente, effettuare le misurazioni/valutazioni del caso) il suddetto sistema registry- repository rispetto ai documenti di propria competenza, secondo quanto stabilito dalle regole stabilite nell’Affinity Domain.
4.4.8 PACS
Il sistema deve interagire con il PACS aziendale con possibilità di consultazione e richiamo di tutti gli esami associati al paziente (anche provenienti da modalità differenti) e dell’archiviazione di tutte le immagini e dei filmati acquisiti tramite il software oggetto di gara.
4.4.9 CUP AZIENDALE
Sistema di prenotazione CUP per la acquisizione delle prenotazioni di esami. Il CUP trasmetterà le prestazioni programmate al sistema di refertazione che reinvierà al CUP l’informazione di erogato dell’esame. Le specifiche tecniche di dettaglio saranno definite e formalizzate in specifici incontri congiunti tra Aziende e fornitori dei due sistemi interessati.
4.4.10 CUP 2.0
Sistema di prenotazione CUP 2.0 per la prenotazione e gli spostamenti di esami. Il sistema deve interagire secondo le specifiche regionali per la prenotazione di esami ed il loro spostamento su CUP 2.0. Le specifiche tecniche di dettaglio saranno definite e formalizzate in specifici incontri congiunti tra Aziende e fornitori dei due sistemi interessati.
4.4.11 Integrazioni con sistemi in contesto
Fatte salve le specifiche architetturali indicate nel presente documento, nonché negli specifici allegati, potrebbe essere necessario in talune realtà ed in alcuni specifici ambiti, utilizzare, anche temporaneamente, l’apertura in contesto dei software esterni al sistema, previo accordo con i servizi IT di ESTAR.
4.4.12 Firma digitale centralizzata
In considerazione dell’obiettivo della stazione appaltante, descritto nei Documenti di definizione ambiente tecnologico del presente capitolato tecnico, di implementare il servizio di firma digitale e marcatura temporale cui ciascun attore del Servizio Sanitario Regionale Toscano possa accedere, le ditte concorrenti dovranno esplicitamente riportare in offerta tecnica la disponibilità e l’impegno a far evolvere il sistema offerto verso tale approccio tramite servizi di interoperabilità, senza oneri aggiuntivi e per l’intera durata contrattuale.
4.4.13 Gestore consensi centralizzati
In considerazione dell’obiettivo della stazione appaltante, descritto nei Documenti di definizione ambiente tecnologico del presente capitolato tecnico, di implementare il servizio di gestione consensi centralizzato cui ciascun attore del Servizio Sanitario Regionale Toscano possa accedere, le ditte concorrenti dovranno esplicitamente riportare in offerta tecnica la disponibilità e l’impegno a far evolvere il sistema offerto verso tale approccio tramite servizi di interoperabilità, senza oneri aggiuntivi e per l’intera durata contrattuale.
4.4.14 Prescrizione elettronica Sire3
Il sistema deve interagire con il sistema di prescrizione elettronica regionale secondo le specifiche regionali, solitamente tramite apertura in contesto.
4.4.15 Magazzino aziendale
Il sistema deve interagire con il software del magazzino aziendale per la gestione del materiale di reparto proveniente da Estar o da acquisti aziendali, qualora questa integrazione non sia possibile per motivi organizzativi delle singole XX.XX. la movimentazione del materiale utilizzato e le altre funzionalità richieste al paragrafo 2.1 dovranno essere gestite direttamente dal software oggetto della presente gara fino al momento in cui sarà possibile attivare questa integrazione prevedendo, in caso di farmaci, la rendicontazione prevista dalla normativa regionale con la produzione dei relativi flussi-informativi.
4.4.16 Sala Operatoria
Il sistema deve interagire con il software di sala operatoria aziendale per:
• Recupero pazienti in lista operatoria per interventi programmati di emodinamica
• Trasmissione referto operatorio e dati necessari alla produzione dell’RFC 165 da parte del sistema di sala operatoria sia in caso di paziente recuperato da lista operatoria che per urgenze inserite direttamente sul CIS. Le specifiche tecniche di dettaglio saranno definite e formalizzate in specifici incontri congiunti tra Aziende e fornitori dei due sistemi interessati.
Nella seguente tabella si elencano per semplicità il nome del software e il nome del fornitore di quanto descritto in precedenza in questo stesso paragrafo:
Sistema Informatico | MODALITA’ INTEGRAZIONE | USL SE | AOUS |
ANAGRAFE UNICA REGIONALE | RFC 249 | ORFEA (RT) | ORFEA (RT) |
ANAGRAFE OPERATORI | WEB SERVICE | ANAGRAFE SOGGETTI | ACTIVE DIRECTORY |
Sistema Informatico | MODALITA’ INTEGRAZIONE | USL SE | AOUS |
ADT | RFC -123 | DATA PROCESSING (GR) DEGENZE-WEB GPI (AR) | AURORA-WEB EXPRIVIA |
CCE DI RICOVERO | WEB SERVICE/HL7 | PLEIADE (ESTAR) dove attiva | PLEIADE (ESTAR) |
CCE AMBULATORIALE | WEB SERVICE/HL7 | Oggetto di fornitura | PLEIADE (ESTAR) oppure Oggetto di fornitura |
REGISTRY/ REPOSITORY XDS e fornitura dell'XDS consumer | XDS | HealthShare di INTERSYSTEM da gara regionale (ad oggi GMED) | HealthShare di INTERSYSTEM da gara regionale (ad oggi GMED) |
PACS | DICOM | PHILIPS (GR) GE (AR) | PHILIPS |
CUP AZIENDALE | WEB SERVICE/HL7 | DATA PROCESSING (GR) GPI (AR) | DATA PROCESSING |
CUP 2.0 (prenotazioni/sposta menti) | WEB SERVICE/CONTESTO | ENGINEERING | ENGINEERING |
FIRMA DIGITALE | WEB SERVICE | SCRYBASIGN DI MEDAS | SCRYBASIGN DI MEDAS |
CONSENSI | WEB SERVICE | MeView, MeDMaker e MeCom di MEDA da gara regionale | MeView, MeDMaker e MeCom di MEDA da gara regionale |
SIRE3 | CONTESTO | DEDALUS | DEDALUS |
MAGAZZINO AZIENDALE | WEB SERVICE/HL7 | DATA PROCESSING | DATA PROCESSING |
SALA OPERATORIA | RFC 165/WEB SERVICE/HL7 | ORMAWEB DEDALUS | ORMAWEB DEDALUS |
Nell’arco di tempo di svolgimento della gara il contenuto di questa tabella potrebbe variare
5. Requisiti Funzionali e Tecnologici del sistema
La fornitura deve includere le funzionalità che seguono, classificate secondo la tematica delle funzioni.
5.1 Requisiti Funzionali
Si riportano nel seguito le caratteristiche generali che il sistema deve avere oltre ai requisiti espressi nei capitoli precedenti. Tali caratteristiche hanno carattere obbligatorio eccetto quelle espressamente indicate come migliorative e/o preferenziali:
ID | Requisito | Obbligatorio/ Preferenziale/ Migliorativo |
001 | Il software deve essere classificato come dispositivo medicale rispondente a quanto contenuto nella direttiva 2007/47/EC | Obbligatorio |
002 | Il sistema per la visualizzazione e refertazione delle diverse metodologie d’indagine presenti possibilmente lo stesso strumento di refertazione con caratteristiche specifiche e dettagliate per ogni specialità cardiologica | Migliorativo |
003 | Da ogni postazione deve essere possibile consultare/visionare esami e referti relativi ad altra specialità diagnostica cardiologica | Obbligatorio |
004 | Il sistema deve essere aperto e permettere l’interfacciamento con diagnostiche (ecocardiografiche, angiografiche) di qualunque produttore | Obbligatorio |
005 | L’interfaccia utente ed i manuali devono essere in italiano | Obbligatorio |
006 | Il sistema deve essere compatibile con qualunque vendor, ovvero consentire l’interfacciamento con gli ecocardiografi di qualunque produttore purché DICOM, o secondo altro standard, e con connessione di Rete | Obbligatorio |
007 | Si ritiene condizione preferenziale la conformità DICOM WAVEFORM. | Preferenziale |
008 | Deve essere possibile l’inserimento delle descrizioni morfologiche delle strutture anatomiche cardiache mediante campi strutturati (con possibilità di ricerca su questi campi) | Obbligatorio |
009 | Deve essere possibile creare schede di refertazione a rapida compilazione per esami di routine | Obbligatorio |
010 | Creazione di schede di refertazione: ⚫ dedicate ad esami che studiano patologie specifiche (con maggiore dettaglio di descrizione e completezza di misure); ⚫ in base all’approccio di studio (esami transtoracici, transesofagei etc.) | Migliorativo |
011 | Creazione automatica di un database scientifico in grado di anonimizzare i referti, dal quale estrarre dati e condividere informazioni cliniche | Migliorativo |
012 | Devono essere compresi un adeguato numero di punti di accesso ai quali possano accedere indifferentemente tutti gli utenti abilitati alla refertazione o alla consultazione dei referti | Obbligatorio |
013 | Le liste di lavoro devono dare evidenza dello stato di refertazione (da refertare, refertato, definitivo) e dell’urgenza. La stessa lista deve potere essere ordinata in base all’urgenza e, in generale, in base a qualunque parametro si definisca rilevante | Obbligatorio |
014 | Il sistema di livelli di accesso gerarchici, realizzati mediante identificazione degli | Obbligatorio |
ID | Requisito | Obbligatorio/ Preferenziale/ Migliorativo |
operatori e dei loro “privilegi” dovrà permettere di garantire: • Un adeguato livello di sicurezza che assicuri l’integrità e la consistenza dei dati, impedendo modifiche non autorizzate e/o cancellazioni accidentali, • Un accesso controllato che consenta l’accesso dei soli utenti abilitati, mediante autenticazione con ID utente e password (integrando il sistema di ADM) ai soli dati da essi consultabili, garantendo la “privacy” delle informazioni contenute, e con un sistema di registrazione dei log e delle operazioni effettuate | ||
Si riportano di seguito le funzionalità specifiche di emodinamica che il sistema deve avere | ||
015 | Tracciabilità sulle fasi di intervento: ⚫ pre-procedura (es. anagrafica del paziente, storia clinica, indicazione all’esame …); ⚫ intra-procedura (es. procedure eseguite e operatori coinvolti, complicanze, materiali impiantati e farmaci somministrati … ); ⚫ post-procedura (es. complicanze, tempi di esecuzione delle procedure e di transito e osservazione del paziente, tempi per la rete dell’infarto… ); | Obbligatorio |
016 | Interagire con il software del magazzino aziendale per la gestione del materiale di reparto proveniente da Estar o da acquisti aziendali, qualora questa integrazione non sia possibile per motivi organizzativi delle singole XX.XX. la movimentazione del materiale utilizzato dovrà essere gestita direttamente dal software oggetto della presente gara fino al momento in cui sarà possibile attivare questa integrazione. In entrambi i casi deve essere possibile la gestione automatica del magazzino dell’emodinamica con immediata evidenza del materiale a disposizione: scorte di materiale acquistato, scorte del materiale in conto visione, scadenza del materiale acquistato (per utilizzare prima quello con scadenza più vicina), scadenza del materiale in conto deposito (per consegnarlo e chiedere che venga sostituito prima che scada), rintracciabilità dei lotti (per recuperare facilmente eventuali lotti difettosi), tracciabilità del materiale; | Obbligatorio |
017 | Refertazione dettagliata per tipo di procedura eseguita: Coronarografia, Angiografia bypass aorto- coronarici, Angiografia periferica, Angioplastica coronarica e periferica, IVUS, OCT, FFR , Valvuloplastiche, TAVI, Interventi di chiusura percutanea di auricola sn, difetto interatriale, forame ovale pervio; | Preferenziale |
018 | Possibilità di effettuare sulle immagini acquisite misurazioni e analisi quantitativa delle dimensioni e dei volumi delle strutture cardiovascolari con calcolo di lunghezze, percentuali di stenosi e frazione di eiezione dei ventricoli; | Obbligatorio |
019 | Estrazione in qualunque momento di tutti i dati raccolti con semplici selezioni da interfaccia grafica a scopo amministrativo (es. report di attività, …) e a scopo scientifico (es. studi nazionali di settore, …) ; | Obbligatorio |
020 | Creazione di un archivio di dati per utilizzo clinico (utile ad avere a disposizione immediatamente tutte le procedure pregresse dei pazienti della nostra struttura non solo in termini di referto finale ma anche di dettaglio) e scientifico (per disporre automaticamente e senza sforzo ulteriore di tutte le informazioni di procedura che sono richieste anche dalle società nazionali del settore, es. GISE); | Obbligatorio |
ID | Requisito | Obbligatorio/ Preferenziale/ Migliorativo | |
Si riportano di seguito le funzionalità specifiche di ecocardiografia che il sistema deve avere | |||
021 | Accessibilità alle informazioni anagrafiche e cliniche cardiologiche (relative a procedure diagnostiche e interventistiche sia degenziali che ambulatoriali) del paziente; | Obbligatorio | |
022 | Refertazione dettagliata per tipo di esame eseguito (ecografia di base, da stress e transesofagea) previo agreement sullo sviluppo di un referto concordato tra i referenti dei laboratori di ecocardiografia di area vasta, in osservanza degli standard qualitativi raccomandati dalle società scientifiche, per favorire un’armonizzazione del processo; | Obbligatorio | |
023 | Gestione della refertazione degli esami di stress con schede specifiche che riportano la schematizzazione delle parti anatomiche acquisite con lo stesso criterio di visualizzazione (per vista anatomica o fase di stress); | Preferenziale | |
024 | Estrazione in qualunque momento di tutti i dati raccolti con semplici selezioni da interfaccia grafica a scopo amministrativo (es. report di attività, …) e a scopo scientifico (es. studi nazionali di settore, …); | Obbligatorio | |
025 | Creazione di un archivio di dati per utilizzo clinico, amministrativo e scientifico (per disporre automaticamente e senza sforzo ulteriore di tutte le informazioni di procedura che sono richieste anche dalle società nazionali e internazionali del settore, es. SIEC, EACVI); | Obbligatorio | |
026 | Deve essere possibile recuperare immagini e video in formato DICOM ed effettuare analisi off-line per calcolo dello strain delle quattro camere cardiache e recuperare immagini e video 3D per analisi off-line quantitativa e morfologica delle quattro camere cardiache e degli apparati valvolari. | Obbligatorio | |
027 | Gestione della dose radiologica al paziente | Obbligatorio | |
Legenda:
Obbligatorio: requisito indispensabile pena l’esclusione
Preferenziale: requisito non indispensabile ma che qualifica positivamente una offerta rispetto ad un’altra Migliorativo: requisito non indispensabile che la commissione si riserva di valutare come proposta migliorativa
5.2 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 in modo centralizzato nei data-center indicati dal committente e nel rispetto dei Documenti di definizione ambiente tecnologico.
L’offerente deve indicare esplicitamente cosa è compreso nella fornitura e cosa è escluso.
Deve essere prevista la fornitura di licenze d’uso illimitate del sistema descritto. In considerazione della previsione di estensione del sistema ad altri apparecchi, eventualmente di prossima acquisizione da parte
delle Aziende Sanitarie coinvolte, non ci potranno essere vincoli di utenze concorrenti né nell’utilizzo del sistema né nella visualizzazione di immagini e referti archiviati. L'aggiudicatario si impegna ad attivare implementazioni che non sono mai sottoposte a costi variabili di licenza relativi a volumi o utenze: l’utilizzo di quanto fornito si intende mai limitato dalla crescita delle utenze del sistema se non per ovvie esigenze di supporto computazionale, senza nessun aggravio di costo per la stazione appaltante, ovvero a pieno carico dell'aggiudicatario per tutta la durata del contratto, al variare delle utenze e delle postazioni di accesso, relativamente alla parte di fruizione dei servizi implementati. Qualsiasi modulo fornito deve quindi risultare non sottoposto a costi di licenza, ovvero esplicitamente fornito per licenze non limitate. In qualsiasi punto del capitolato tecnico si facesse riferimento a dimensionamento di licenze, tale dimensionamento è da intendersi solamente quale previsione iniziale di utenze, comunque non esaustiva.
L’accesso al sistema deve avvenire attraverso credenziali di autenticazione con vari profili (sola consultazione, refertazione, ecc.).
Verrà valutata positivamente la disponibilità in offerta di sistemi di alert/monitoraggio del corretto funzionamento del sistema che eventualmente implementino algoritmi predittivi dei principali guasti.
Il software deve poter essere utilizzato da qualsiasi pc con le seguenti caratteristiche:
● pc con Microsoft Office o Openoffice/Libreoffice;
● browser Internet Explorer 9 e successive release;
● browser Mozilla Firefox 79.0 e successive;
● browser Google Chrome 84.0 e successive;
La piattaforma dovrà altresì consentire una distinzione in ambienti software corrispondenti alle singole aziende sanitarie e ospedaliere in modo tale da garantire la gestione separata, a livello aziendale, delle attività delle Strutture organizzative delle aziende sanitarie locali e ospedaliere toscane, ovvero di tutti gli Enti destinatari della fornitura. Salvo funzionalità di collaborazione tra professinisti di aziende diverse.
Deve essere prevista la predisposizione, di un adeguato protocollo operativo da far utilizzare alle strutture sanitarie in caso di indisponibilità del servizio, da mantenere aggiornato almeno annualmente.
Dovrà essere fornita la descrizione di tutte le tabelle e dei relativi vincoli di integrità; le Aziende potranno accedere, in qualunque momento anche attraverso altri strumenti software, alle tabelle del database per l'interscambio dati in tempo reale con altri applicativi.
La versione del sistema offerto deve essere l’ultima release disponibile sul mercato. La ditta aggiudicataria dovrà assicurare, senza oneri aggiuntivi, l’aggiornamento SW. Devono essere altresì implementati senza costi ulteriori gli aggiornamenti consigliati dall’aggiudicatario allo scopo di migliorare la perfomance tecnica del prodotto.
Tutte le necessarie licenze SW per rendere la fornitura perfettamente funzionante devono essere incluse ad eccezione delle licenze di terze parti e per l’interfacciamento con gli elettromedicali, come sopra descritto.
Devono, inoltre, essere installate e connesse al sistema il numero di postazioni di refertazione richieste.
Si riportano nel seguito le caratteristiche generali che il sistema deve avere oltre ai requisiti espressi nei capitoli precedenti. Tali caratteristiche hanno carattere obbligatorio eccetto quelle espressamente indicate
come migliorative e/o preferenziali:
ID | Requisito | Obbligatorio/ Migliorativo/ Preferenziale |
T1 | l’eventuale interazione con strumenti di office automation (tramite integrazione, off-line su file prodotti dal servizio, etc.) non deve essere limitata a strumenti proprietari quali, a titolo esemplificativo ma non esaustivo, Microsoft Office, ma deve essere effettuabile con strumenti di office automation di tipo open source; | Obbligatorio |
T2 | disponibilità di servizi on line a supporto dell’apprendimento e dell’uso del software (deve essere prevista una fase di addestramento nei confronti del personale medico ed infermieristico che lo utilizzerà). Esempio: 🌕 Video Tutorial in linea: ovvero piattaforme interattive e navigabili per imparare velocemente ad usare il software, con i problemi più frequenti risolti/descritti mediante appositi video; a tali piattaforme si deve poter accedere direttamente da menù dell’applicativo; 🌕 Forum: ovvero uno spazio virtuale dedicato agli operatori per lo scambio di esperienze, al confronto e alla discussione; 🌕 Help on line: ovvero un motore di ricerca per trovare le soluzioni nel Video Tutorial e nel Forum NB: Tutti questi strumenti devono essere mantenuti aggiornati alla versione corrente del software per tutta la durata del contratto con periodicità di rilascio non superiore a 6 mesi; | Obbligatorio |
T3 | gestione strutturata delle utenze e dei profili: il software in acquisizione dovrà possedere al suo interno funzionalità, utilizzabili solo dai profili di amministrazione, dedicate alla generazione e manutenzione delle utenze e dei profili di accesso alla procedura. Il gestionale deve essere integrato/integrabile, senza oneri aggiuntivi, con i sistemi aziendali di identity management. E’ responsabilità dell’aggiudicatario garantire che quanto offerto identifichi i soggetti accedenti tramite i servizi IdM stessi. Ogni soggetto accreditato, dopo essere stato riconosciuto come attivo, dovrà poter essere accreditato all’utilizzo di risorse/servizi tramite utilizzo di token (utente/password) piuttosto che certificati locali al soggetto accreditato (carta CNS) e/o centralizzati, da verificare tramite attributi IdM; il livello di accesso deve avvenire tramite profilazione degli utenti e consentire una visione gerarchica degli utenti con attribuzione agli stessi di livelli operativi diversi (consultazione, inserimento, modifica dati) e di fasi di lavoro (menù personalizzabili) configurabili ad opera degli “amministratori di sistema” con la possibilità di configurare i menù in modalità gerarchica con attribuzione agli operatori, sia per classi omogenee, che per il singolo utente; ; con la validazione della refertazione non dovrà essere più possibile apportare modifiche che non siano tracciabili sia nei contenuti sia nell’identificazione dell’utente che le ha apportate; | Obbligatorio |
T4 | la visualizzazione anagrafica e la relativa attività dovrà essere fruibile per classi di utenza, per utenti appartenenti ad una stessa struttura e per tutta l’utenza; | Obbligatorio |
T5 | disponibilità di un costruttore di modulistica individuale (consenso informato, comunicazioni, richiesta esami, ecc.) che consenta l’importazione di dati anagrafici all’interno di un documento tipo word che deve poter essere stampato istantaneamente per essere eventualmente firmato dall’utente o dall’operatore. Dovrà essere possibile registrare per ogni assistito la data di | Preferenziale |
ID | Requisito | Obbligatorio/ Migliorativo/ Preferenziale |
emissione dei moduli, il tipo di modulo e salvato (configurabile parametricamente) il documento prodotto. Il fornitore dovrà esplicitamente riportare in offerta tecnica la disponibilità ad integrarsi con sistemi informatici centralizzati di gestione del consenso del paziente di prossima acquisizione da parte delle XX.XX. destinatarie della fornitura; | ||
T6 | le visualizzazioni /stampe standard devono essere previste a menu; | Obbligatorio |
T7 | Sistema di messaggistica interna al software dedicata alla pubblicazione di news o alert redatti dall’amministratore dell’applicativo. Il meccanismo di messaggistica deve strutturarsi su due livelli gerarchici: ⚫ messaggi che richiedono la presa visione obbligatoria da parte dell’utente al momento dell’accesso (login) al gestionale; ⚫ messaggi che possono essere letti in differita e conservati in un’area apposita dell’applicativo e segnalati con un alert fino all’avvenuta lettura | Preferenziale |
T8 | Inoltro delle richieste di assistenza tecnica, da parte dell’operatore, mediante semplice selezione di un pulsante o di una voce di menù sempre disponibile nella barra dei pulsanti/menù a disposizione dell’utente. Una volta premuto il pulsante o selezionata la voce di menù, l’utente verrà invitato a compilare un form con le informazioni necessarie per inoltrare correttamente la segnalazione, che verrà trasmessa via mail all’HD. L’interfaccia utente dovrà anche consentire all’operatore di monitorare lo stato di avanzamento delle segnalazioni trasmesse. | Migliorativo |
Legenda:
Obbligatorio: requisito indispensabile pena l’esclusione
Preferenziale: requisito non indispensabile ma che qualifica positivamente una offerta rispetto ad un’altra Migliorativo: requisito non indispensabile che la commissione si riserva di valutare come proposta migliorativa
5.3 Recupero di dati storici dei laboratori di emodinamica
Incluso nel contratto è il recupero dei data base storici. Deve essere garantita la consultazione di documenti e immagini relativi alle procedure registrate con gli attuali sistemi negli anni solari precedenti alla data dell’effettiva attivazione del presente contratto di convenzione ad esclusione dei dati salvati su CD. Si specifica che deve essere effettuata l’importazione in formato digitale elaborabile.
I dati del database storico devono essere associati alla rispettiva anagrafica paziente secondo le linee guisa RFC 249. Nel caso in cui prima dell’attivazione dell’integrazione con anagrafe centrale, sia già presente una banca dati locale dei contatti che hanno avuto eventi clinici registrati, occorre ricondurre tali soggetti a quelli presenti su APC-MPI. Gli scenari di riferimento di un verticale che si vuole integrare con l’APC-MPI via rfc249, sono i seguenti:
1) Attivazione nuovo verticale con eventi sanitari provenienti da un altro dominio anagrafico
2) Attivazione nuovo verticale con eventi sanitari legati a più domini anagrafici
3) Migrazione del verticale con eventi sanitari all’interno del medesimo dominio anagrafico Per i citati scenari l’attività di allineamento iniziale consiste in:
• E’ cura e responsabilità del fornitore rimuovere le anagrafiche senza eventi clinici associati: le anagrafiche presenti che non hanno eventi clinici associati devono essere rimosse per ottemperare al principio di necessità previsto dal D.Lgs 196/2003
• sincronizzazione cataloghi: in primis per il catalogo storicizzato dei luoghi di nascita (recuperabili all’indirizzo xxxx://xxxxxx-xx.xxxxx.xxxxxxx.xx/xxx/XxxxxxXxxxxxx) e poi per tutti gli altri cataloghi necessari per lo specifico dominio di interesse (professione, stato civile, etc.). L'introduzione di voci nei cataloghi diverse da quelle originali potrebbe richiedere una attività di analisi e aggiornamento delle anagrafiche locali che sarà a carico del fornitore;
• allineamento degli identificativi master:
o Estar esporrà al fornitore una vista sull’APC-MPI di riferimento nella quale saranno presenti le impronte che sono già sincronizzate RFC 248 con il loro ID_MASTER_AUR.
o I fornitori confronteranno massivamente solo per impronta completa (cognome, nome, genere, data nascita, istat comune/stato di nascita, codice fiscale) i soggetti della banca dati locale con quelli disponibili nella vista, per recuperare gli ID_MASTER_AUR dei soggetti coincidenti
o Le rimanenti posizioni complete e non con complete, dovranno essere inviate ad APCMPI come censimento e finiranno nel limbo. In questo modo si potrà recuperare la loro storia clinica una volta che le posizioni saranno riconciliate, oppure “promosse” alla circolarità se nel frattempo la loro impronta è stata certificata da Xxxxx;
Al fine di verificare la possibilità di allineamento delle anagrafiche con anagrafe regionale Orfea, Estar fornisce un apposito software per gestire il servizio di “Start-UP” Anagrafico Orfea-Loader.
MODALITA’ ARCHIVIAZIONE | SISTEMA PRECEDENTE | ANNI DI UTILIZZO | |
USL TSE GROSSETO | SERVER LOCALE | CARDIOPLANET | Dal 2007 |
USL TSE AREZZO | SERVER LOCALE | CARDIO | Dal 2002 |
AOUS | SERVER LOCALE e PACS di reparto | SUITE-EXTENSA e versione precedente | Dal 2008 prestazioni 1600/anno |
Si richiede altresì che venga prodotta appropriata documentazione relativa al formato dei dati resi disponibili al termine del contratto per eventuale passaggio ad altro software.
5.4 Team di lavoro dell’aggiudicatario
Le Ditte concorrenti dovranno indicare in modo preciso ed esaustivo il team di lavoro che verrà dedicato alla realizzazione del progetto, con definizione della struttura gerarchica del gruppo in termini di referenti di management, referenti tecnici, referenti commerciali, etc.
In particolare, è richiesta la composizione dettagliata del team, in termini di:
• Definizione del Responsabile di Progetto con relativo specifico curriculum;
• Definizione del Responsabile commerciale di Area con relativo specifico curriculum;
• Numero personale dedicato al progetto con specifica funzionale;
• Profili professionali con relativi curricula che documentino esperienze precedenti, in Italia ed all’estero, nel settore di intervento specifico;
• Per ogni componente del team la quota di tempo e il tempo totale previsto in cui quel professionista è assegnato a questo progetto.
5.5 Pianificazione delle attività e tempistiche di avvio in produzione dei sistemi
Le Ditte concorrenti, in accordo con quanto definito nel presente Capitolato Tecnico, dovranno predisporre un piano di lavoro dettagliato ovvero un progetto esecutivo, accompagnato da un cronoprogramma entro il limite massimo di 120 (centoventi) giorni dall’avvio del contratto di adesione, relativo all’implementazione dei sistemi oggetto del presente lotto, che illustri le relazioni temporali e la concatenazione delle varie attività. Esso dovrà contenere la pianificazione tecnica, organizzativa e funzionale di dettaglio. Tale documento sarà parte integrante del progetto esecutivo concordato dalle strutture di progetto messe a disposizione da parte delle Aziende Sanitarie e dal Responsabile di Xxxxxxxx nominato dalla ditta aggiudicataria. Le attività di monitoraggio verranno, pertanto, effettuate sulla base di tale documento iniziale.
5.6 Consegna ed installazione del sistema
La consegna del software dovrà essere effettuata a cura ed a carico della Ditta aggiudicataria entro i seguenti tempi:
• la fornitura delle componenti obbligatorie entro e non oltre 180 (centoottanta) giorni solari dalla data di avvio del contratto di adesione
• la fornitura delle integrazioni indispensabili all’avvio (es. anagrafe, PACS, attrezzature sanitarie, firma digitale, ecc. Elenco definitivo da concordare tra le parti al momento dell’avvio del contratto di adesione) entro e non oltre 180 (centoottanta) giorni solari dalla data di avvio del contratto di adesione
• la fornitura delle rimanenti componenti accessorie entro e non oltre 365 (trecentosessantacinque) giorni solari dalla data di avvio del contratto di adesione
5.7 Requisiti Minimi Formazione e Affiancamento all’Avvio
La Ditta aggiudicataria dovrà provvedere alla formazione e all’addestramento del personale tecnico e sanitario utilizzatore delle componenti software oggetto di fornitura.
Dovrà essere previsto un corso di formazione specifico per ciascuna tipologia professionale, di durata adeguata. In analogia a quanto richiesto per i professionisti sanitari, dovrà essere proposto anche un corso di formazione adeguato per formare alcuni profili di amministratore di sistema in modo che possano gestire sia alcune attività di configurazione sia le future richieste di intervento di primo livello.
La ditta dovrà formare almeno un Amministratore di Sistema con prerogative operative adeguate al ruolo. Dovrà, altresì, essere prevista la formazione di tutor, specificamente individuati allo scopo dalle AASS/AO, che provvederanno, a loro volta, a supportare la ditta aggiudicataria nell’attività di affiancamento degli operatori all’avvio in produzione e all’ingresso in servizio di nuovi operatori. Tale attività di formazione dovrà essere ripetuta dalla ditta aggiudicataria a seguito di importanti aggiornamenti dei sistemi forniti.
La formazione dovrà essere necessariamente erogata entro l’avvio in produzione nell’ambito delle aziende sanitarie ed enti del SSRT per il personale coinvolto nell’utilizzo della piattaforma.
L’affiancamento all'avvio dovrà essere necessariamente erogato on site senza oneri aggiuntivi per un minimo di 5 gg per ogni presidio ospedaliero e per ogni reparto con localizzazione diversa all’interno dello stesso ospedale.
La ditta dovrà presentare in offerta un piano dettagliato della formazione del personale (secondo la struttura sopra proposta) completo di argomenti trattati, durata e figure professionali a cui è destinato il corso.
Allo scopo di dimensionare correttamente l’offerta formativa si riporta, nella tabella a pag. 12 “Dotazione organica del personale”, il numero di operatori ad oggi in servizio che si ritiene opportuno formare almeno nelle UUOO coinvolte nella fornitura, individuati secondo una suddivisione che si ritiene possa avere riscontri distinti sulla profilazione e, quindi, sulle relative permissioni sull’applicativo.
6. Offerta Tecnica - Predisposizione e Vincoli
Nel presente capitolo si riportano le indicazioni utili alla corretta predisposizione dell’offerta tecnica da parte dei concorrenti.
La presentazione dell’offerta tecnica dovrà chiaramente distinguere tra:
⚫ fase implementativa che include l’installazione, configurazione, recupero dati, realizzazione delle integrazioni nonché formazione e affiancamento all’avvio del sistema informatico a supporto delle attività delle AA SS e/o AA.OO del SSRT destinatarie del software oggetto di gara;
⚫ fase di supporto e manutenzione (da descrivere nel solo documento A) della piattaforma a partire dall’avvio in produzione e/o dal collaudo con esito positivo e per tutta la durata del contratto.
Al fine di agevolare i lavori della commissione giudicatrice, si richiede che l’offerta tecnica presentata sia strutturata come segue, descrivendo all’interno dei singoli documenti (o raccolta di essi) gli argomenti elencati:
Doc di riferimento | Rif. Capitolato Tecnico | Oggetto | Ambito di illustrazione |
DOCUMENTO A | Parag. 5.7 Capitolo 6 | Organizzazione dei servizi | ⚫ Organizzazione dei processi interni all'Azienda/ATI ⚫ Proposte (anche migliorative) sui servizi di assistenza e manutenzione ⚫ Procedure di sicurezza e riattivazione del sistema in seguito a incidente con indisponibilità dello stesso ⚫ Proposte sul piano di formazione (inclusa FAD) ⚫ Affiancamento all'avvio |
DOCUMENTO B | Parag. 2.1 Parag. 2.3 Parag. 4.2 Parag. 5.2 Requisito T1 Requisito T7 | Tecnologia e funzionalità del software | ⚫ Proposta tecnico-funzionale per il software ⚫ Caratteristiche di ergonomicità ⚫ Potenzialità di configurazione ⚫ Facilità di realizzazione delle integrazioni ⚫ Disponibilità di sistemi di alert/monitoraggio del corretto funzionamento del sistema che eventualmente implementino algoritmi predittivi dei principali guasti ⚫ Supporto funzionale volto alla semplificazione del flusso di lavoro degli operatori ⚫ Utilizzo di prodotti/licenze open source ⚫ Eventuali requisiti aggiuntivi per le workstation di refertazione |
DOCUMENTO C | Parag. 4.1.4 Parag. 5.1 Parag. 5.2 Requisito T6 | Sistemi di reporting | ⚫ Ampiezza e completezza delle funzioni di reporting ⚫ Flessibilità nella generazione di nuovi report ⚫ Flessibilità nella scelta dei filtri e configurabilità dei report offerti (informazioni e aggregazioni) ⚫ Ergonomicità di accesso e fruizione dei report |
Doc di riferimento | Rif. Capitolato Tecnico | Oggetto | Ambito di illustrazione |
⚫ Flessibilità nell'export dei dati | |||
DOCUMENTO D | Parag. 2.1 Parag. 2.3 Parag. 5.2 Parag. 5.4 Parag. 7.1 | Documentazione | ⚫ Compilazione dell’allegato 7 - "Scheda check di compliance sicurezza e privacy applicativi software" ⚫ Elenco delle installazioni nazionali, europee ed extra-europee relative al sistema offerto o sistemi similari ⚫ Documentazione per l'utente ⚫ Documentazione tecnica del software, con particolare riguardo all'architettura, ai linguaggi di sviluppo, alle librerie o agli standard utilizzati, al disegno del database, alla modalità di archiviazione documentale (filesystem, db, etc…), alla firma digitale, alla semplicità di accesso alle varie funzionalità (compreso reporting) ⚫ Caratteristiche di tutte le componenti hardware che dovranno essere messe a disposizione da Estar affinché sia garantito il corretto funzionamento del software ⚫ Elenco analitico di tutti i componenti ed eventuali accessori e/o moduli hardware e software offerti come migliorativi / opzionali inclusi nell’offerta ⚫ Disponibilità di servizi on line a supporto dell’apprendimento e dell’uso del software |
DOCUMENTO E | Parag. 5.1 Parag. 5.2 Requisito T3 | Portabilità della soluzione | ⚫ Modernità delle tecnologie ⚫ Grado di innovazione delle scelte architetturali ⚫ Garanzia della compatibilità con i vari browser ⚫ Modalità di tutela rispetto agli aggiornamenti di versione di SO/browser ⚫ Presenza di ambienti sviluppati in HTML5 ⚫ Compatibilità del software con dispositivi mobili ⚫ Capacità della soluzione proposta di funzionare con produttori e versioni diverse di OS, browser ⚫ Compatibilità con le più comuni suite di produttività aziendale ⚫ La distribuibilità della soluzione mediante ambienti di virtualizzazione applicativa ⚫ Integrazione degli ecosistemi applicativi in sistemi di dominio AD per la profilazione utenti ⚫ Modalità di autenticazione weak e strong |
DOCUMENTO F | Parag. 2.1 Capitolo 3 Parag. 4.3 Parag.4.4.12 Parag. 4.4.13 Parag. 5.3 Parag. 7.2 | Integrazioni e recupero dati | Proposta tecnico-funzionale in merito a: ⚫ Integrazioni ⚫ Infrastruttura di riferimento ⚫ Valutazione dei volumi delle immagini prodotte dalle apparecchiature diagnostiche e la relativa produttività (esami/anno) per il dimensionamento del sistema PACS aziendale ⚫ Lista dettagliata dei modelli delle apparecchiature diagnostiche collegabili, con particolare riferimento agli elenchi della dotazione strumentale presente nelle Aziende ⚫ Gestione delle utenze e tracciamento attività ⚫ Recupero dati incluse specifiche di dettaglio ⚫ Formato dei dati che saranno resi disponibili al termine del contratto |
Doc di riferimento | Rif. Capitolato Tecnico | Oggetto | Ambito di illustrazione |
⚫ Architettura SOA ⚫ Documentazione dei servizi di interoperabilità anche con le apparecchiature diagnostiche | |||
DOCUMENTO G | Parag. 5.4 Parag. 6.1 | Sviluppo del progetto | ⚫ Caratteristiche qualitative del PM ⚫ Composizione del team di progetto con personale adeguatamente preparato ⚫ Attinenza del Gantt e delle modalità di esecuzione in relazione a quanto descritto nella Procedura LIFECYCLE Management (Allegato 3) ⚫ Grado di copertura delle check list di collaudo |
DOCUMENTO H | Parag. 5.1 Parag. 5.2 | Migliorie e Roadmap | ⚫ Caratteristiche migliorative rispetto a quanto richiesto; ⚫ Roadmap di sviluppo del prodotto software per gli anni successivi |
L’offerta tecnica potrà essere ove necessario contestualizzata nella fase esecutiva dopo l’adesione a seconda delle esigenze dell’ente aderente; a tal fine e per tutti i dettagli sulle modalità di svolgimento dei progetti e per il ciclo di vita del software, si deve fare riferimento alle fasi 3, 4, 5 dell’Allegato 3 “Procedure Lifecycle Management”.
6.1 Fase di Implementazione - definizione dei vincoli
Nella predisposizione del Gantt relativo alle attività oggetto della fornitura il concorrente, dovrà rispettare i seguenti vincoli:
Codice Vincolo | Descrizione Vincolo | Gravità (ALTA/MEDIA/ BASSA) |
V1 | Avviamento della nuova piattaforma per ciascun Ente entro 6 mesi dall’avvio del contratto di adesione | ALTA |
V2 | Completamento della fornitura per ciascun Ente entro 12 mesi dall’avvio del contratto di adesione | ALTA |
V3 | Verifiche di conformità non esitate positivamente e che non impediscono l’avvio in uso del sistema, non risolte entro 30 gg dalla formalizzazione del DEC | MEDIA |
V4 | Mancata predisposizione di video tutorial, forum o help on line, entro il mese precedente l’avvio nel primo Ente | MEDIA |
V5 | Mancato aggiornamento semestrale dei video tutorial ed help on line | 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à” (Allegato 6), 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.
6.2 Fase di Supporto e Manutenzione (post-collaudo)
I dettagli per lo svolgimento della fase di Supporto e Manutenzione sono descritti nella Procedura Lifecycle Management (Allegato 3), per la quale si deve fare riferimento alle fasi 6 e 7, e nell’allegato 1.
Inoltre, facendo riferimento alle fasce orarie indicate nell’Allegato 1, si precisa che per questo software si intendono coperte le seguenti fasce:
Tutti i giorni della settimana dalle 00:00 alle 23:59 festivi compresi
365 gg H 24
H24
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.
Oltre al servizio di help desk e manutenzione ordinaria, normativa e correttiva, il contratto prevede la realizzazione di manutenzione evolutiva sulla piattaforma oggetto del bando. In merito ad essa si descrive la modalità di erogazione:
⚫ Manutenzione evolutiva standard da erogarsi a consumo mediante moduli MEV come da procedura ‘ALLEGATO 4 - PA 45 2018 REV02 SOFTWARE CHANGE REQUEST’ 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: Formazione aggiuntiva (ulteriore rispetto a quella richiesta nel paragrafo 5.4), servizio DBA a consumo, sviluppo software (gg in house), consulenza ed evoluzioni (gg on site) e supporto informatico.
Costituiscono parte integrante del presente capitolato i seguenti allegati:
7.1 Documenti contrattuali
Nella tabella sono riportati gli allegati standard contrattuali per Assistenza e Manutenzione Software e le procedure standard ESTAR a supporto del ciclo di vita del software:
ID | Documento | Descrizione Documento |
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 del contratto. 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 | Esempio calcolo SLA | Fornisce a solo titolo di esempio un report di calcolo degli SLA che l’Aggiudicatario dovrà produrre in allegato alle fatture periodiche. È possibile ovviamente produrre reportistica più ampia e si precisa che quanto contenuto nell’esempio è il livello minimo richiesto. |
All.3 | Procedura Lifecycle Management | La procedura definisce il ciclo di vita del software |
All.4 | 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 del contratto. 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.5 | Modulo per MEV | Modulo allegato ad All.4 da utilizzare per la definizione e quotazione delle attività di manutenzione evolutive (Change Request) |
All.6 | Procedura Verifiche di Conformità Procedure Software | La procedura definisce le modalità con cui verranno eseguite le fasi di verifiche di confermità 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. 6bis | Template Verifiche di Conformità Procedure Software | Modulo allegato ad All.6 da utilizzare per le verifiche di conformità procedure software |
All.7 | Privacy (Con scheda da compilare a cura di ciascun Concorrente) | 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 ad ogni concorrente. |
7.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
⚫ Anagrafe RFC249
⚫ ADT RFC -123
7.3 Allegati tecnologici da referenziare mediante link alla pagina web del sito di Regione Toscana
“Si ritengono parte integrante del presente capitolato i seguenti documenti di definizione delle RFC e dei Flussi Informativi pubblicati alle seguenti pagine Web di Regione Toscana:
❏ xxxx://xxx.xxxx.xxxxxxx.xx/xXxxxxxxxxx/xxxxxxx/xxxxxxXxxxxXXX
❏ xxxxx://xxx.xxxxxxx.xxxxxxx.xx/-/xxxxxx-xxxxxxxxxxx
facendo riferimento all’ultima release vigente alla data di pubblicazione del presente bando”.
Di seguito si riportano la definizione e la quantificazione delle penali che l’Ente si riserva di applicare oltre alle penali previste per il servizio di assistenza e manutenzione che sono già definite nell’Allegato 1 e salvo il risarcimento del maggior danno.
Rispetto ai vincoli descritti nel capitolo 6, di seguito sono indicate le relative penalità:
Codice Vincolo | Gravità | Importo e modalità di applicazione |
V1 | ALTA | Fino ad un massimo di 1000 euro/giorno per ogni giorno solare di ritardo rispetto al GANTT formalmente approvato dal DEC |
V2 | ALTA | Fino ad un massimo di 1000 euro/giorno per ogni giorno solare di ritardo rispetto al GANTT formalmente approvato dal DEC |
V3 | MEDIA | Fino ad un massimo di 500 euro/giorno per ogni giorno lavorativo di ritardo |
V4 | MEDIA | Fino ad un massimo di 200 euro/giorno per ogni giorno lavorativo di ritardo |
V5 | BASSA | Fino ad un massimo di 50 euro/giorno per ogni giorno lavorativo di ritardo |
Deve considerarsi inadempimento e/o ritardo anche il caso in cui il fornitore esegua le prestazioni contrattuali in modo solo parzialmente difforme dalle prescrizioni contenute nella documentazione di gara e nell'offerta presentata dallo stesso fornitore.