Capitolato tecnico della soluzione software per lagestione del processo di Presa in Carico deipazienti cronici in qualità di Ente Gestore in

applicazione della L.R. n.23/2015 e successiveDGR in materia di presa in carico della cronicità

per la ASST Cremona

1

Sommario

QUADRO NORMATIVO DI RIFERIMENTO……………………………………………………….. 32. OGGETTO DELLA FORNITURA……………………………………………………………………. 43. CONTESTO ATTUALE DEI SISTEMI INFORMATIVI DELLA ASST DI CREMONA………………………… . 54. REQUISITI FUNZIONALI DELLA PIATTAFORMA SOFTWARE………………………………….105. REQUISITI NON FUNZIONALI……………………………………………………………………….126. GESTIONE DEL CAMBIAMENTO ORGANIZZATIVO E PROJECT MANAGEMENT…………..147. PROPOSTE MIGLIORATIVE…………………………………………………………………………..148. CONSEGNA, IMPLEMENTAZIONE E GESTIONE DELL’INSTALLAZIONE DELLA SOLUZIONE

APPLICATIVA…………………………………………………………………………………………..149. FORMAZIONE DEL PERSONALE E AVVIAMENTO……………………………………………….1610. SERVIZI DI MANUTENZIONE………………………………………………………………………………1711. EXIT STRATEGY……………………………………………………………………………………….1812. SERVICE LEVEL AGREEMENT (SLA)……………………………………………………………….1813. PENALI……………………………………………………………………………………………………1914. CRITERI DI AGGIUDICAZIONE………………………………………………………………………20

2

1. QUADRO NORMATIVO DI RIFERIMENTO

La Legge Regionale 23/2015 della Regione Lombardia ha introdotto un profondo ripensamento dellemodalità per la gestione della domanda e dell’offerta del Sistema Sanitario Lombardo, attraverso lacostituzione di nuovi enti sanitari (ATS/ASST) nati dall’accorpamento e la ridefinizione dei perimetripreesistenti delle aziende. La nuova impostazione prevede la separazione delle attività di pianificazione econtrollo ad opera delle ATS e dell’erogazione delle attività assistenziali attraverso l’integrazione della rete diofferta ospedaliera con quella territoriale.Sotto tali presupposti, ed in linea con il Piano Nazionale delle Cronicità, la Regione Lombardia haproseguito con l’evoluzione della integrazione della componente ospedaliera con quella territorialeimplementando i nuovi modelli assistenziali di integrated care che sono stati raccolti e definiti nella DGRX/4662 (23/12/2015) - Piano regionale della cronicità e fragilità. Questa delibera stabilisce le modalità egli indirizzi della presa in carico delineando anche quali siano i modelli di riferimento e le realtà evolutiveattese, da sviluppare e attuare con successive delibere. Con la DGR X/6164 (30/01/2017) “Governo della domanda: avvio della presa in carico di pazienti cronici efragili - determinazioni in attuazione dell'art. 9 della legge n. 23/2015” è stato concretizzato il frameworkoperativo del processo della presa in carico definendone anche gli attori, il ruolo ed il funzionamentogenerale, regolando in tal modo la parte della domanda.Con la DGR X/6551 del 04/05/2017 avente ad oggetto il “riordino della rete di offerta e di modalità di presain carico dei pazienti cronici e/o fragili in attuazione dell’art.9 della legge regionale 33/2009”, si è dataattuazione alla gestione della presa in carico lato offerta. Quest’ultima delibera definisce i principi generali delle modalità attuative della gestione della presa incarico e del sistema informativo a supporto. La Piattaforma Regionale di Integrazione ed in seguito la NuovaPiattaforma Regionale di Integrazione (NPRI) vengono individuate come lo strumento a supporto degli attoricoinvolti nel processo di gestione della Presa in Carico.Proprio la riorganizzazione interna degli erogatori è uno dei principali cambiamenti che la presa in caricorichiede, in quanto si determina un passaggio di paradigma da gestione verticale ad integrazione orizzontaledei setting assistenziali in cui il paziente, non solo è seguito, ma è proattivamente indirizzato e monitorato. Ilcambio strutturale deve pertanto essere supportato da un sistema informativo che ne agevoli l’attuazione eche consenta da subito l’operatività degli utenti direttamente interessati, sia interni che esterni al sistema dierogazione delle cure. L’obiettivo, che il sistema informativo è chiamato a supportare è, sulla base di quanto espresso nella DGRX/6164, quello di consentire l’unitarietà di un percorso di presa in carico evitando la frammentazione deiprocessi e la suddivisione dei servizi tra area ospedaliera e territoriale a fronte dello sviluppo di nuovimodelli organizzativi che dovranno assicurare: la gestione dei sistemi di valutazione multidimensionale necessari alla presa in carico della persona; la lettura trasversale all’organizzazione/organizzazioni rinforzando i processi orizzontali tra i diversi

servizi e livelli di organizzazione per garantire l’integrazione e la continuità di cura; la “logistica” dei flussi informativi rendendo disponibili le informazioni a supporto della gestione di

percorsi di cura lungo le varie fasi del processo erogativo per garantire efficienza e appropriatezza.

Pertanto, alla luce delle suddette esigenze normative il presente documento definisce le principalifunzionalità, i servizi di supporto e le modalità di attuazione della soluzione software atta al supporto delprocesso della presa in carico.Il partner che si vuole individuare deve essere in grado di supportare l’ASST Cremona in questo processoevolutivo in coerenza con i suddetti indirizzi regionali.

3

2. OGGETTO DELLA FORNITURAIn riferimento all’oggetto del presente appalto, si richiede al Concorrente di presentare la miglior offerta perla fornitura della licenza d’uso, in formato eseguibile, della Piattaforma Software volta a supportare laStazione Appaltante nel processo di presa in carico dei pazienti. La Piattaforma Software dovrà essereinteroperabile e modulare, onde permettere a questa Stazione Appaltante di procedere conl’implementazione del nuovo modello di cura come definito da Regione Lombardia con la su indicata L.R.23/2015. La licenza d’uso della Piattaforma Software sarà concessa all’ASST Cremona a tempoindeterminato, irrevocabile e per utenti illimitati. Per licenza d’uso s’intende il diritto non esclusivo e nonliberamente trasferibile dell’ASST Cremona ad usare il Software.La Piattaforma Software, il cui utilizzo verrà esteso ad un numero illimitato di utenti, deve:- sostenere tutti i ruoli organizzativi previsti dalla delibera (Clinical Manager, Case Manager, Centrale

Operativa, MMG/PLS co-gestori, filiera erogativa) e tutti i ruoli interni alla ASST che senza vincoloalcuno, potranno essere definiti dalla ASST di Cremona nella fase di progettazione organizzativa e diprocesso. Si precisa che la Piattaforma Software oggetto della fornitura dovrà integrare gli ambitid’intervento sanitari, socio sanitari e sociali. Dovrà, inoltre, essere dimensionata e configurata in modotale da permettere a tutti gli attori della rete d’offerta che entrano nel processo di presa in carico (inparticolare al paziente stesso) la condivisione delle informazioni, nel rispetto delle normative vigenti inmateria di sicurezza delle informazioni, privacy e trattamento dei dati personali e dati sensibili sanitari;

- offrire tutte le componenti utili all’interoperabilità con i software: interni alla ASST, messi a disposizioneda soggetti della filiera erogativa, in capo ai MMG co-gestori, messi a disposizione da altri soggetti terziche possono operare nella specificità del quadro territoriale in sinergia con la ASST alla correttaesecuzione dei servizi socio sanitari e sociali in risposta alla domanda di salute dei pazienti presi incarico.

La piattaforma deve offrire le proprie funzionalità in modo modulare e flessibile, deve essere orientata aiprocessi e a diversi assetti organizzativi onde permettere, senza vincoli o costi aggiuntivi, a questa StazioneAppaltante di procedere con l’implementazione del nuovo modello di cura come definito da RegioneLombardia con la sopra indicata L.R. 23/2015.Il fornitore deve attivare, inoltre, tutto il supporto organizzativo e informatico necessario affinché l’ASST siain grado di organizzare ed avviare una propria centrale operativa interna.L’Aggiudicatario è, quindi, tenuto a:

predisporre, installare, configurare, ed attivare la piattaforma applicativa per la presa in carico secondole specifiche esigenze organizzative/operative della ASST Cremona entro 15 gg dalla stipula delcontratto, ad esclusione delle integrazioni con i sistemi informativi della ASST e delle integrazioni SISS.La piattaforma applicativa deve permettere l’accesso in modo profilato anche ai pazienti e ad eventualicare givers adeguatamente autorizzati. Fa parte della piattaforma anche una APP mobile a supporto deipazienti;

realizzare le integrazioni con i sistemi informativi della ASST, che dovranno essere rese disponibili ecollaudate entro 60 gg dalla stipula del contratto;

mettere a disposizione le integrazioni applicative del sistema con il SISS sulla base delle indicazionipresenti nel kit di integrazione di RL/LISPA (GPC_Integration_Kit_V03) entro 45 gg dalla stipula delcontratto accompagnando l’ASST negli eventuali percorsi di validazione eseguiti da RL/LISPA;

garantire l’assistenza e la manutenzione della Piattaforma Software per la durata pari a n. 36 mesi a fardata dalla sottoscrizione del verbale di collaudo;

garantire la formazione e l’assistenza all’avviamento del personale dell’ASST Cremona coinvolto nelprocesso di presa in carico avviando tali attività sin dall’inizio del processo di configurazionedell’applicativo;

rendere disponibili interfacce per la interoperabilità della soluzione proposta con le soluzioniinformative degli enti (pubblici e privati) coinvolti nella filiera di gestione e di erogazione del processo dipresa in carico dei pazienti;

fornire l’estensione della suddetta piattaforma applicativa anche ad ulteriori 10 enti erogatori (pubblicie privati) al fine di creare un processo completamente integrato e interoperante con gli stessi;

4

fornire, durante il periodo del contratto, il supporto organizzativo e informatico all’ASST per l’avvio dellaPiattaforma Software, compresa un’attività di Project Management, garantita da un Project Managerdedicato. Le funzioni di supporto all’ASST possono essere ricomprese in due macro ambiti: unotecnologico e d’integrazione dei sistemi informativi e l’altro prettamente organizzativo e diaccompagnamento finalizzato (1) all’attivazione del processo di presa in carico che prevede l’interazionecon i diversi interlocutori aziendali coinvolti nel processo e (2) all’organizzazione della fase di start up delCentro Servizi interno e integrato con gli altri Enti erogatori (Pubblici e Privati).

Si precisa che l’importo unitario offerto per ciascun Ente Erogatore (pubblico o privato) verrà riconosciutosolo se effettivamente l’ASST richiederà l’estensione della suddetta Piattaforma applicativa.Ciò che viene richiesto non è solo una soluzione tecnologica, ma una partnership per accompagnare l’ASSTnella progettazione e nell’implementazione di modelli organizzativi di gestione della cronicità e delle logichedi processo.

3. CONTESTO ATTUALE DEI SISTEMI INFORMATIVI DELLA ASST DI CREMONA

ASST di Cremona si compone delle seguenti strutture erogative:- Sedi ospedaliere

Ospedale di Cremona, Viale Concordia n.1, Cremona Ospedale Oglio Po, Via Staffolo n. 53, Vicomoscano (Cremona)

- Sedi territoriali, prevalentemente nei comuni di: Cremona, Casalmaggiore, Soresina.Di seguito è illustrato l’attuale contesto dei sistemi informativi della ASST Cremona al fine di consentire unavisione il più completa possibile al concorrente in modo da poter qualificare meglio la proposta.La ASST di Cremona ha aderito al progetto di Regione Lombardia di “Consolidamento e razionalizzazionedei CED delle Aziende Sanitarie” (d.g.r. X/3650 del 05/06/2015 avente oggetto “Determinazioni inerenti ilconsolidamento e razionalizzazione dei CED - Centro Elaborazione Dati - di sei Aziende Sanitarie”).Obiettivo specifico del progetto è l’erogazione di servizi IaaS, costituita dall’erogazione di risorseinfrastrutturali di storage ed elaborazione presso il Data Center di Regione Lombardia, assegnatevirtualmente alle ASST aderenti al progetto e fruite da queste secondo la logica di Virtual Data Center (VDC),e di servizi di Disaster Recovery, costituiti dalla erogazione del Disaster Recovery in Classe Tier 4 dei VDCdella ASST. L’architettura di riferimento presente nel Data Center di Regione Lombardia è descrittanell’allegato 1. In questo contesto, dovrà quindi inserirsi la Piattaforma Software offerta e tutte le relativeintegrazioni.

L’infrastruttura di rete aziendale che copre tutti i presidi della ASST e permette l’accesso alla Intranetaziendale è in fase di revisione sia per la componente WAN, che entro giugno 2018 migrerà sullaconnettività MPLS di Regione Lombardia, sia per la componente LAN, per la quale è stata avviata unaprocedura di gara per la competa sostituzione delle componenti attive di rete.Negli ospedali di Cremona e Oglio Po’ è presente una rete WiFi che copre tutte le aree di ricovero e che staper essere completata con la copertura delle aree amministrative e delle aree di maggior frequenza degliutenti (Sale attesa CUP e altre). Il parco delle Postazioni di Lavoro della ASST di Cremona è composta prevalentemente da pdl Windows7italiano,32 bit. La soluzione proposta, completamente WEBbased, deve essere compatibile con i più diffusiantivirus del mercato (attualmente la ASST ha installato trend Micro), con i più diffusi browser.Dovrà essere garantita la compatibilità con versioni successive del SO.Dal punto di vista applicativo il Sistema Informativo Aziendale della ASST Cremona è composto da diversimoduli integrati tra loro a vario livello, finalizzati a permettere la corretta gestione dei processi clinici edamministrativi.La ASST di Cremona si avvale, per l’interoperabilità applicativa e con il SISS della Piattaforma Regionale diIntegrazione e, quindi, non appena disponibile migrerà verso la Nuova PRI.

5

Nel seguito sono elencate le principali componenti applicative e di interoperabilità del Sistema Informativodella ASST di Cremona.

SISTEMI AREA CLINICO/SANITARIA

• PRI - Piattaforma Regionale di Integrazione (Fornitore Lombardia Informatica). Delle varie componenti di cui è costituita la PRI si elencano quelle utilizzate presso la ASST diCremona

o MIDDLEWARE DI INTEGRAZIONE JCAPS

Il middleware consente la condivisione dei servizi centrali tra le varie applicazioni, inparticolare la sincronizzazione dell’Anagrafica Pazienti Centralizzata con le Anagrafiche localidei vari dipartimentali e si presenta come hub per le integrazioni hl7 tra i vari dipartimentali.

o MIDDLEWARE SISSWAY

Permette di interagire con i due elementi fondamentali della piattaforma, RPY e BAC e sipone come interfaccia al SISS. In particolare fornisce servizi per:

Identificare l’assistito rispetto l’anagrafica depositata a livello regionale; Identificare e acquisire le prescrizioni registrate sui domini centrali del SISS; Notificare al SISS gli eventi sanitari (prenotazione e accettazione appuntamenti,

accettazioni e dimissioni ricovero, etc etc); Gestire l’archiviazione sul Repository dei referti generati dai dipartimentali in forma

strutturata e non; Gestire i servizi necessari per il recupero dello storico dei referti; Fornire i servizi di firma digitale con carta operatore CRS-SISS.

o BAC (BANCA ANAGRAFICA CENTRALE) – ANAGRAFE CENTRALIZZATA PAZIENTI

La gestione centralizzata dei dati anagrafici è abilitata dalla BAC (Banca AnagraficaCentralizzata). La BAC è alimentata dai sistemi di front office attraverso il middleware HL7.Comunica ogni variazione anagrafica attraverso broadcast HL7 allo scopo di garantire ilcostante allineamento dei dati anagrafici. Lo scenario è quello per cui ciascun sottosistemasia dotato di una propria anagrafe locale, che deve essere allineata alla BAC conmessaggistica HL7.

o RPY (Repository Referti)

Il Repository raccoglie la documentazione clinica firmata elettronicamente (Refertiambulatoriali, Verbali di Pronto Soccorso, Lettere di dimissione, …). In particolare, ilRepository Referti sfrutta i servizi SISS-Way per l’archiviazione, la consultazione el’oscuramento dei referti, sia in formato pdf, sia in formato srutturato. Tutti i refertiarchiviatisono firmati con firma digitale SISS e marcati temporalmente. E’ possibile inoltre accederecon l’interfaccia EPR (Electronic Patient Record) alla consultazione avanzata dei referti,organizzati su scala temporale e per episodio clinico per ciascun paziente.

• CUP-CAMELIA (Fornitore Reply/SANTER)Supporta la gestione amministrativa relativa all’erogazione delle prestazioni ambulatoriali.L’applicativo si integra attraverso il middleware di integrazione via messaggistica HL7 con iservizi dipartimentali, con SISSWAY e con tutti i servizi SISS necessari. Garantiscel’integrazione verso il servizio GP (Gestione Prenotazioni) di Regione Lombardia, per laprenotazione di prestazioni ambulatoriali attraverso i canali CCR (Call Center Regionale,farmacie e cittadini.

• Piattaforma AREAS (Fornitore Engineering)Dei moduli della piattaforma Areas sono presenti:

6

o ADTWEBSupporta la gestione amministrativa degli eventi di accettazione, dimissione etrasferimento, relativi ai ricoveri ordinari e alle prestazioni erogate in regime di DH.L’applicativo produce le SDO e le lettere di dimissione firmate digitalmente e archiviate viaSISS-Way sul Repository aziendale e notificate al Fascicolo Sanitario Elettronico nella reteregionale SISS.

o PSWEBGoverna il processo di gestione del paziente in Pronto Soccorso attraverso gli step classicidel triage, della visita medica e della dimissione. Durante il processo di gestione è possibilerichiedere tramite le opportune integrazioni con i dipartimentali aziendali consulenze erichieste di indagini diagnostiche, per queste ultime sono, attraverso il modulo di OrderEntry, integrazioni con i dipartimentali LIS, RIS, consulenze interne. L’applicativo produce ilVerbale di PS firmato digitalmente e archiviato via SISS-Way sul Repository aziendale enotificato al Fascicolo Sanitario Elettronico nella rete regionale SISS. E’ attiva la gestionedell’OBI. Gestisce anche i flussi INPS e INAIL.

o ORDER ENTRYRappresenta il sistema per la gestione delle richieste informatizzate verso i dipartimentaliper i pazienti ricoverati. Al momento la richiesta informatizzata è gestita per il RIS (servizi diRadiologia, ,Medicina Nucleare e Gastroenterologia Digestiva). E’ in fase di avvio la richiestaLIS e in sviluppo la richiesta di Anatomia Patologica. E’ inoltre utilizzato per l’integrazione fraADTWEB e OrmaWeb per l gestione delle liste operatorie.

o MURG -Medicina d’UrgenzaCartella clinica per la gestione del reparto di medicina d’urgenza, integrata alla gestione OBI.

• Prescrizione e Somministrazione Farmaco – Sofia (Fornitore SLPA)Gestione della prescrizione e somministrazione del farmaco anche in dose unitaria presso i repartidi ricovero. L’applicativo è integrato HL7 al Sistema Informativo Aziendale per recepire i dati delpaziente e dei ricoveri oltre ad integrarsi con la componente amministrativa di gestione del farmaco

• Blocco Operatorio e Cartella Anestesiologica - OrmaWeb (Fornitore DEDALUS)Il gestionale dedicato al Blocco Operatorio offre funzionalità di richiesta, pianificazione eregistrazione degli interventi, consentendo inoltre di compilare digitalmente il verbale operatorio,firmarlo digitalmente ed archiviarlo su RPY. Il sistema, integrato con il modulo Order Entry ad ADTper la gestione informatizzata delle prenotazioni di intervento.

• LIS - Concerto (Fornitore Dedalus) Il LIS è integrato mediante messaggistica standard HL7 al CUP per l’accettazione, e al SISSWAY perl’archiviazione dei referti strutturati CDA2 e firmati digitalmente su RPY. E’ predisposto all’invio deldato strutturato dei dati di laboratorio, ed integrato attraverso Order Entry.

• Immunoematologia e Medicina Trasfusionale – Emonet (Fornitore Insiel Mercato)• AP – Armonia (Fornitore Dedalus)

Armonia gestisce il servizio di Anatomia Patologica, è integrato mediante messaggistica standardHL7 al CUP per l’accettazione, al SISSWAY per l’archiviazione dei referti firmati digitalmente su RPY.E’ in via di sviluppo l’integrazione con Order Entry.

• RIS – Elefante.net (Fornitore Agfa) Il RIS gestisce i Servizi di Radiologia, Medicina Nucleare ed Endoscopia Digestiva. Viene inoltreutilizzato per la compilazione del referto di Angiografia Cardiaca. E’ integrato mediantemessaggistica standard HL7 al CUP per l’accettazione, al SISSWAY per l’archiviazione dei refertifirmati digitalmente su RP e con Order Entry.

• Refertazione Ambulatoriale e Gestione Cartella Ambulatoriale - HCSuite (Fornitore DSP)L’applicativo HCSuite, integrato mediante messaggistica HL7 al CUP, permette di produrre il refertoambulatoriale partendo dalla visualizzazione della lista di lavoro. Sempre con HCSuite sono stateimplementate alcune cartelle ambulatoriali. E’ integrato in HL7 con RPY per l'archiviazione delreferto firmato digitalmente. E’ nativamente integrato con il software di Prescrizione MPSolution.

7

• Generazione Prescrizione - MPSolution (Fornitore DSP)Supporta l’attività di Prescrizione di prestazioni specialistiche e farmaci sia in modalità cartacea(RUR) sia in modalità dematerializzata (DEM). E’ integrato da altre soluzioni applicative presenti inASST (LIS, AP, RIS, Cartella Ambulatoriale, Dialisi, CAD, TAO).

• Dialisi – MedWare (Fornitore SINED)Gestione della attività di dialisi e del servizio di Nefrologia, integrato al SISS e alla rete RENE diRegione Lombardia.

• Centro Antidiabetico (CAD) – WyStar Connect (Fornitore Meteda)Gestione Cartella Clinica Centro Antidiabetico integrata al SISS e alla rete DIAB di RegioneLombardia.

• Centro Emostasi e Trombosi (TAO) – TAONET (Fornitore EDP Progetti)Gestione Cartella Clinica Centro TAO i corso l’integrazione al SISS

• Gestione prescrizione FILE F - File F (Fornitore Net4market-CSAmed)• Gestione Consultori - SIT (Fornitore GPI)

Utilizzato prevalentemente per garantire i flussi istituzionali, è integrato al CUP Camelia della ATSValpadana per la fase di prenotazione/accettazione/cassa prestazioni e valorizzazione economica.Attualmente il sistema è installato presso il Data Center della AST della Valpadana. E’ prevista lasostituzione della integrazione al CUP della ATS Valpadana con l’integrazione al CUP della ASST diCremona.

• Gestione SERD - MFP (Fornitore Ciditech)Attualmente il sistema è installato presso il Data Center della AST della Valpadana.

• Medicina Legale - Aster (Fornitore Insiel Mercato)Attualmente il sistema è installato presso il Data Center della AST della Valpadana

• Flussi Protesica - Assistant RL (Fornitore Lombardia Informatica) che gestisce i flussi di protesicamaggiore, protesica minore, diabetica e dietetica.

SISTEMI AREA AMMINISTRATIVA

Agli applicativi sopra elencati che sono pertinenti dell’area clinico sanitaria, si deve aggiungere lacomponente amministrativa gestionale di cui si elencano le principali componenti:

• Gestione Risorse Umane - Aliseo (Fornitore Windex)Le principali funzionalità del sistema sonole funzioni di gestione della componente giuridica, dellarilevazione presenze e del trattamento economico del personale, oltre a tutti gli adempimentiprevisti dalle norme vigenti. L’applicativo alimenta il sistema Amministrativo Contabile per i flussieconomici elaborati periodicamente. Il sistema integra una componente web per la gestione dellainterazione con il personale.

• Amministrativo Contabile e Logistica – OAPPS (Produttore Oracle, Partner aziendale GPI)Tutta la componente amministrativo-contabile dell’Azienda viene gestita con la PiattaformaSoftware OAPPS che presidia il ciclo attivo, ovvero tutta la parte contabile e di fatturazione legataall’erogazione del servizio, e il ciclo passivo, ovvero tutti gli ordini e i rapporti con i fornitori,mettendo a disposizione funzionalità per la gestione del workflow di gestione degli ordini dallarichiesta di magazzino, alla generazione dell’ordine, alla gestione della tesoreria per il pagamento.La gestione delle richieste e delle scorte di farmaci e dei prodotti economali dei diversi reparti sonogestite mediante una web application fornita dalla stessa GPI e integrata a OAPPS.

• Controllo di gestione – Oracolo/ReportMeq/Qlik (Fornitore OSLO). La Piattaforma Software mette a disposizione tutte le funzionalità di contabilità analitica, cheraccolgono i dati da tutti i database presenti in Azienda per calcolare gli indicatori economico-finanziari per procedere all’analisi mediante strumenti di business intelligence. Gli stessi strumentivengono utilizzati per:- la costruzione di indicatori di performance,

8

- la produzione e la diffusione della reportistica aziendale al livello direzionale e ai centri diresponsabilità,

- la gestione di alcuni dei principali flussi verso gli enti di controllo.

• Protocollo e Workflow documentale – Archiflow (Fornitore SIAV). La Piattaforma Software gestisce la protocollazione a norma. Sono stai inoltre implementati alcuniflussi documentali: Gestione Comitato Etico, Flusso Sinistri, Flusso Determine e Delibere, FlussoLiquidazione Fatture Passive.

Il modello a cui tende l’architettura logica dei sistemi informativi della ASST è rappresentata nella figura

seguente:

4. REQUISITI FUNZIONALI DELLA PIATTAFORMA SOFTWAREAl fine di permettere a ciascun Concorrente di presentare la propria miglior offerta, si precisa che la presa incarico integrata delle cronicità richiede all’Ente Gestore di interagire, sia in fase di definizione del percorsodi cura del paziente sia in fase di attuazione e monitoraggio dello stesso, con uno o più altri soggettierogatori di prestazioni sanitarie e sociosanitarie, specificatamente, con l’Agenzia della Tutela della Salute diriferimento (ATS) per le attività di propria competenza, con il cittadino anche tramite il Fascicolo SanitarioElettronico (FSE), con il Pediatra di Libera Scelta (PLS) e con il Medico di Medicina Generale (MMG). Il Sistema dovrà disporre di strumenti di profilazione degli operatori, che a seconda del proprio ruolo,concorreranno nella presa in carico del paziente, compreso il case manager e il clinical manager. Il Software dovrà, inoltre, permettere la configurazione e la gestione di eventuali co-gestori, come definitoda Regione Lombardia (cfr. DGR 6551 del 04.05.2017). Si specifica che il Sistema dovrà consentire l’estrazione dei dati relativi: - ai profili configurati per ciascun operatore; - elenco degli operatori abilitati suddiviso per profili; - ai permessi di visibilità dei dati trattati (dati personali e dati sensibili sanitari degli Utenti) per ogni profilo.

9

Si precisa che tale estrazione è necessaria in quanto consente alla Stazione Appaltante di procedere con lapredisposizione della scheda informativa contenente i nominativi dei singoli operatori che potrannoaccedere ai dati dei pazienti presi in carico, in ossequio a quanto previsto dall’art. 3.4 - Allegato 1 della DGRn. 6551del 04.05.2017. Inoltre, l’ASST Cremona, in qualità di Ente Gestore, dovrà garantire tutte le funzioni definite perl’accompagnamento del percorso di presa in carico dei pazienti, le quali potranno essere gestitedirettamente o parzialmente esternalizzate. In particolare, l’ASST Cremona dovrà assicurare, mediante laPiattaforma Software, la corretta condivisione delle informazioni cliniche tra tutti i diversi attori coinvoltinella presa in carico di tali Utenti. Tale modello di interazione organizzativa richiede, pertanto, un supporto informatico interoperabile eaccessibile a vari livelli, in particolare, da parte dell’ATS di riferimento ai fini di monitoraggio delle attività dipresa in carico. Si precisa che la piattaforma Software presentata dovrà consentire la completa gestione del processo dipresa in carico del paziente, come definito dalle linee di indirizzo regionali, secondo le seguenti fasi: (1)Arruolamento; (2) Organizzazione del percorso di cura e (3) Monitoraggio, controllo e remunerazione.

PIATTAFORMA SOFTWARE

La piattaforma Software deve offrire funzionalità per la presa in carico, che supportino tutto il processonelle sue fasi: governo degli arruolamenti, patto di cura e la relativa sottoscrizione, pianificazione econdivisione del percorso di cura, gestione pianificazione appuntamenti, attuazione percorso di cura,monitoraggio e controllo, percorso di raccolta della Customer Satisfaction, acquisizione e gestione deiconsensi informatici, verifica obiettivi e remunerazione. In particolare, la piattaforma applicativa deve garantire: la piena configurabilità dell’organizzazione dell’Ente Gestore che può anche variare nel tempo e della

Filiera Erogativa, comprensiva degli eventuali co-gestori; la piena configurabilità dei ruoli e delle responsabilità che verranno attribuite agli utenti del sistema; la piena configurabilità delle attività e dei processi di gestione della presa in carico; la piena configurabilità dei PDTA, nel rispetto delle indicazioni regionali e delle norme attuali e di futura

emanazione; La piena integrazione ai Domini Centrali SISS in totale adesione a quanto definito nel kit di integrazione

di RL/LISPA (GPC_Integration_Kit_V03) e future revisioni); la gestione delle liste degli Utenti arruolabili, anche mediante l’interfacciamento con i sistemi regionali,

utilizzando i metodi previsti nel KIT di integrazione nella versione attuale e nelle future evoluzioni; la raccolta dei consensi al trattamento dei dati personali e dei dati sensibili sanitari del paziente; la verifica dei criteri di inclusione/esclusione dei pazienti (stratificazione del livello di gravità), la

sottoscrizione del patto di cura e la valutazione di base dei pazienti come definito dai processi e dalleattività previste da RL/LISPA nel kit di integrazione;

la valutazione multidimensionale del bisogno del paziente cronico divisa per ambito di valutazione ecomprendente tutte le principali scale di valutazione;

la identificazione del Case Manager e del Clinical Manager e laddove presente il MMG co-gestore; la redazione del Piano Assistenziale Individuale (di seguito: “PAI”) sia mono sia pluri-patologia

permettendo la configurazione di diversi flussi di lavoro e di redazione collaborativa tra il clinicalmanager/Co-Gestore ed eventuali specialisti. Verranno valutate le potenzialità del Software di:supportare, mediante schermate di facile utilizzo, la redazione del PAI, proponendo, in base allepatologie che verranno associate all’Utente, i PDTA e i set minimi definiti a livello regionale e aziendalee di caricare il piano terapeutico dedicato al paziente per quanto riguarda la fornitura al domicilio difarmaci, protesica maggiore e minore;

la redazione del PAI multispecialistico e quindi corredato di tutte le funzionalità per essere gestito edintegrato con l’interazione dei diversi attori specialisti;

al Gestore o al soggetto incaricato dal Gestore di effettuare per ogni paziente preso in carico laprenotazione delle prestazioni previste nel PAI, prevedendo l’integrazione sia con i sistemi di gestionedelle agende interne al Gestore, che presso gli enti erogatori della filiera esterna;

10

la condivisione del PAI, tra eventuale Co-gestore e Gestore, e in ogni caso tra Gestore e il Medico diMedicina Generale (MMG) o il Pediatra di Libera Scelta (PLS), condivisione informativa, attraversoadeguate integrazioni tra la piattaforma di presa in carico e le cartelle cliniche dei MMG/PLS;

la configurazione di alert o warning per la gestione ottimale del percorso di cura; la valutazione ex-ante ed ex-post della qualità del PAI predisposto rispetto alla regole definite dalla

normativa e aziendalmente dai comitati sanitari e scientifici; strumenti di valutazione di congruità del percorso svolto dal paziente in grado di evidenziare quanto

prima eventuali scostamenti; l’interazione con i diversi soggetti interni ed esterni coinvolti nel processo erogativo (prestazioni

sanitarie e sociosanitarie), sia in fase di definizione del percorso di cura sia in fase di attuazione emonitoraggio dello stesso;

la possibilità di fruire, anche attraverso eventuali integrazioni con sistemi esterni alla ASST, delladocumentazione sanitaria in possesso del paziente o proveniente anche da altre strutture sanitarie esociosanitarie;

il monitoraggio, il controllo (sia internamente per l’ente gestore, sia verso l’ATS per le attività di relativacompetenza) e la rendicontazione dei flussi di attività di assistenza e delle prestazioni erogate;

la registrazione di tutti gli eventi relativi al singolo paziente durante tutto il percorso di cura e la relativaconsultazione in modalità chiara e efficiente al fine del monitoraggio dell’aderenza al percorsodell’Utente;

la condivisione del PAI e del percorso di cura con il paziente sia attraverso APP Mobile sia attraversol’accesso profilato alla Piattaforma Software che deve permettere la piena configurabilità del “patientportal” e di canali alternativi (per esempio: chat, e-mail; SMS,…);

l’integrazione con i sistemi di telemedicina e telemonitoraggio del paziente; la possibilità di configurare questionari o schede di valutazione che permettano il costante monitoraggio

del percorso di cura del singolo paziente, nonché la gestione dei feedback dei pazienti attraverso lasomministrazione di specifici questionari on-line (Customer Satisfaction).

INTEGRAZIONI E INTEROPERABILITÀ

La piattaforma software deve garantire le seguenti interfacce: l’integrazione ai Domini Centrali SISS per l’identificazione dell’Utente e la pubblicazione della

documentazione sul FSE (patto di cura, consenso, PAI, documentazione sanitaria, tra cui i referti)secondo le indicazioni e i metodi definiti o in via di definizione da parte di Regione Lombardia e dallaSocietà Lombardia Informatica S.p.A.;

la piattaforma Software fornita deve prevedere l’integrazione con i seguenti sistemi informaticiattualmente in uso presso l’ASST di Cremona: ◦ Anagrafica aziendale BAC, sistemi RUR, CONSENSI; ◦ Applicativo CUP CAMELIA, per la gestione del ciclo di prenotazione/accettazione/rendicontazione

dell’erogazione; più in generale per la gestione di dati amministrativi e sanitari delle prestazioni dispecialistica ambulatoriale prenotate ed erogate in ambito ospedaliero e territoriale;

◦ Repository aziendale dei referti RPY, indicativamente per l’archiviazione del PAI, l’accesso allo storicoreferti e all’EPR;

◦ Integrazione con i servizi Sissway per la firma digitale dei documenti clinici;◦ Piattaforma Areas per le informazioni relative ad accessi in PS e a ricoveri, incluse le integrazioni per

la gestione delle liste attesa per i ricoveri programmati; ◦ Modulo per la prescrizione Specialistica e Farmaceutica Mpsolution;◦ integrazione con il DWH aziendale (oracolo) al fine di garantire la gestione di tutti gli indicatori

necessari al monitoraggio qualitativo e quantitativo del processo di presa in carico;◦ integrazione con eventuali sistemi di prenotazione di enti erogatori esterni, convenzionati con l’ASST

di Cremona, mediante linguaggi standard di comunicazione. ◦ eventuali integrazioni con altre soluzioni applicative aziendali potranno essere definite in un

secondo momento e riguarderanno le componenti applicative sanitarie o socio sanitarie (File F,

11

Cartelle Ambulatoriali, Consultori, Cartelle Cliniche, Servizi Diagnostica). Tali integrazioni verrannodiscusse e quotate fuori dal perimetro economico della presente gara.

al fine di garantire l’interoperabilità con i sistemi informativi di Enti erogatori (pubblici e privati)dovranno essere fornite interfacce d’integrazione standard (HL7, webservices).

In questo contesto dovranno essere gestite e manutenute anche le corrette comunicazioni con laPiattaforma Regionale di Integrazione di cui l’Azienda è dotata e in futuro con la NPRI.In merito si fa riferimento ai documenti pubblicati da Lombardia Informatica sotto il nomeGPC_Integration_Kit_V03 e alle loro successive evoluzioni, rintracciabili all’indirizzo:http://www.siss.regione.lombardia.it/EdmaSissPortaleSitoWebPublic/disclaimer.do?pag=documentoDiProgetto.jsp&par=doc&id=94245768

5. REQUISITI NON FUNZIONALI

GESTIONE DEGLI ACCESSI AL SISTEMA - COMPONENTE DI GESTIONE DELLA TRACCIABILITÀ DI PROCESSO

Per la gestione dell’accesso del personale al sistema, dovranno essere tassativamente implementati unaserie di requisiti atti a garantire tracciabilità e affidabilità degli accessi a sistema.

Dovranno essere garantiti livelli di accesso differenti per i diversi gruppi di utilizzatori (medico,infermiere, caposala, utente amministrativo, Operatore Tecnico) e anche, ove richiesto, per singoliruoli di utilizzatore con abilitazioni a livello di:

o visualizzazione,o inserimento,o modifica/cancellazione logica, differenziabili a livello di singolo campo e categoria di dati.

Il Software dovrà permettere la registrazione elettronica da parte del personale abilitato ad operaresulla Piattaforma Software di ogni attività svolta durante il processo in modo da garantire:

o la tracciabilità,o la rintracciabilità,o la ripetibilità.

Le operazioni sul sistema saranno possibili solo in seguito ad autenticazione dell'operatore e lemodifiche saranno consentite solo se previste dal profilo autorizzativo;

Per adempiere ai requisiti di affidabilità, è necessario che il dato clinico, una volta inserito nelsistema, non possa essere eliminato da alcun soggetto ma, possa essere revisionato o logicamentereso invalido (cancellazione logica). Sarà necessario tener conto di eventuali errori materiali e/o divalutazione e pertanto mantenere un log delle modifiche, tracciate per ora, data e identificativodell’operatore che le effettua. Sarà anche opportuno che la gestione della revisioni siapersonalizzabile per ogni ente secondo le policy aziendali (es. solo data odierna).

Il Software deve evitare l’eventualità che gli operatori omettano dati fondamentali per il percorso dicura o li registrino in modo incompleto o sintatticamente scorretto; sulla base delle esigenzeprocedurali e normative e tramite il confronto con il personale interno della ASST devono quindiessere definiti i campi dell’interfaccia utente la cui compilazione è obbligatoria e devono essereprevisti specifici controlli sui campi compilati.

REQUISITI DELL’ARCHITETTURA DELLA PIATTAFORMA SOFTWARE

Dal punto di vista dell’architettura applicativa il sistema dovrà:

avere una struttura modulare a sottosistemi finalizzata all’utilizzo delle sue funzionalità nell’ambitodella rete aziendale, vale a dire un sistema basato sulla comunicazione con protocollo TCP/IP,

12

architettura e interfaccia utente web-based basata su protocolli e tecnologie standard (es. http, asp)compatibile con i principali browser senza l’installazione di ulteriori software aggiuntivi;

supportare le integrazioni tra applicativi in modalità standard come HL7 o webservices;

permettere la fruizione delle funzionalità del sistema in mobilità, nelle diverse fasi del processo chelo richiedono;

assicurare l’accesso degli operatori al sistema: Medici, Infermieri ed altre figure coinvolte neiprocessi assistenziali e a supporto delle funzioni meramente amministrative. L’accesso dovrà essererealizzato secondo diverse modalità a sulla base del contesto operativo, attraverso l’inserimentodelle credenziali d’accesso (username e password) e attraverso uno strumento hardware qualesmart card SISS operatore o altro. In merito dovrà essere garantita la coerenza e l’integrazione conle infrastrutture di sicurezza ed autenticazione esistenti (autenticazione utente, identificazionepaziente, identificazione oggetti, firma digitale, etc..);

essere dimensionato in modo da garantire un supporto prestazionale adeguato alle attività eseguitedalla ASST seguendo adeguatamente la crescita dell’attività nell’intero periodo contrattuale. Ilconcorrente dovrà fornire specifiche dettagliate per la predisposizione da parte di LISPAdell’infrastruttura tecnologica di supporto;

essere opportunamente documentato, in modo da dare indicazione chiara delle tecnologieutilizzate e delle modalità scelte per l’integrazione con le diverse componenti del SistemaInformativo Aziendale (SIA). Tale documentazione dovrà essere mantenuta aggiornata dal fornitorein base alle evoluzioni del software;

per quanto concerne la sicurezza di gestione del dato clinico, garantire la crittografia deicollegamenti anagrafici del paziente e prevedere l’eventuale necessità di anonimizzazione dei daticlinici sensibili del paziente per alcuni utilizzi secondo la normativa vigente;

integrarsi con il Dominio dell’ASST Cremona allo scopo di facilitare l’accesso degli operatori dellaASST alle informazioni.

6. GESTIONE DEL CAMBIAMENTO ORGANIZZATIVO E PROJECT MANAGEMENT

Al Fornitore è richiesto di collaborare con l’Ente, durante l’intero periodo contrattuale, alla gestione delcambiamento fornendo supporto organizzativo e informatico attivo e proattivo in tutte le fasi legate alcambiamento dei processi nell’ambito della fornitura (dall’analisi dei requisiti, alla progettazione, finoall’implementazione e alla formazione degli utenti), comprese le attività di Project Management (attraversodei Project manager dedicati).In particolare:- supporto organizzativo all’avvio e all’organizzazione delle attività in carico al Centro Servizi Interno (eintegrato con altri Enti Erogatori pubblici e privati) fruitore della Piattaforma Software, oggetto di questafornitira, che dovrà permettere la configurazione di alert o warning al fine di agevolare l’attività del suddettoCentro Servizi;- monitoraggio proattivo delle attività previste dal PAI (visualizzazione dell’elenco degli Utenti arruolati per iquali è possibile procedere alla prenotazione degli appuntamenti e visualizzazione delle prenotazioni inscadenza per effettuare chiamate outbound o invio SMS di recall..);- realizzazione di un sistema di indicatori di tipo clinico, gestionale e organizzativo per monitorare la correttae la appropriata implementazione del processo di presa in carico.

Data la complessità dell’intervento, l’impatto sui processi primari di cura, e la necessità di preservarel’operatività del sistema nel corso del cambiamento, è richiesto che il Fornitore tenga opportunamente

13

conto delle attività di gestione del cambiamento in sede di pianificazione e identifichi una o più risorsereferenti a presidio di tutti i processi di change management.

7. PROPOSTE MIGLIORATIVESi precisa che le ipotesi migliorative andranno compiutamente descritte in termini organizzativi, funzionali etecnologici nella documentazione di progetto.Anche queste funzionalità dovranno sottostare ai requisiti di sicurezza definiti nelle altre sezioni delpresente documento e non dovranno comportare oneri aggiuntivi per la ASST Cremona.

8. CONSEGNA, IMPLEMENTAZIONE E GESTIONE DELL’INSTALLAZIONE DELLASOLUZIONE APPLICATIVA

CONSEGNA, RILASCIO IN TEST E IN PRODUZIONE.

Il fornitore dovrà impegnarsi a rilasciare gli ambienti di test e produzione in ambiente virtuale presso il DataCenter di LISPA completi di tutte le funzionalità previste nel presente documento e nel progetto tecnicopresentato in sede di offerta entro 15 gg dalla data di stipula del contratto.Le modalità di rilascio in produzione dovranno essere definite e concordate con i referenti dell’Ente e conLISPA e tutti i soggetti coinvolti dovranno essere opportunamente allineati allo scopo del rilascio.Ad ogni rilascio successivo dovranno essere definite e concordate con i referenti dell’Ente le strategie dirilascio in produzione delle funzionalità, e tutti i soggetti coinvolti dovranno essere opportunamenteallineati allo scopo del rilascio.L’ambiente di test fornito deve permettere di verificare gli impatti di modifiche e/o aggiornamenti sulcorrispondente sistema di produzione e sulle integrazioni in essere. In particolare:

dovrà essere specificata l’infrastruttura a supporto del suddetto ambiente di test; dovrà essere salvaguardata la separazione tra Ambiente di Test e Ambiente di Produzione. Ogni

modifica, a livello di ambiente applicativo o di prodotto standard, dovrà essere testata in termini dicompatibilità, funzionalità ed integrazione prima di essere rilasciata in produzione;

l’Ambiente di Test dovrà essere un ambiente non produttivo per testare gli effetti degli aggiornamenti direlease, di nuovi moduli e dei processi di gestione prima dell’installazione in produzione;

l’Ambiente di Test non dovrà interferire, in nessun caso, sull’ambiente di produzione e deve essereintegrato con gli altri Ambienti interessati al processo;

l’Ambiente di Test dovrà essere l’analogo all’ambiente di produzione, per garantire la validità delleverifiche eseguite;

il Fornitore si farà carico della gestione dell’Ambiente di Test che include: l’allineamento dell’ambiente,la verifica di aggiornamenti software (applicativi, sistemi operativi e software di base) e la verificadell’installazione di nuovo software.

CONFIGURAZIONE E GESTIONE DELL’INSTALLAZIONE DELLA SOLUZIONE PROPOSTA

Parallelamente alla fase di consegna, il Fornitore deve svolgere le attività di configurazione e gestionedell’installazione necessarie per il suo funzionamento a regime, coerentemente con gli obiettivi stabiliti,presidiando i servizi di formazione come specificati nei paragrafi successivi.Salvo accordi diversi in sede esecutiva, il Fornitore dovrà provvedere, a proprio esclusivo onere, a svolgeretutte le attività di installazione e configurazione della Piattaforma Software. Il fornitore dovrà inoltrecollaborare con LISPA per la predisposizione dell’ambiente tecnologico di supporto (server applicativi, DB,…)sia per l’ambiente di test sia per l’ambiente di produzione.

14

Il Fornitore dovrà provvedere, a proprio esclusivo onere, a svolgere tutte le attività di configurazione dellasoluzione e quindi:

alla configurazione del sistema e alla sua personalizzazione coerentemente con i processi e iflussi di lavoro da implementare;

alla implementazione della documentazione e della modulistica gestita dall’applicativo;

alla inizializzazione del sistema con le anagrafiche e le codifiche necessarie per abilitare lapersonalizzazione del sistema da parte del personale clinico;

alla verifica e messa in funzione del sistema.

COLLAUDO

L’Aggiudicatario è tenuto ad installare e consegnare all’ASST Cremona la Piattaforma Software entro 15(quindici) giorni dalla data di stipula del contratto. Al momento della consegna, si procederà al contempocon il collaudo tecnico della Piattaforma. Entro 45 (quarantacinque) giorni dalla stipula del contratto, dovràessere eseguito il collaudo funzionale della Piattaforma Software, al fine di consentire all’ASST Cremona:

di accertare l’aderenza del Software ai requisiti previsti nel presente documento e nel progettopresentato in sede di procedura di gara dall’Aggiudicatario;

di verificare sia la correttezza dei dati gestiti sia, dal punto di vista tecnico, il funzionamento e leprestazioni del Software medesimo;

di verificare le integrazioni applicative del sistema con il SISS sulla delle indicazioni presenti nel kitd’integrazione di RL/LISPA.

Dal collaudo funzionale è escluso il collaudo delle integrazioni con il Sistema Informativo della ASST diCremona, per le quali è fissato entro di 60 (sessanta) giorni a far data dalla stipula del contratto. Nell’eventualità che durante i collaudi si manifestassero malfunzionamenti addebitabili al Fornitore, odovessero essere rilevate delle non-conformità ai requisiti del presente Capitolato Tecnico, il Fornitore ètenuto ad effettuare i necessari interventi entro un massimo di 15 (quindici) giorni di calendario dalla datadai collaudi sopra indicati e presentare nuovamente il Software al collaudo. Il collaudo della fornitura, per il quale il Fornitore proporrà all’ASST un piano di test per ciascuna areafunzionale, dovrà essere effettuato sul sistema attivato secondo la programmazione definita dalcronoprogramma.Le attività di test si intendono concluse positivamente quando:

tutti gli errori rilevati siano stati opportunamente gestiti e corretti, salvo accordi diversi circa adesempio un tempo transitorio di adeguamento;

tutte le prove pianificate siano state eseguite con successo; tutte le integrazioni software con le componenti applicative precedentemente indicate.

A seguito dell’esito positivo delle attività di collaudo, verrà redatto e sottoscritto da entrambe le parti ilVerbale di collaudo attestante l’esito positivo del collaudo e contenente la dichiarazione di conformità ditutti i requisiti della Piattaforma Software rispetto a quanto indicato nell’offerta tecnica. Restaespressamente inteso che il Verbale di collaudo andrà a sostituire qualsivoglia precedente deliverablevalidato. La data del Verbale di collaudo funzionale con esito positivo verrà considerata quale data di accettazionedella fornitura ed inizio del periodo di manutenzione della durata di 36 (trentasei) mesi.Il regolare collaudo non esonera il Fornitore per eventuali vizi o difformità che non siano emersi in sede dicollaudo, ma che vengano rilevati e accertati dalla Stazione Appaltante per tutto il periodo contrattuale. Siprecisa che il Fornitore è tenuto a prestare gratuitamente, salvo che la causa sia imputabile a responsabilitàdell’ASST Cremona, ogni attività necessaria alla rimozione di vizi e difetti sul Software fino per tutto ilperiodo contrattuale.I collaudi dovranno essere effettuati alla presenza del SIA e degli utenti amministrativi e sanitari interessati edovrà risultare da apposito verbale sottoscritto dai presenti. Dovranno comportare tutte le prove e verifichedi accettazione e la conformità al tipo e ai modelli descritti nel presente capitolato tecnico.

15

9. FORMAZIONE DEL PERSONALE E AVVIAMENTOIl Fornitore deve prevedere un adeguato piano di formazione del personale (indicativamente tra 50 e 70operatori). I corsi, di tipo teorico-pratico, dovranno essere tenuti preso la sede dell’Azienda in date emodalità da concordare che tengano conto dell’inderogabile esigenza dell’Azienda di garantire la continuitàdei servizi offerti. La Formazione dovrà essere prevista per tutto il personalemedico/infermieristico/tecnico/amministrativo dell’ASST sulla base di una tabella dell’Organico che l’ASSTfornirà al Fornitore.Per gli operatori addetti alla gestione del sistema si richiede inoltre l’illustrazione con applicazioni pratichedi tutte le funzioni operative dei sistemi da installarsi suddivise per ogni modulo funzionale e supportareattivamente il personale operativo nell’ambito del profondo cambiamento.L’attività volta a trasferire il know-how, sia agli utenti sia agli amministratori del sistema, deve prevedere:

- la predisposizione di manuali di gestione e dei manuali utente che verranno usati a supporto dellaattività di formazione;

- l’addestramento degli utenti utilizzatori del sistema, suddivisi per tipologia funzionale, compresi gliutenti dei 10 Enti Erogatori (pubblici e privati) che usufruiranno della Piattaforma;

- l’addestramento di figure di Tutor (key user) che possano a loro volta addestrare gli utenti all’utilizzodel sistema la predisposizione del materiale didattico da utilizzare per l’attività di addestramentodegli utenti;

- l’addestramento degli utenti gestori, del personale addetto all’help desk e di figure selezionate dellafunzione SIA.

La formazione sopracitata, in particolare per le sessioni dedicate agli amministratori deve avere contenuti emodalità idonee a garantire la loro autonomia lavorativa. Si chiede inoltre che la formazione effettuata consenta il raggiungimento dei seguenti obiettivi:

1. corretto utilizzo dei sistemi da parte dell’utente, al fine di consentire l’uso appropriato di tutte lefunzionalità disponibili;

2. cpprendimento, da parte dell’utente, delle nuove modalità operative caratterizzate dal ricorso allamoderna tecnologia, rispetto alle usuali prassi sinora adottate.

Il Fornitore è tenuto a predisporre la manualistica utente completa accessibile on-line dalla PiattaformaSoftware.Si richiede al Fornitore una proposta complessiva relativa all’attività di addestramento che descriva:

- la metodologia adottata per la progettazione del percorso formativo e per la progettazione delmateriale didattico che sarà fornito a supporto,

- gli strumenti utilizzati- le modalità di erogazione dei servizi di formazione in relazione al piano di avviamento in

esercizio del sistema.Il concorrente dovrà predisporre un piano di formazione, da completare entro 60 giorni dalla di stipula delcontratto, indicandone tempi e modalità. La formazione dovrà essere avviata anche nella fase di rilascio inproduzione della Piattaforma Software al fine di contenere al massimo i tempi di messa a regime delsistema utilizzando opportuni ambienti di test preconfigurati.La strategia di comunicazione e formazione sarà oggetto di valutazione da parte dell’Ente.Il fornitore dovrà inoltre garantire per un periodo congruo dopo la messa in produzione del sistema, minimouna settimana, la presenza diretta sul campo di personale con competenza adeguata ad affiancare gli utentinella fase di avvio all’utilizzo del software. Dovrà anche prevedere un supporto telefonico dedicato per unperiodo di almeno tre settimane.

16

10. SERVIZI DI MANUTENZIONE

L’Aggiudicatario è tenuto a garantire i servizi di manutenzione e di assistenza tecnica della PiattaformaSoftware per un periodo pari a n. 36 mesi, a far data dal collaudo funzionale, durante il quale le attivitàsotto elencate dovranno essere erogate senza oneri per la ASST Cremona.Specificatamente, la manutenzione del Software deve comprendere le seguenti tipologie:

1. Manutenzione Correttiva: comprendente la correzione di errori software e/o anomalie difunzionamento (blocchi, comportamenti anomali, ecc.), segnalati al servizio di assistenzaoggettivamente riscontrabili, alla quale seguirà il rilascio di patch o nuove release della PiattaformaSoftware.

2. Manutenzione Normativa: comprendente le modifiche della Piattaforma Software necessarie peradeguarlo a nuove disposizioni di legge che dovessero entrare in vigore a carattere nazionale e/oregionale. In particolare, essendo il progetto regionale di gestione della presa in carico dei pazienticronici ancora in fase di definizione, l’Aggiudicatario è tenuto ad offrire adeguata ManutenzioneNormativa in favore dell’ASST Cremona, al fine di recepire le indicazioni che verranno fornite infuturo da Regione Lombardia (inclusi gli adeguamenti alle eventuali evoluzioni delle piattaformaregionale di integrazione e dei metodi di integrazione pubblicati da Lombardia Informatica) e,conseguentemente, sarà tenuto a provvedere all’adeguamento del Software, entro i tempi impostidalla normativa.

3. Software Assurance: comprendente il rilascio di nuove release del sistema per aggiornamenti dinatura funzionale o migliorie di prodotto utili all'evoluzione del sistema offerto.

4. Manutenzione Evolutiva: Il fornitore si dichiara disponibile ad effettuare aggiornamenti funzionaliderivanti da modifiche organizzative interne alla ASST Cremona o richieste di nuove funzionalitàsoftware. Tali modifiche verranno valutate insieme al fornitore e quantificate economicamente almomento della richiesta.

Si precisa che il servizio di assistenza tecnica potrà essere erogato, a seconda delle necessità, attraversocollegamento remoto o attraverso intervento tecnico on site da parte di tecnici specializzati e autorizzati aseconda della tipologia del disservizio. Il numero di chiamate per interventi di assistenza e manutenzione è da ritenersi illimitato.Il servizio dovrà essere erogato anche ai 10 Enti Erogatori (Pubblici e Privati), utilizzatori della piattaforma.Il valore economico del servizio di manutenzione non dovrà essere superiore al 20% annuo dell’importocomplessivo della fornitura.

A seguito della adesione della ASST Cremona al progetto di Razionalizzazione dei data Center delle AziendeSanitarie Lombarde, il Fornitore dovrà dichiarare la sua disponibilità al contatto diretto con i gestori del DataCenter di LISPA per problemi ad esso collegati.

SISTEMA DI HELP-DESK E TROUBLE TICKETING

Al Fornitore è richiesto di mettere a disposizione un sistema di help-desk per il supporto applicativo. Ilservizio deve essere sempre attivo nelle fasce orarie definite per i servizi di assistenza.

• Trouble Ticketing, per la gestione delle richieste di modifica e intervento provenienti sia da partedegli utenti del sistema che da parte del personale tecnico, mantenendo una base dati di tutti glieventi legati a una segnalazione, dallo stato di avanzamento, ai documenti correlati alle singoleprestazioni rese. Il sistema di ticketing deve essere opportunamente categorizzato in termini ditipologia di richiesta. Deve essere prevista una procedura chiara di gestione dei ticket che permettala definizione delle tempistiche di evasione delle richieste.

17

• Controllo Remoto, per gli interventi di controllo e manutenzione da remoto. Per garantire lamassima tempestività e capacità di monitoraggio ed assistenza da remoto deve essere previsto unaccesso VPN che verrà definito nei particolari operativi con il Fornitore.

11. EXIT STRATEGY

Quando l’accordo è risolto per qualsiasi ragione o è scaduto, tutti gli accessi devono essereimmediatamente revocati. Tutte le informazioni e i dati devono essere restituiti all’ASST nelle attività dimigrazione dei dati nel nuovo sistema dell’ASST. Tutti i dati dovranno essere adeguatamente eliminati dandone formale evidenza all'ASST Cremona e ciò noncomporta nessun onere aggiuntivo per l’azienda.

12. SERVICE LEVEL AGREEMENT (SLA)Il presente paragrafo riporta i Service Level Agreement (SLA) che saranno contrattualizzati nell’ambito deiservizi richiesti. I livelli minimi di servizio che devono essere garantiti sono dettagliati nella tabella diseguito.

ServiziPeriodo di copertura dell’assistenza

Lun-Ven SabatoHelp/Service Desk 7:30 – 18:00 8:00 – 13:00

Interventi on-site (su chiamata) 9:30 – 18:00 ==

In riferimento alla tabella sottostante, per:

“Tempo di intervento” si intende la presa in carico e la prima analisi del problema omalfunzionamento da parte del Fornitore.

“Tempo di ripristino” si intende il tempo massimo concesso, dopo la presa in carico del problema,per la risoluzione definitiva o temporanea dello stesso.

Di seguito sono riportate le tempistiche utilizzate come indicatori per la valutazione degli SLA specificate pergrado di urgenza; l’urgenza è valutata sulla base della criticità del componente e sul livello gravità del bloccodelle funzionalità del sistema e del disagio recato all’organizzazione.

Per interventi effettuati su componenti ad alta criticità, i tempi indicati sono relativi alle 24h, per i guasti amedia e bassa criticità il tempo indicato è relativo all’orario di assistenza/presidio sopra indicato.

Grado di urgenza Tempo diintervento

Tempo di ripristino o diapplicazione di soluzione

temporaneaCritico (problema bloccante): più utenti non sono in grado di svolgere l’attività con i sistemi ICT previsti

½ ora 2 ore

Alto (problema bloccante): un utente non è in grado di svolgere l’attività con i sistemi ICT previsti

2 ore 4 ore

Medio (problema non bloccante): l’utente è in grado di svolgere l’attività ma in modo degradato

1 giornolavorativi

2 giorni lavorativi

Basso (problema non bloccante): l’utente è in grado di svolgerel’attività senza avvertire in modo significativo il degrado

3 giornilavorativi

4 giorni lavorativi

Programmabile richiesta di supporto tecnico specialistico 5 giornilavorativi

Da concordare

18

Il fornitore dovrà garantire un uptime del sistema pari al 99,8% su base mensile (il calcolo dell’uptime el’eventuale applicazione di penali non è applicabile per interventi programmati e concordati con l’ASSTCremona). Le interruzioni di servizio considerate saranno solo quelle relative alle componenti di competenza delFornitore. Saranno, quindi, esclusi i disservizi causati da malfunzionamenti delle componenti gestite dalData Center Regionale, della rete ASST e delle postazioni di lavoro.

13. PENALI

Penali legate agli SLA definiti nel paragrafo 12

Grado di urgenza Tempo di intervento PenaleCritico ½ ora

10 per 1000 del valore complessivo del servizio di manutenzione per ogni ora lavorativa di ritardo

Alto 2 oreMedio 1 giorno lavorativiBasso 3 giorni lavorativiProgrammabile 5 giorni lavorativi

Grado di urgenza Tempo di ripristino o di applicazionedi soluzione temporanea

Penale

Critico 2 ore20 per 1000 del valore complessivo del servizio di manutenzione per ogni ora lavorativa di ritardo

Alto 4 oreMedio 2 giorni lavorativiBasso 4 giorni lavorativiProgrammabile Da concordare Non applicabile

Penali legate ai tempi di realizzazione del progetto

Parametro Valore target Valorizzazione della penale

Consegna, installazione, configurazione, attivazione e collaudo tecnico della piattaforma applicativa

15 giorni dalla data disottoscrizione delcontratto

20 per 1000 del valore complessivo della offerta economica per ogni giorno di ritardo

Collaudo Funzionale 15 giorni dalla data disottoscrizione delcontratto

20 per 1000 del valore complessivo della offerta economica per ogni giorno di ritardo

Secondo collaudo (relativamentead entrambe i punti precedenti)

15 giorni dalla data delprimo collaudo con esitonegativo

50 per 1000 del valore complessivo della offerta economica per ogni ulteriore giornodi ritardo

Realizzazione e collaudo integrazioni con i sistemi informativi della ASST e SISS

60 giorni dalla stipula del

contratto

10 per 1000 del valore complessivo della offerta economica per ogni giorno di ritardo

19

14. CRITERI DI AGGIUDICAZIONEL’aggiudicazione avverrà secondo i criteri di cui all’art. art. 95 del Dlgs 50/2016 e smi, a favore delconcorrente che avrà presentato l’offerta economicamente più vantaggiosa, valutata, ad insindacabilegiudizio della Commissione, sulla base dei seguenti criteri di valutazione:

CRITERIO PUNTEGGIO

PREZZO 30QUALITA’ 70

TOTALE PUNTEGGIO 100

A sua volta il punteggio relativo al “Criterio qualità” è distinto nei sotto indicati sub-punteggi:

ELEMENTO VALUTAZIONE PUNTEGGIOmax

1

Competenze del concorrente

Sarà valutata l’esperienza maturata nel periodo 2014-2017 disupporto informativo e organizzativo nell’ambito della gestione deipercorsi di cura e della presa in carico della cronicità con particolareriferimento al numero e al dimensionamento dei progetti gestiti,nonché alla loro rilevanza strategica. Verranno, altresì, valutate lecompetenze nella gestione di progetti change management tecnicoed organizzativo di sistemi informativi complessi ed integratioperanti in ambiente ospedaliero e territoriale (sanitario e sociosanitario). Verrà valutato il modello metodologico di gestione delprogetto sia in termini di copertura del processo di cambiamentoorganizzativo, sia tecnologico. Verranno valutati le capacità digestione di progetti complessi in termini di tempi proposti, attività edeliverables prodotti.

10

2

Requisiti funzionali dellapiattaforma software

Verranno valutati gli elementi funzionali della piattaforma softwarecon particolare attenzione ai seguenti punti:

profondità, flessibilità e semplicità di configurazione ecapacità di configurare le logiche di workflow e le regole digestione del processo/ruoli/attività;

ricchezza funzionale, orientata alla gestione della filieraerogativa e del supporto a tutte le componentiorganizzative e di equilibrio funzionale tra le stesse;

funzionalità utili alla gestione efficace delle attività; condivisione delle informazioni fra operatori e fra operatori

e pazienti.

15

Verranno valutati gli elementi di integrazione e interoperabilità ed inparticolare:

modalità di integrazione interne alla ASST dellasoluzione proposta, relativamente agli impattiorganizzativi ed economici che queste comportano;

interoperabilità con la piattaforma SISS;

10

20

modalità di integrazione verso soggetti esterni pubblicie privati coinvolti nella filiera erogativa del processo dipresa in carico della cronicità.

3

Requisiti non Funzionali

Verranno valutati i seguenti elementi:

gestione degli accessi al sistema; Componenti di gestione della tracciabilità di processo; requisiti della architettura della Piattaforma Applicativa.

5

4

Gestione del cambiamentoorganizzativo e Project

Management

Verranno valutate le fasi del progetto volte a supportare l’ASST nelprocesso di presa in carico dei pazienti sia da un punto di vistainformatico che organizzativo attraverso l’attività di ProjectManagement. Verranno quindi valutate le potenzialità di gestionedel cambiamento organizzativo per le diverse fasi del processo(dall’arruolamento all’organizzazione del percorso di cura e almonitoraggio). Verranno valutate, altresì, le componenti di supportoal funzionamento del centro servizi interno e integrato con gli altriEnti erogatori pubblici e privati.

10

5

Proposte migliorative

Verranno valutate eventuali proposte migliorative, attinentiall’oggetto dell’appalto, che il concorrente riterrà di formulare. 5

6

Sistema di monitoraggio

Verrà valutato il sistema di monitoraggio reso disponibile e gliindicatori sviluppati in coerenza o migliorativo rispetto a quantoindicato nel capitolato tecnico

5

7

Piano di avviamento e Servizi distart up del Software, formazione

assistenza e manutenzione

Verranno valutati seguenti elementi: consegna, implementazione e gestione dell’installazione

della Piattaforma Applicativa; formazione del personale e avviamento; cronoprogramma proposto; Servizi di manutenzione compreso il servizio offerto per la

gestione di Help Desk e Troble Ticketing.

10

21

Allegato 1:

Architettura di riferimento Data Center Regionale

Premessa

Obiettivo del presente documento è fornire un framework architetturale di riferimento, la Reference Architecture (RA),volto a definire le linee guida per la progettazione delle architetture esecutive dei sistemi.La RA ha il compito di disegnare le soluzioni target standardizzando le configurazioni e le componenti architetturali, inaccordo con le strategie di evoluzione di LI.

Le soluzioni target definite sono suddivise in 2 categorie:

Standard, architettura di destinazione ottimale desiderata per la trasformazione

Near Standard, soluzione sub ottimale per l’architettura target, costituisce la trasformazione minima accettata.

La architettura alla quale si dovrà adeguare il fornitore è la architettura standard

Di seguito vengono esplicitati i di modelli architetturali per le principali componenti di servizio.Per ogni modello architetturale viene fornita una architettura logica, intesa come modello logico di riferimento dovevengono introdotte le componenti logiche dell’architettura esecutiva proposta per il componente e relativa topologia.Per ogni architettura logica vengono poi definiti diversi design pattern, intesi come implementazione delle architetturelogiche sulle diverse piattaforme esecutive.

Driver

I driver che hanno guidato la definizione delle Architetture di Riferimento sono raggruppabili in due aree principali: Razionalizzazione delle Componenti Esecutive:

◦ Standardizzazione/Omogeneizzazione: razionalizzazione delle Componenti Esecutive (Web Server,Application Server, Database & Middleware,…) con l’obiettivo di omogeneizzare e ridurre il numero ditecnologie utilizzate

◦ Consolidation Architetture: riduzione del numero di componenti esecutive attraverso right sizing delledell’architettura esecutiva, in linea con i requisiti di business

◦ Centralizzazione: condivisione e riuso delle risorse, migrazione delle componenti verso infrastrutturecentralizzazione

Ottimizzazione delle ‘Level Qualities’.◦ Service Level: adeguamento architetturale focalizzato sulla percezione del servizio dell’utente finale

(Availability, Reliability, Performance)◦ System Level: adeguamento architetturale focalizzato sulla manutenibilità del sistema (Maintainability,

Manageability, Security, Serviceability)◦ Strategic Level: adeguamento architetturale focalizzato sulla capacità di una architettura di cambiare

nel tempo rispetto ad evoluzioni del business (Scalability , Flexibility)

Scopo e campo di applicazione

La RA è rivolta a definire l’architettura esecutiva di un nuovo sistema o avviare un upgrade tecnologico di architettureesistenti relativamente alle componenti IT esecutive che erogano uno specifico servizio .Componenti di Servizio:

Presentation: Layer di presentazione, costituito da Web server e Load Balancer. Include i plugin perl’autenticazione e l’ autorizzazione e bilanciamento delle applicazioni. L’alta affidabilità del Frontendrealizzata mediante load balancer Hardware o Software

Application Server: Layer costituito dagli application server che supportano le applicazioni, realizzando lalogica di business per cui sono sviluppate.

Data Layer: Layer costituito dai Database Server e dalle componenti di Data & Information Management

22

volto ad erogare i servizi di accesso e gestione dei dati

Operating System: Layer costituito dai Sistemi Operativi realizzato sulla infrastruttura

Modelli Architetturali

Di seguito vengono identificati una serie di modelli architetturali per le componenti di servizio sopra elencate..Per ogni modello architetturale viene fornita una architettura logica, intesa come modello logico di riferimento dovevengono introdotte le componenti logiche dell’architettura esecutiva proposta per il componente e relativa topologia.

Presentation Layer

Layer di presentazione, costituito da Web server e Load Balancer.Di seguito vengono rappresentate le Componenti di Servizio in ambito Presentation Layer:

Apache Http Web Server Internet Information Server

Per ciascuna componente sono state identificate le Modelli Architetturali Standard e Near Standar.

Apache Http Server

Apache http Server viene normalmente utilizzato in associazione con il software shibboleth per la gestione dei criteri di sicurezza degli accessi e per la gestione delle autorizzazioni.

Internet Information Server (IIS)Le versioni Internet Information Server (IIS) previste come riferimento sono le seguenti:

IIS 8.X – configurazione Near Standard IIS 10 o superiore – configurazione Standard

23

Application Layer

Layer di presentazione, costituito dagli Application Server. Il modello di riferimento per Application Layer è costituito dal prodotto:

Red Hat JBoss Enterprise Apache Tomcat Oracle Java JDK Internet Information Server Mirth connect (utilizzato solo per le ASST)

Modelli Architetturali Standard e Near Standar per Red Hat JBoss Enterprise

Apache Tomcat Le versioni Apache Tomcat Lispa (versione Custom di Apache) previste come riferimento sono le seguenti:

Tomcat Lispa Custom 2 – configurazione Near Standard Tomcat Lispa Custom 3 o superiore – configurazione Standard

Apache Tomcat (dalla verisone 6 a seguire) sono da considerarsi in configurazione Near Standard in quanto LISPA hadeciso di utilizzare il Tomcat Lispa Custom come standard.

Oracle Java JDK Le versioni Oracle Java JDK previste come riferimento sono le seguenti:

Oracle Java JDK 1.7 – configurazione Near Standard Oracle Java JDK 1.8 – configurazione Standard Oracle Java JDK 1.9 – configurazione Standard

Internet Information Server (IIS)Le versioni Internet Information Server (IIS) previste come riferimento sono le seguenti:

IIS 8.X – configurazione Near Standard IIS 10 o superiore – configurazione Standard

Data Layer

Le versioni di riferimento per Data Base Layer sono le seguenti:

Soluzione Linux based:

▪ Oracle Database Enterprise Edition 12.1 o superiore. In caso di soluzioni HA è previsto l’utilizzo di OracleGrid Infrastructure 12c con ausilio di ASM (Automatic Storage Management)

24

▪ PostgreSQL 9.x Database o PostgreSQL 10.x

Soluzione Microsoft based:

◦ MS SQL Server 2012 o superiore (supportata con SO Windows 2012 o successive).

Windows Server 2016 DataCenter

Operating System

Le versioni di riferimento per i Sistremi Operativi sono:

Soluzione Linux based: RedHat Linux Enterprise Linux 6.x. RedHat Linux Enterprise Linux 7.x. Oracle Linux 5.11 o superiore

Soluzione Solaris based: Oracle Solaris 11

Soluzione AIX based: AIX Enterprise Edition 6.1.0 e 7.1.0 o superiore

Soluzione Microsoft based: Windows Server EE 2012 o superiore (solo versioni Enterprise

Edition) Windows Client 7, 8, 10

Per garantire il corretto supporto delle attività di gestione operativa, su ciascuna macchina fisica vi è la presenza di agent:

Antivirus Backup Monitoraggio, Allarmistica Performance Update

Virtualization

25

Le versioni di riferimento per le Piattaforme di Virtualizzazione sono:

Soluzione Vmware: Vmware ESXi 6 o superiore Vcloud Suite 6 o superiore Vcenter 6 o superiore

26