Viale F. Rodolfi n VICENZA COD. REGIONE 050 COD. U.L.SS. 006 COD.FISC. E P.IVA Documento tecnico OGGETTO DELLA FORNITURA...

Transcript

1 Documento tecnico OGGETTO DELLA FORNITURA...3 IN PARTICOLARE, LA DITTA DOVRÀ FORNIRE LE SEGUENTI COMPONENTI :... 3 PRINCIPI CLINICO FUNZIONALI DEL PROGETTO...3 DESCRIZIONE DELLE CARATTERISTICHE TECNICO FUNZIONALI DEL SISTEMA RICHIESTO...5 DESCRIZIONE DEL PROGETTO... 5 FUNZIONALITÀ GENERALI DEGLI APPLICATIVI... 5 CARATTERISTICHE FUNZIONALI DEGLI APPLICATIVI... 6 CARATTERISTICHE COMUNI ALLE COMPONENTI PROPOSTE... 6 INTEGRAZIONE DEI SOFTWARE PROPOSTI... 6 AMBIENTI DI TEST PER SVILUPPO E FORMAZIONE... 7 IDENTIFICAZIONE... 7 RIATTRIBUZIONE DI EPISODI DI CURA... 7 ACCOMPAGNATORI E TUTORI LEGALI... 7 CATALOGHI/DIZIONARI... 7 RICERCA FACILITATA... 8 ELEMENTI COMUNI NELLE STAMPE... 8 CARATTERISTICHE QUALITATIVE SULLE FUNZIONI E SULLE INTERFACCE... 8 PRONTO SOCCORSO... 9 ORDER ENTRY CONTINUITA' ASSISTENZIALE ENTERPRISE SERVICE BUS / MIDDLEWARE FLUSSO APS E CRUSCOTTO DI BI FIRMA DIGITALE E CREAZIONE REFERTI FIRMATI CARATTERISTICHE TECNOLOGICHE VIRTUALIZZAZIONE ADERENZA AGLI STANDARD INFORMATICI AZIENDALI BASE DATI UNICA SICUREZZA AUTENTICAZIONE E PRIVILEGI AUDIT SISTEMA DI MONITORAGGIO DEI SERVIZI BLOCCO E SBLOCCO SESSIONE ACCESSIBILITÀ E PERSONALIZZAZIONI ACCESSO AGLI APPLICATIVI VIA WEB HTTPS GESTIONE AUTONOMA DELLE CONFIGURAZIONI E DELLE STAMPE(CRI_v1.18) INTEROPERABILITA FRA SISTEMI INFORMATICI INTRODUZIONE INTEGRAZIONI TRA LE PARTI FORNITE SCHEMA DELLE INTEGRAZIONI ELENCO DEI SISTEMI DA INTEGRARE ANAGRAFE(MODIFICATO 1,18) GESTIONE DEI CONSENSI PRIVACY pag 1 di 34

2 INFRASTRUTTURA HARDWARE BUSINESS CONTINUITY E DISASTER RECOVERY POSTAZIONI DI LAVORO POSTAZIONE DI EMERGENZA INFRASTRUTTURA SERVER INFRASTRUTTURA DI RETE LICENZE ACCESSORIE FORMAZIONE DEL PERSONALE AFFIANCAMENTO DEL PERSONALE E AVVIAMENTO DEL SISTEMA SERVIZI DI ASSISTENZA TECNICA E MANUTENZIONE DEL SISTEMA TEMPI DI INTERVENTO (SLA) E METRICA DI RENDICONTAZIONE DEL SERVIZIO DI ASSISTENZA TECNICA E MANUTENZIONE MODALITÀ DI RENDICONTAZIONE SERVIZIO DI GESTIONE DEL SISTEMA SERVIZI OGGETTO DI GESTIONE SERVIZIO DI SU HELP DESK DI I E II LIVELLO SLA PRESTAZIONE DI SERVIZIO REGOLARE E PENALITÀ RENDICONTAZIONE DEL SERVIZIO PRESIDIO ON-SITE MANUALISTICA RECUPERO E PORTING DEI DATI STORICI pag 2 di 34

3 OGGETTO DELLA FORNITURA Il presente appalto prevede la fornitura di un sistema informativo/informatico (hardware, software e servizi), con relativa assistenza e gestione, a supporto dei servizi di Pronto Soccorso e Continuità Assistenziali delle 4 Ulss della Provincia di Vicenza. In particolare, la ditta dovrà fornire le seguenti componenti : 1) applicativi e relative licenze per la gestione: del Pronto soccorso e dell OBI (PS); dell Order Entry (OE) anche per processi sovra aziendali; della Continuità Assistenziale (CA); dei processi di cooperazione applicativa (Enterprise Service Bus ESB) 2) componenti hardware: server fisici; postazioni di lavoro; 3) connettività: infrastruttura di rete e connettività necessaria per garantire i livelli di servizio, il Disaster Recovery e la Business Continuity; 4) licenze accessorie: tutte le licenze accessorie necessarie al loro regolare funzionamento, indipendentemente dal numero di postazioni di lavoro, dal numero di utenti o dal numero di transazioni gestite (o da qualsiasi altra metrica di licensing); 5) servizi: formazione al personale medico e di comparto; assistenza tecnica e manutenzione; gestione (Help Desk di I e II livello); presidio on-site; reperibilità h24 (notturni e festivi); Inoltre la ditta dovrà garantire il recupero delle informazioni pregresse e l integrazione con i sistemi informativi aziendali, regionali e nazionali al fine di rendere funzionale il sistema informatico proposto. PRINCIPI CLINICO FUNZIONALI DEL PROGETTO Il sistema informativo/informatico fornito dovrà implementare i seguenti principi: 1. Il sistema informativo deve raccogliere e rappresentare agli operatori le informazioni utili e necessarie alle decisioni clinico-assistenziali da assumere, dove e quando serve: pag 3 di 34

4 a. Sia informazioni prettamente socio-sanitarie/assistenziali (medico-infermieristiche, allergie, alert, segni e sintomi, sociali etc.) ; b. Sia informazioni relative alla disponibilità reale delle risorse (es: posti letto liberi nei vari setting assistenziali, carichi assistenziali in essere nelle diverse aree/moduli, visite/consulenze specialistiche disponibili, prescrizione esami, liste di attesa per ricoveri ed altre informazioni utili per programmare la degenza già durante la visita specialistica ambulatoriale o di PS); 2. Il sistema informativo deve costituire l evidenza documentata della appropriatezza delle prestazioni erogate (accountability del processo) e perciò: a. Deve connotare, quantificare, dare evidenza dei bisogni rilevati e assegnare ad essi una priorità (dove possibile ciò deve avvenire in modo strutturato, attraverso l uso di schede, scale e punteggi che rendano il più possibile oggettive le rilevazioni); b. Deve collegare ogni singolo bisogno rilevato alla modalità e alla cronologia della risposta, sulla base delle risorse realmente disponibili nella filiera produttiva, al fine di mettere in condizioni gli operatori di prendere decisioni finite, (poiché ritornare sulle decisioni provoca sempre il consumo di ulteriori risorse e deve essere perciò evitato); 3. Il sistema informativo deve realizzare il supporto alla programmazione delle attività operative nelle fasi di pianificazione, attuazione e valutazione delle azioni assistenziali; deve quindi strutturare e rendere disponibili i piani assistenziali (diagnostico-terapeutico-riabilitativi) articolandoli per paziente, per attività, per competenza e profilo professionale; 4. Il sistema informativo deve essere il principale strumento di comunicazione tra i diversi professionisti coinvolti nei PDTA e perciò deve: a. Evolvere dalla medicina narrata e raccontata verso una medicina evidenziata e rappresentata al fine rendere chiara e consistente la comunicazione stessa, risolvendo ogni possibile ambiguità; b. Facilitare l integrazione tra gli operatori che intervengono nei processi di prevenzione, diagnosi, cura e riabilitazione favorendo il rapporto multi professionale, multi settoriale, multi specialistico; c. Garantire la continuità delle cure in modo trasversale rispetto ai diversi professionisti e alle diverse unità operative che sono intervenute sul caso, nella consapevolezza che oramai i processi complessi si dipanano a scavalco tra le diverse organizzazioni: unità operative (ambulatori, degenze, ADI etc.), macro aree (prevenzione,ospedale,territorio) e aziende (ad esempio modelli hub&spoke). E chiaro quindi che il modello di trust tra gli operatori non può più essere quello gerarchico ma il fidati di me è garantito dall evidenza documentata dal chi-a-fatto-che-cosa-quando-e-perché, sia nella fasi di rilevazione dei bisogni, sia nelle fasi decisionali; 5. Il sistema informativo aziendale è l unica fonte dati con la quale l azienda costituisce il Dossier Sanitario del cittadino ed è quindi la fonte con cui partecipa alla costruzione del Fascicolo Sanitario Elettronico Regionale e Nazionale del cittadino; deve essere in grado di gestire un enorme mole di informazioni e quindi: a. deve considerare le informazioni alla stregua di un dispositivo medico o di un processo certificato, in quanto sono un elemento fondamentale del processo assistenziale; b. deve rispondere ai principi del technology assessment, per poter procedere così alla sua valutazione e legittimazione (al pari delle grandi tecnologie, dei farmaci e dei dispositivi); c. deve essere in grado di filtrare e sintetizzare le informazioni strutturate in esso contenute, a seconda dei diversi contesti di utilizzo; 6. Il sistema informativo deve relazionare le risorse al bisogno, il bisogno al paziente e alla sua patologia; tale catena consente al sistema informativo di realizzare il cost-accounting; ciò consente di compiere analisi più accurate e puntuali (contabilità e benchmarking sui processi) e di istaurare una maggior consistenza tra le attività di programmazione aziendale ed i processi produttivi, rendendo così coerente il processo di budget; pag 4 di 34

5 7. Il sistema informativo, come sottoprodotto rispetto alle attività di supporto alla prevenzione, diagnosi e cura, deve garantire il supporto anche a: a. Studi scientifici, ricerca, formazione, aggiornamento; b. Valutazione delle attività sanitarie (VRQ, audit clinici, etc.) c. Produzione dei flussi amministrativi regionali e nazionali (NSIS); 8. Il sistema informativo deve supportare il processo di risk management; deve concorrere alla protezione legale dei pazienti, degli operatori e dell azienda, attraverso la tracciabilità di tutte le attività svolte, per individuare i responsabili, la cronologia dei fatti e degli episodi e le modalità di esecuzione; DESCRIZIONE DELLE CARATTERISTICHE TECNICO FUNZIONALI DEL SISTEMA RICHIESTO DESCRIZIONE DEL PROGETTO Con la presente procedura di gara le Ulss della provincia di Vicenza intendono uniformare le soluzioni software atte a gestire il pronto soccorso e il servizio di continuità assistenziale. Inoltre intendono dotarsi di uno strato applicativo per la gestione dell order entry. A tal fine si ritiene utile, al fine di garantire una gestione razionale e strutturata dei processi di cooperazione applicativa oggetto di questa gara, che venga fornito un sistema di ESB. I sistemi si dovranno integrare in ogni singola azienda con i seguenti sistemi: servizio di autenticazione: IAP (standard definiti nell ambito delle attività della DGRV 1671/2012), Active directory, altri LDAP server; servizi di identificazione anagrafica (standard definiti nell ambito delle attività della DGRV 1671/2012); applicativi terzi L installazione dei sistemi forniti deve avvenire su un istanza unica. L infrastruttura di data center deve essere comune e deve implementare i servizi di business continuity e di disaster recovery (almeno soluzione di classe Tier 3, con riferimento alle linee guida DR dell AgID). FUNZIONALITÀ GENERALI DEGLI APPLICATIVI La suite fornita deve garantire le seguenti funzionalità: Gestione del Pronto soccorso; Gestione della continuità assistenziale; Gestione dell order entry; il modulo deve poter funzionare anche per la gestione dei processi sovra aziendali; il modulo deve integrare le specifiche per la prescrizione de materializzata; Gestione dei processi di cooperazione applicativa; Saranno valutate qualitativamente le soluzioni dando maggior punteggio a quelle che siano: più esaustive nella gestione delle parametrizzazioni, più performanti per l'operatività, più intuitive e facilmente utilizzabili per gli operatori. Tutto quanto afferisce a questo paragrafo viene considerato ai fini della valutazione qualitativa. pag 5 di 34

6 Per ogni modulo in fornitura devono inoltre essere garantite le seguenti caratteristiche L accesso al dato deve avvenire nel rispetto del codice della privacy, tenuto conto che nel progetto sono interessati 4 titolari del trattamento diversi; l autenticazione deve essere implementata integrandosi con i sistemi di ogni singola ULSS; la possibilità di interrogare il sistema informativo a scopo statistico o di estrazione dati in modo il più possibile flessibile e personalizzabile in autonomia dal personale ospedaliero, senza che vi sia la necessità di competenze sistemistiche o di apprendimento di linguaggi o meta linguaggi informatici; La suite fornita dovrà facilitare la dematerializzazione della documentazione cartacea nei percorsi interessati (ospedalieri, amministrativi e territoriali); I privilegi utente dovranno essere impostabili sui singoli utenti e su raggruppamenti di utenti, anche legati ai ruoli; L accesso agli applicativi deve essere possibile da qualsiasi postazione delle aziende ULSS; Non ci deve esser alcuna profilazione funzionale (o restrizione) relativa ai client Per ogni singola ULSS la gestione delle anagrafiche dei pazienti deve essere, per tutti i moduli forniti, il più possibile conforme alle politiche aziendali ivi comprese le funzioni di ricerca paziente e merge; Il fornitore deve proporre soluzioni nel rispetto del Codice dell Amministrazione Digitale D.Lgs. 7 marzo 2005, n. 82, pubblicato in G.U. del 16 maggio 2005, n S.O. n. 93 Codice dell'amministrazione digitale, aggiornato dal D.Lgs. n. 159 del 4 aprile 2006 pubblicato in G.U. del 29 aprile 2006, n. 99 S.O. n. 105 "Disposizioni integrative e correttive al decreto legislativo 7 marzo 2005, n. 82 recante codice dell'amministrazione digitale" e successive integrazione e modificazioni. Tutte le soluzioni offerte devono essere multipiattaforma, sia rispetto ai sistemi operativi che all hardware. CARATTERISTICHE FUNZIONALI DEGLI APPLICATIVI Il presente paragrafo si divide in: Caratteristiche comuni alle componenti proposte; definizione di funzionalità proprie dei singoli moduli software, caratteristiche tecnologiche richieste al sistema in fornitura. CARATTERISTICHE COMUNI ALLE COMPONENTI PROPOSTE INTEGRAZIONE DEI SOFTWARE PROPOSTI I moduli software offerti dovranno essere tra loro del tutto integrati; si dovrà poter passare da un modulo all altro senza dover reinserire dati già immessi, come per esempio l anagrafica di un paziente, il contesto di cura o le credenziali di accesso. Le basi dati di tipo dizionario dovranno essere comuni (o centralizzate) a tutte le parti in fornitura senza alcuna duplicazione. Il fornitore deve in ogni caso garantire che qualunque attività eseguibile sui pag 6 di 34

7 dizionari (inserimenti, modifiche, cancellazioni) possa esser operata centralmente e impattare su tutta la suite senza dover esser ripetuta manualmente. Non ci dovranno essere sistemi differenti di profilazione utente. AMBIENTI DI TEST PER SVILUPPO E FORMAZIONE La ditta offerente dovrà tener conto delle esigenze formative in uno o più ambienti differenti da quello di produzione, a seconda delle necessità. Uno degli ambienti di test dovrà essere utilizzabile anche come ambiente di pre production test. IDENTIFICAZIONE Le informazioni trattate da tutti i moduli in fornitura devono consentire una identificazione univoca: del cittadino, dei medici prescrittori, delle prestazioni, delle unità operative erogatrici, degli utenti del sistema informativo aziendale. Deve essere consentita l identificazione del cittadino attraverso vari criteri di ricerca, adoperati congiuntamente o distintamente, quali la lettura del numero di tessera sanitaria, del codice fiscale o la ricerca tramite l'immissione dei dati anagrafici, parziali o completi. RIATTRIBUZIONE DI EPISODI DI CURA Per gestire il caso in cui vi sia stato uno scambio di identità di pazienti, i sistemi devono permettere la riattribuzione degli episodi di cura, in blocco o singolarmente, per i pazienti interessati. ACCOMPAGNATORI E TUTORI LEGALI Tutti i sistemi in fornitura devono prevedere la possibilità di annotare chi siano gli l eventuali accompagnatori dei pazienti al fine delle comunicazioni in merito allo stato clinico. Deve inoltre essere gestibile la figura del tutore legale per i minori e gli incapaci di intendere e volere. Tale dato deve essere obbligatorio per i minori. La compilazione, sull anagrafica del paziente (per il tutore), di tale dato deve generare un allarme per gli operatori che prendano li prendano in carico. CATALOGHI/DIZIONARI Si definiscono "Cataloghi", "Dizionari" o Terminologie tutti gli elenchi che compongono le informazioni codificate utilizzabili dagli applicativi in fornitura ovvero tutte gli elenchi cui gli utenti fanno riferimento nei campi a "lista di valori" e dei quali, al fine di chiarire il concetto, si riporta più avanti una lista non completa. Nel dettaglio dovranno esser gestiti almeno i seguenti cataloghi: Comuni e stati esteri; Aziende sanitarie e relazione aziende / comuni; Prestazioni: Catalogo Veneto delle prestazioni erogabili e relativo tariffario; Nomenclatore e tariffario nazionale (per le prestazioni extra CVP) pag 7 di 34

8 Ulteriori Listini: LP, convenzionati, Medicina Pubblica, Veterinari, etc. Elenco regionale e nazionale esenzioni; Correlazione tra esenzioni e prestazioni; Correlazione tra esenzioni e regimi; Strutture erogatrici; Agende; Regimi di erogazione e posizione utenti; Medici Prescrittori Interni e Medici erogatori; Catalogo delle convenzioni Elenco delle sedi operative; Elenco degli Uffici/Reparti; Codifiche anagrafiche (stati civili, professioni, etc.) Diagnosi e procedure ICD9-CM Prontuario Farmaceutico aziendale/nazionale. In particolare per il Catalogo Veneto del Prescrivibile, che declina il nomenclatore-tariffario regionale sul dettaglio delle prestazioni erogabili, sarà possibile proporre una soluzione software che abbia una gestione del passaggio da una versione all'altra il meno onerosa possibile per le aziende sanitarie (più in generale il principio deve valere per tutti i cataloghi). Il sistema dovrà gestire e mettere a fattore comune tutti i cataloghi delle 4 aziende. RICERCA FACILITATA Sarà possibile per il concorrente proporre l autocompilazione dinamica durante la digitazione, con tecnologia ajax, dei controlli caselle combinate o caselle di testo che emulano caselle combinate (esempio ricerche google-like). ELEMENTI COMUNI NELLE STAMPE Tutte le stampe che siano prodotte ad uso dei cittadini dovranno essere provviste di barcode che le rendano immediatamente fruibili ad altre parti dei sistemi informativi (Es. casse automatiche). In particolare il codice fiscale dovrà essere sempre stampato in formato barcode così come l'idaccesso/idepisodio, ovvero quei codici che fungono da chiave nelle integrazioni. CARATTERISTICHE QUALITATIVE SULLE FUNZIONI E SULLE INTERFACCE L interfaccia operatore/applicativo deve essere user friendly, uniforme, semplice e immediata, conforme agli standard di interfaccia grafica e web browser previsti dai principali applicativi di mercato. In particolare, il significato associato alle varie icone ed ai messaggi deve essere sempre il medesimo all interno di tutto l applicativo. I passaggi più critici devono essere opportunamente segnalati all utente e le funzioni disponibili devono essere differenziate a seconda dell utente collegato. Il sistema deve inoltre fornire un percorso logico da seguire evidenziando i passi obbligatori ed implementando opportuni meccanismi di controllo in fase di editing del dato. pag 8 di 34

9 La procedura deve: consentire l'utilizzo di lettori barcode; prevedere un accesso rapido a dati anagrafici e tabelle, ricerca veloce di codici: la procedura deve consentire un accesso rapido e "trasparente" alle tabelle e alle anagrafiche di base (compatibilmente con i privilegi assegnati ad un utente); proporre automaticamente valori di default quali le date, gli orari, i codici da utilizzare per operazioni di selezione, i valori più frequenti nel caso di operazioni di inserimento/modifica dati, laddove pertinente ed utile per un più rapido impiego dell'interfaccia, proponendo valori predefiniti sia di tipo generale, sia in base all utente collegato; proporre automaticamente come valori di default quei valori ricavabili dal contesto operativo, ad esempio proporre ove pertinente il codice identificativo dell'ultimo paziente rispetto a cui sia stata compiuta qualche operazione, oppure il codice identificativo dell'unità operativa a cui è associato l'operatore della procedura; permettere di definire glossari testuali, ovvero utilizzare testi precodificati che facilitino la compilazione di campi di tipo Testo/Memo; la possibilità di innescare funzionalità di posta elettronica direttamente dall applicazione. PRONTO SOCCORSO Tale modulo deve supportare il processo di diagnosi e cura tipico degli accessi di pronto soccorso per il tramite delle opportune funzionalità sotto riportate. La lista non intende essere esaustiva o limitante. Configurazione e gestione multi aziendale / multi sito; Configurazione e gestione degli ambulatori; Gestione dei pronti soccorsi di pediatria, ostetricia/ginecologia, psichiatria e oculistica; Gestione dei trasferimenti da/verso gli altri siti/aziende gestiti; Gestione del triage, Accettazione, Stampa del bracciale identificativo, Integrazione con i monitor di sala d attesa, Gestione degli esame obiettivo, Gestione delle prestazioni erogate, Gestione delle terapie farmacologiche: o deve essere possibile la gestione della prescrizione, a cura del personale medico, e della sottoscrizione della somministrazione a cura del personale infermieristico, o devono essere gestiti il dettaglio delle dosi, della posologia (compresa la modalità al bisogno ), del tipo farmacologico, dell unità di misura, della via di somministrazione etc. o devono essere gestite le infusioni: quantità, velocità di infusione, ripetizione, etc rilevazione dei parametri vitali e fisiologici (grafica): o la rilevazione deve essere correlabile alle somministrazioni in modo da dare evidenza dell andamento del paziente, richiesta di esami diagnostici e visite specialistiche ad altre unità operative (per mezzo dell order entry) Rilevazione delle schede cliniche del dolore; pag 9 di 34

10 Configurazione nuove schede clinico/assistenziali e rilascio in produzione delle stesse senza fermi della procedura; Ipotesi diagnostiche Diario unico (e filtrabile) per ogni tipologia di operatore coinvolto; Diagnosi, Conclusioni, Indicazioni terapeutiche a domicilio (strutturate e non), Comunicazioni al medico curante, Prognosi, Gestione dei pazienti in Osservazione Breve Intensiva o Temporanea: o il sistema, in base alla durata discriminerà automaticamente tra le due e nel casi si tratti di OBI provvederà a considerarla ai fini amministrativi, o devono essere gestiti i posti letto di OBI Passaggi di consegne: o il passaggio di consegne conferisce agli operatori subentranti la presa in carico del paziente, o il passaggio può essere eseguito sull intero blocco di pazienti in visita o in attesa (cambio turno) oppure può riguardare insiemi di pazienti selezionabili, Agenda di ps: finalizzata alla gestione dei controlli INAIL o alle rivalutazioni e le medicazioni, etc. Gestione di quanto previsto dalla DGR 74/2014 e dalla DGR 909/2014, Chiusura caso con gestione di o ricovero, in integrazione con l ADT o dimissione, o trasferimento, o etc.. Integrazione con l infrastruttura di registry/repository (sia per la consultazione che per l alimentazione), Completa tracciabilità ( chi-quando-cosa ) di tutte le operazioni eseguite nell ambito dell episodio Produzione del verbale in XML CDA2 e apposizione della firma digitale, con inserimento di tutte i dati rilevati durante l episodio ed i riferimenti a tutte le richieste e a tutti i documenti clinici ottenuti in risposta dalle altre unità operative coinvolte nel percorso di diagnosi e cura; ORDER ENTRY E richiesta la fornitura di un sistema atto a gestire il ciclo completo di richiesta-risposta per prestazioni specialistiche e consulenze interne, anche sovra aziendali. L Order Entry: Deve poter essere attivato con le seguenti tre modalità: 1. gestione via web services di tutto il ciclo richiesta-risposta; 2. gestione attraverso un applicazione web di tutto il ciclo richiesta-risposta; 3. gestione del ciclo richiesta-risposta attraverso un mix delle modalità 1 e 2; Deve essere integrato con l ADT e con il CUP; Deve poter svolgere, in senso IHE, sia i compiti di Order Placer (invio ordini) che i compiti di Order Filler (allocazione degli ordini negli slot liberi); pag 10 di 34

11 Deve permettere la redazione del quesito diagnostico (testo libero o specifica form configurabile e strutturata) e delle prestazioni richieste (anche per pacchetti di prestazioni); Deve permettere la firma digitale delle richieste; Deve poter esser invocato da parte di altri software con passaggio dei parametri di contesto (operatore, paziente e regime di assistenza) e senza necessità di ri-autenticazione; Deve dare evidenza dei risultati via via che vengono prodotti (anche prima che il referto sia completo e/o firmato), nei contesti in cui è richiesto; Deve gestire la funzione di stampa etichette per i campioni prelevati, ove necessario; Deve consentire la redazione e la firma digitale dei referti, attraverso l uso di form configurabili e strutturate (integrandosi con i repository/registry aziendali); Deve integrarsi via WS o attraverso viewer web all infrastruttura registry/repository delle aziende; Deve integrarsi con la funzionalità di prescrizione elettronica di ogni singola ULSS secondo le specifiche sviluppate all interno delle attività previste dalla DGRV 1671/2012. L order entry dovrà gestire tutti i processi di cooperazione tra software dipartimentali di diverse Unità Operative, anche tra quelle collocate nelle diverse ULSS (es:richiesta di consulto tra due aziende); all atto della richiesta, oltre ad inserire un dataset strutturato a corredo, deve essere possibile selezionare specifici dati o referenziare determinati documenti clinici riferiti al paziente al fine di porli in evidenza alla Unità Operativa erogante (la selezione deve poter riguardare tutti i documenti che afferiscono all insieme di uno o più episodi di cura, compreso o meno quello corrente, oppure l insieme di uno o più documenti indipendentemente dall episodio di cura in cui sono stati generati); CONTINUITA' ASSISTENZIALE Tale modulo deve supportare il processo di diagnosi e cura tipico degli accessi dei cittadini al servizio di continuità assistenziale, per il tramite delle opportune funzionalità sotto riportate. La lista non intende essere esaustiva o limitante. Configurazione e gestione multi aziendale / multi sito; Configurazione e gestione degli ambulatori; Accettazione, Anamnesi / Rilevazione condizioni cliniche Configurazione nuove schede clinico/assistenziali e rilascio in produzione delle stesse senza fermi della procedura; Diagnosi, Conclusioni, Indicazioni terapeutiche a domicilio (strutturate e non), Prescrizioni farmaceutiche in caso di terapia non differibile (mediante integrazione con il modulo di e-prescription aziendale); Compilazione dei certificati di malattia ( per i soli turnisti, in servizio la notte e nei giorni festivi; il certificato è rilasciato limitatamente ai giorni di festività - 1, 2, al massimo 3); Comunicazioni al medico curante, Chiusura caso con inserimento dell esito strutturato e gestione del: o Attivazione del servizio 118; o Invio al Pronto Soccorso; pag 11 di 34

12 o Costatazione di decesso; Integrazione con l infrastruttura di registry/repository (sia per la consultazione che per l alimentazione), Completa tracciabilità ( chi-quando-cosa ) di tutte le operazioni eseguite nell ambito dell episodio Produzione del modulo M (distinguendo il per consulto telefonico dall accesso domiciliare) in XML CDA2 e apposizione della firma digitale, con inserimento di tutte i dati rilevati durante l episodio ed i riferimenti a tutte le richieste e a tutti i documenti clinici ottenuti in risposta dalle altre unità operative coinvolte nel percorso di diagnosi e cura; ENTERPRISE SERVICE BUS / MIDDLEWARE Un Enterprise Service Bus (ESB) è un'infrastruttura tecnologica che rimuove qualsiasi collegamento diretto tra il consumer ed il provider di un servizio telematico. I consumer si collegano al bus e non al provider che effettivamente implementa il servizio. In questo modo da un lato si disaccoppia in modo forte il consumer dal provider per il servizio specificatamente richiesto e dall altro si concentra nel bus l implementazione dei servizi di log, di audit, di routing, di sicurezza, di garanzia di consegna, di trasformazione e di integrazione che diversamente bisognerebbe far implementare ogni volta alla coppia consumer/provider. L implementazione e la gestione comuni dei servizi del bus contribuisce ad aumentare la sicurezza, la flessibilità e la gestibilità di un architettura SOA, evitando la ripetizione di investimenti importanti. Il Modello architetturale di riferimento, evitando integrazioni point-to-point, diventa così di tipo Hub & Spoke. Data la complessità entro la quale i software oggetto della fornitura andranno ad operare, ovvero la necessità all'interno della stessa installazione di integrarsi con applicativi di aziende sanitarie diverse, tutti i processi di integrazione necessari al buon funzionamento del sistema offerto, devono essere gestiti dal ESB. In tal senso è richiesta la fornitura di: un ESB con le caratteristiche tecniche più avanti riportate, compresa l installazione, la configurazione, la fornitura, se necessaria, di tutte le licenze utili alla gestione dell intero periodo contrattuale, indipendentemente dal numero di utenti o transazioni gestite o dall incremento nel tempo del carico; L RDBMS su cui deve appoggiare l ESB, compresa l installazione, la configurazione, la fornitura, se necessaria, di tutte le licenze utili alla gestione dell intero periodo contrattuale, indipendentemente dal numero di utenti o transazioni gestite o dall incremento nel tempo del carico; pag 12 di 34

13 L ESB deve comprendere e garantire le seguenti caratteristiche/funzionalità: 1. deve garantire elevate performance e scalabilità; 2. deve essere configurato in alta affidabilità ed la messa in produzione di nuove funzionalità, processi, metodi ed operazioni deve avvenire con rilasci a caldo; 3. deve essere multipiattaforma rispetto all hardware e al sistema operativo (windows, unix, linux, AIX, etc.) 4. la messaggistica deve supportare i principali standard di settore, tra cui SOAP, WSDL, XML, REST; 5. deve processare, consentire o rifiutare gli allegati alla messaggistica (MIME, DIME, MTOM) 6. deve supportare la gestione publish / subscribe ed event driven; 7. deve garantire le attività di routing basandosi sia sugli standard internazionali di instradamento (ws:addressing e simili) che sul contenuto dei messaggi; 8. deve offrire i servizi di test per validare le diverse componenti delle interfacce; 9. deve fornire la persistenza di tutti i messaggi e dei processi attraverso la presenza di un RDBMS quale parte integrante dell offerta; 10. deve gestire un motore di regole (Business Rules Engine, BRE) estensibile ed utilizzabile in modo efficace anche da non programmatori; 11. deve garantire il log e la tracciabilità di tutte le operazioni e messaggi gestiti; in particolare deve avere un interfaccia grafica per il log, il monitoraggio la tracciabilità dei messaggi (Business Activity Monitoring, BAM), il loro recupero, la loro visualizzazione, l eventuale modifica ed re-inoltro nel processo, sia in fase di sviluppo (per operazioni di debug), sia in produzione; deve essere inoltre possibile monitorare i livelli di servizio (Service Level Monitoring, SLM) e gli indicatori chiave di performance per ogni servizio/metodo esposto/proxato anche attraverso cruscotti grafici integrati; 12. deve avere un motore per la gestione di Business Process (Business Process Management, BMP) che supporti; a. l orchestrazione dei processi di business; b. la possibilità per gli sviluppatori di definire la logica di business attraverso la modellazione grafica o documenti strutturati XML o attraverso la scrittura di codice, combinando questi strumenti per affrontare efficacemente la più ampia gamma di esigenze; c. l integrazione con il BRE in modo da poter modificare il comportamento dei processi gestiti lavorando sulle regole e non sul codice; d. la separazione delle regole dalla logica di business in modo da poterle riutilizzare facilmente; e. la gestione sia di workflow automatizzati che di human workflow, mixandoli con trasparenza quando occorre; f. l integrazione con il BAM ai fini di monitorare l'attività e lo stato dei singoli processi aziendali e dell'intero sistema; 13. deve essere gestito il versioning per i servizi ed i processi resi disponibili attraverso l ESB; 14. deve garantire che i messaggi vengano processati ed instradati nella sequenza stabilita dal mittente (sequencing); pag 13 di 34

14 15. deve supportare i formati di messaggistica standard in sanità, tra cui HL7, DICOM, ASTM; 16. in particolare la messaggistica HL7 oltre ad essere integrata con tutte le altre funzionalità e caratteristiche esposte, deve garantire la documentazione ed il supporto nativo per le versioni 2.X e 3; 17. deve supportare i profili IHE: a. Cross-Enterprise Clinical Documents Share (XDS.b) b. Audit Trail and Node Authentication c. Cross Enterprise User Assertion (XUA) d. Scheduled Workflow (SWF) e. Patient Identity Reconciliation (PIR) f. Patient identifier Cross-Reference (PIX) g. Patient Demographics Query (PDQ) h. Patient Administration Management (PAM) i. Laboratory testing Workflow (LTW) j. Anatomic Pathology Workflow (APW) 18. deve supportare l estrazione di parametri, la trasformazione, l elaborazione di messaggi XML basata su interfacce visuali, su codice e/o su tecnologia XPath, XQuery, XSLT (extract & transform) 19. deve essere integrato in un ambiente di sviluppo object-oriented; 20. deve supportare transazioni sincrone ed asincrone; 21. deve essere possibile analizzare il traffico che passa attraverso l ESB per fornire servizi di business intelligence in tempo reale; 22. deve potersi integrare con tutte le versioni dei principali RDBMS (Oracle, Microsoft SQL Server, Postgres; MySQL, DB2, etc ); 23. deve gestire la profilazione degli utenti per ruoli e attributi (RBAC, ABAC); 24. deve supportare obbligatoriamente i seguenti standard specifici di settore: WS Security 1.1, WS Policy, WS Addressing, SAML2, LDAP, X.509, XML Signature, XML Encryption, SSL / TLS; 25. deve supportare tutti gli standard definiti all interno delle attività previste dalla DGRV 1671/2012 (standard DGRV 1671/2012); 26. sono inoltre considerati ulteriori standard rilevanti al fine della valutazione: WS Trust, XACML, PKI, WS Reliability, WS ReliableMessaging. Altri standard attinenti gli ambiti di dominio di questo capitolato verranno comunque vagliati e valutati. Sono ammesse soluzioni che mettono a disposizione della stazione appaltante strumenti di amministrazione visuali, semplici ed intuitivi. pag 14 di 34

15 FLUSSO APS E CRUSCOTTO DI BI Il sistema deve offrire la possibilità, senza appoggiarsi a programmi di terzi, di estrarre il flusso informativo obbligatorio APS, con la periodicità richiesta dalla Regione Veneto, riguardante l attività del pronto soccorso. Inoltre l offerta dovrà prevedere strumenti flessibili di estrazione dati e di "cruscotto aziendale" ovvero di ETL e Business Intelligence operante su tutti i contenuti informativi del sistema proposto. FIRMA DIGITALE E CREAZIONE REFERTI FIRMATI Il sistema proposto deve consentire di apporre la firma digitale ai documenti prodotti per tutti i moduli software, alimentando i repository aziendali, come descritto nel paragrafo sulle integrazioni. I formati di firma supportati devono essere: CAdES PAdES XML Signature (enveloped, enveloping, detached) CARATTERISTICHE TECNOLOGICHE I sistemi in fornitura devono disporre delle seguenti caratteristiche minime: VIRTUALIZZAZIONE Tutta l'infrastruttura lato server deve funzionare su infrastruttura virtuale. ADERENZA AGLI STANDARD INFORMATICI AZIENDALI La Ditta aggiudicataria deve garantire la perfetta compatibilità dei software forniti con l ambiente informatico aziendale, che deve essere rilevato dal fornitore in sede di sopralluogo. BASE DATI UNICA Tutti gli applicativi in fornitura dovranno poggiare su una base dati unica per tutte le parti e funzionalità del sistema stesso. SICUREZZA AUTENTICAZIONE E PRIVILEGI Il sistema dovrà permettere l'accesso nominale agli operatori secondo la normativa vigente. I privilegi legati all'utente dovranno essere impostabili in base a ruoli o ad attributi (sia ABAC che RBAC). In aderenza alla D.LGS 196/03, deve essere garantita dai moduli in fornitura la visibilità agli utenti autorizzati dei soli dati di propria competenza. I moduli applicativi destinati all'uso aziendale devono disporre di modalità di accesso sicuro ai dati attraverso l uso di identificativi utente e password (e metodi di autenticazione forte) e livelli differenziati di accesso. In particolare il sistema dovrà operare la verifica : delle credenziali secondo le policy aziendali, del contesto applicativo (secondo le specifiche sulla sicurezza nel progetto FSE-r), pag 15 di 34

16 del ruolo (secondo le specifiche sulla sicurezza nel progetto FSE-r) del reparto/servizio, degli ulteriori privilegi di accesso eventualmente slegati da quelli definiti da ruolo, reparto e contesto; La suite dovrà interfacciarsi al sistema di autenticazione aziendale Microsoft Active Directory per la verifica delle credenziali di accesso. Si accederà quindi al sistema per il solo tramite di credenziali di Active Directory. Gli utenti avranno accesso ai sistemi della suite fornita a condizione di esser membri di gruppi concordati di Active Directory. La suite si dovrà interfacciare all'identity and Assertion Provider SAML2 di ogni singola azienda secondo le specifiche regionali relative al progetto FSE-r. Sarà considerata migliorativa la condizione nella quale i sistemi riconoscano l'appartenenza a gruppi di AD anche quando nidificati. Il sistema dovrà mettere a disposizione diverse modalità di autenticazione. Dovrà essere possibile configurare tali modalità a seconda dell'azienda e del contesto presso cui l utente opera. AUDIT Le seguenti indicazioni si applicano a tutti gli applicativi oggetto di questa fornitura. Le eliminazioni di dati devono esser logiche e non fisiche. I dati logicamente eliminati non dovranno esser modificabili. Ogni componente del sistema in fornitura deve garantire la tracciabilità di ogni operazione (ricerca, visualizzazione, creazione, modifica ed eliminazione). Il log delle operazioni deve essere consultabile con un apposita funzionalità del sistema che deve essere descritta nell offerta. SISTEMA DI MONITORAGGIO DEI SERVIZI Deve essere previsto nella fornitura un sistema per il monitoraggio automatico dello stato di funzionamento di tutte le componenti offerte e dei servizi da esse erogati, che sia in grado attraverso l uso di sonde software di verificare costantemente il loro regolare funzionamento. BLOCCO E SBLOCCO SESSIONE Quando un utente abbandona la postazione deve poter bloccare completamente l accesso al programma, oscurando i dati eventualmente visibili. Tale blocco deve inoltre avvenire automaticamente dopo un tempo di inattività della sessione. Tale tempo deve essere parametrizzabile. Deve essere gestito nel modo più semplice e funzionale possibile il cambio di user nei contesti applicativi oggetto del presente capitolato. ACCESSIBILITÀ E PERSONALIZZAZIONI ACCESSO AGLI APPLICATIVI VIA WEB Si richiede che le soluzioni web oggetto della fornitura siano sviluppate preferibilmente con l'uso di dhtml puro senza installazioni aggiuntive rispetto agli internet browser. pag 16 di 34

17 Le soluzioni web inoltre devono poter operare sui principali browser di mercato (Internet explorer, Google Chrome, Mozilla Firefox e Safari) e sui principali sistemi operativi (Linux, Windows, ios e Android). HTTPS Tutte le parti della suite fornita dovranno essere utilizzabili tramite protocollo HTTPS. GESTIONE AUTONOMA DELLE CONFIGURAZIONI E DELLE STAMPE(CRI_v1.18) Sarà possibile proporre una soluzione che dia la possibilità di configurare in autonomia da parte di ciascuna ULSS, senza la necessità di utilizzare linguaggi o meta linguaggi informatici, la profilazione, le componenti del sistema (comprese tutte le form ed i controlli coinvolti) e le stampe prodotte dalla suite di programmi offerti. INTEROPERABILITA FRA SISTEMI INFORMATICI INTRODUZIONE L'architettura desiderata per la fruizione degli applicativi prevede una sola installazione presso i server centrali ad uso delle 4 Ulss della Provincia di Vicenza. Ogni applicativo oggetto di fornitura si dovrà interfacciare con i relativi dipartimentali delle 4 ULSS. In tal senso gli applicativi forniti si integreranno con:: 4 differenti sistemi di anagrafe centrale dei contatti (assistiti della singola ulss e non assistiti con cui la stessa è venuta in contatto); 4 differenti servizi di autenticazione, 4 differenti dipartimentali per ogni ambito clinico ; I sistemi forniti dovranno gestire centralmente tutti i campi codificati interfacciando questi con quelli dei 4 ambienti informativi della provincia. Ovvero, il fornitore dovrà mettere a fattore comune i dizionari di tutte e 4 le ULSS. Tutte le integrazioni dovranno transitare attraverso il sistema ESB in fornitura. Tutte le integrazioni dovranno essere gestite in modo da prevenire accessi non controllati, falsificazione di personalità, visibilità di dati non in linea con il D.Lgs 196/03, SQL e XML-injection, spoofing, DOS, cross-site scripting, etc... INTEGRAZIONI TRA LE PARTI FORNITE I metodi di integrazione dei moduli software, oggetto di fornitura, dovranno essere consegnati, in ambiente di produzione, via HL7 nelle versioni 2.X o 3 e utilizzando i profili IHE, ove possibile. SCHEMA DELLE INTEGRAZIONI pag 17 di 34

18 Il seguente schema riassume le integrazioni che devono essere implementate. Le modalità di integrazione devono essere considerate come indicazione di massima derogabili in caso il fornitore proponga soluzioni più performanti e aderenti agli standard. Si dividono nello schema sottostante l funzioni di order entry per la parte di richiesta (OE) e di risposta (VA). pag 18 di 34

19 a) ProntoSoccorso b) Order Entry c) Visite Ambulatoriali d) Continuità assistenziale 1 continuità la CA ha visione del carico di lavoro CA invia pazienti in PS assistenziale del PS tramite ordine referenziando il referto di CA 2 order entry PS attiva OE e invia dati strutturati al OE invia a VA la fine di minimizzare inserimento dati. richiesta ed il - OE informa PS sulla chiusura della dataset correlato prestazione - OE consegna al PS l URI del referto - OE invia il contenuto dei referti dei Dipartimentali al PS. 3 Visita VA informa OE sulla Ambulatoriale chiusura della prestazione 4 E- prescription deve poter deve poter richiamare richiamare con con passaggio di passaggio di contesto contesto (medico/paziente) i (medico/paziente) i diversi moduli di E-prescription. diversi moduli di E- prescription. Uno per Azienda Uno per Azienda 5 Active autenticazione e permesso di accesso autenticazione e permesso autenticazione e autenticazione e Directory legato a gruppo di accesso legato a gruppo permesso di permesso di accesso accesso legato a legato a gruppo gruppo 6 ANAGRAFE Bidirezionale Monodirezionale Bidirezionale 7 Repository - PS esegue XDS submissionset - OE esegue XDS - PS richiama visore XDS tramite submissionset passaggio di contesto 8 INPS PS produce ed esegue UPLOAD certificati di malattia verso l INPS 9 INAIL PS produce ed esegue UPLOAD certificati di infortunio verso l INAIL pag 19 di 34 - VA esegue XDS submissionset - richiama visore - CA esegue XDS submissionset - richiama visore XDS XDS tramite tramite passaggio di passaggio di contesto contesto VA produce ed CA produce ed esegue UPLOAD esegue UPLOAD certificati di certificati di malattia malattia verso verso l INPS l INPS VA produce ed esegue UPLOAD certificati di

20 infortunio l INAIL verso pag 20 di 34

21 a) ProntoSoccorso b) Order Entry c) Visite Ambulatoriali 10 FSE-r PS Richiama i servizi regionali per VA Richiama i accedere ai documenti clinici del FSE.r servizi regionali per accedere ai documenti clinici del FSE.r 11 ADT PS informa ADT aziendale del ricovero di un paziente. Deve esser gestito anche l'annullamento di un ricovero e l'eventuale riconoscimento a posteriori del paziente. 12 RIS OE passa i dati relativi alla richiesta. - RIS accetta o ripianifica l'esame e lo comunica ad OE.. - OE ottiene info sull'erogato e riferimento al referto d) Continuità assistenziale CA Richiama i servizi regionali per accedere ai documenti clinici del FSE.r 13 LIS OE passa i dati relativi alla richiesta. - oe ottiene info sull'erogato e riferimento al referto - OE legge i contenuti del referto prima della firma dello stesso 14 CIS e altre cartelle OE passa i dati relativi alla richiesta. - CIS accetta o ripianifica l'esame e lo comunica ad OE - OE ottiene info sull'erogato e riferimento al referto 15 CASSA - PS informa CASSA sulle prestazioni erogate - PS ottiene da CASSA un barcode e un importo da stampare nella distinta di pagamento. pag 21 di 34

22 16 Altri Order Entry 17 Sistemi di Gestione delle Code a) ProntoSoccorso b) Order Entry c) Visite Ambulatoriali OE in fornitura si integra con altri OE in produzione per la gestione del processo di richiesta-risposta - il PS deve informare i monitor delle sale attesa per informare i pazienti - il sistema di check-in si integra con il sistema di PS per i pazienti in attesa di triage d) Continuità assistenziale ELENCO DEI SISTEMI DA INTEGRARE ULSS3 MARCA Prodotto Metodo di integrazione RIS LIS CIS ADT/SIO Repository Anagrafe Directory Server E-Prescription CASSA Altro Order Entry ULSS4 MARCA Prodotto Metodo di integrazione RIS LIS CIS ADT/SIO Repository Anagrafe Directory Server E-Prescription CASSA Altro Order Entry ULSS5 MARCA Prodotto Metodo di integrazione RIS LIS pag 22 di 34

23 CIS ADT/SIO Repository Anagrafe Directory Server E-Prescription CASSA Altro Order Entry ULSS6 MARCA Prodotto Metodo di integrazione RIS LIS CIS ADT/SIO Repository Anagrafe Directory Server E-Prescription CASSA Altro Order Entry Si specifica che in base alle esigenze della singola ULSS il sistema di Order Entry si dovrà integrare con altri sistemi di Order Entry. ANAGRAFE(modificato 1,18) Ognuna delle 4 ULSS ha una propria Anagrafe Centralizzata dei Pazienti, di seguito APC. L'integrazione con le APC è requisito indispensabile per le integrazioni applicative interne alle ULSS. Ognuna della 4 aziende ha delle peculiarità sulla gestione della anagrafe centrale. Tali caratteristiche sono descritte nei documenti che ogni azienda allega al presente capitolato tecnico. A questi documenti si aggiungono le specifiche dell anagrafe regionale. I sistemi devono supportare le specifiche relative al progetto IXS (vedi all. XX) interno al progetto FSE-r e le specifiche anagrafiche delle 4 ULSS. Il fornitore deve dettagliare nel progetto relativo alle integrazioni come intende far sì che i pazienti siano agganciati a posizioni esistenti e non duplicati. Si tenga presente che deve esser data la possibilità agli operatori di unificare posizioni anagrafiche non certificate. Si rammenta al fornitore il paragrafo relativo alla riattribuzione degli episodi di cura. Si consideri infine l impatto delle unificazioni anagrafiche a livello provinciale sulla storia individuale dei pazienti. GESTIONE DEI CONSENSI PRIVACY pag 23 di 34

24 La gestione della Privacy è una caratteristica essenziale per la gestione delle integrazioni. In particolare, quanto di seguito descritto, potrà dover essere rivisto alla luce delle specifiche emesse all'interno del progetto Fascicolo Sanitario Elettronico regionale e della nuova normativa nazionale inerente la materia di prossima approvazione. I consensi ai fini privacy di ogni assistito devono corrispondere a definiti privilegi di accesso, generali o puntuali, ai dati presenti su Repository e FSEr. I consensi privacy sono: Di tipo generale, relativi al paziente per il trattamento dei suoi dati; Di tipo specifico, relativi ad un episodio/documento; I consensi generali vengono associati al paziente. Ad oggi sono costituiti dai seguenti flag: consenso generale al trattamento dei dati da parte della Azienda ULSS; consenso alla alimentazione del dossier sanitario elettronico presso la ULSS; consenso alla consultazione del dossier sanitario elettronico presso la ULSS; consenso alla alimentazione del fascicolo sanitario elettronico regionale; consenso alla consultazione del fascicolo sanitario elettronico regionale; Anche i software oggetto di fornitura, nella messaggistica verso le anagrafi centrali aziendali dovranno gestire i consensi privacy legati all'utente. Qualora un utente sia sprovvisto di consensi legati al trattamento dei suoi dati da parte della ULSS che lo ha in cura il sistema dovrà segnalarlo all'operatore e dargli la possibilità a fronte dell'avvenuto consenso, di tracciarlo sul programma in modo da notificarlo anche alle anagrafi centrali aziendali. Il Pronto soccorso, l order entry ed eventualmente il modulo di Visita Ambulatoriale, essendo i software che opereranno a contatto con l'utenza, sono deputati a gestire la registrazione dei consensi puntuali, legati cioè all evento ovvero alla prestazione cogente. Tale registrazione, anche assieme ai consensi legati alla persona, sarà comunicata ai document source terzi tramite le integrazioni applicative legate alle liste d'attesa (order entry) e di lavoro (cup e order entry). Il sistema deve tracciare dunque luogo, data ed ora di raccolta dei consensi e l operatore (identificato dallo user ID di login al sistema) che l ha effettuato, inoltre deve essere registrato il contesto per il quale viene dato ogni consenso: globale il consenso è a tempo indeterminato e per tutte le prestazioni con diritto di recesso; contestuale il paziente dà il consenso al trattamento relativamente ad un evento VISIT, come definito in HL7. Deve inoltre essere gestita la dichiarazione di consenso da parte dei tutori legali di minori e di pazienti interdetti o non in grado di esprimerlo. Per i minori il consenso deve essere richiesto nuovamente al raggiungimento della maggiore età. pag 24 di 34

25 I document source terranno l'impostazione ricevuta o la modificheranno (in particolare in radiologia o anatomia patologica, qualora il medico refertante lo ritenga opportuno) e la utilizzeranno per la compilazione del campo xds "hl7 confidentiality code". I valori impostati sui consensi faranno parte dei dati a corredo dei documenti sui Repository e ne costituiranno i criteri di accesso non solo sulla interfaccia utente del repository, ma anche nelle chiamate applicative. Con un esempio, l'order entry, quando anche disponga del documentid, non potrà eseguire il retrive di un referto marcato "Obscured". Nell'ottica del FSEr si prospetta all'offerente uno scenario che, con qualche modifica, potrebbe dover essere implementato entro l'anno Si rimanderà alla fase iniziale della messa in opera della fornitura la scelta più opportuna tra la situazione come gestita oggi e la prospettata nuova gestione che si va a descrivere. In base ai potenziali destinatari di un documento si ritiene che i consensi legati all'evento dovrebbero essere i seguenti: consenso all'accesso al documento da parte del personale medico della ULSS: la negazione di questo consenso non preclude l'accesso al documento al personale del reparto che emette il documento stesso; consenso all'accesso al documento da parte del medico di medicina generale dell'assistito; consenso all'accesso del documento nel fascicolo sanitario elettronico regionale ovvero all'accesso da parte del personale medico dipendente dalle aziende sanitarie della regione Veneto. Sono in istituzione regole atte a definire quali siano i criteri effettivi che daranno accesso ai dati del paziente. INFRASTRUTTURA HARDWARE BUSINESS CONTINUITY E DISASTER RECOVERY L infrastruttura di data center deve essere comune e deve implementare i servizi di business continuity e di disaster recovery (almeno soluzione di classe Tier 3, con riferimento alle linee guida DR dell AgID). POSTAZIONI DI LAVORO Al fine di garantire che le performances del sistema siano quanto più possibile vicine a quanto atteso dai fornitori, si richiede con il presente capitolato la fornitura di tutto l hardware necessario alla fruizione dei sistemi ad eccezione di quanto riguarda l infrastruttura telematica ed elettrica delle aziende ULSS. Si richiedono cioè il corrispettivo di Postazioni di lavoro (PC,monitor, mouse, tastiere), stampanti, lettori bar code, scanner, come esposti nella seguente tabella. ULSS3 PDL STAMPANTI BAR CODE SCANNER PS-ASIAGO PEDIATRIA- BASSANO pag 25 di 34