PROCEDURA RISTRETTA PER L’AFFIDAMENTO DEL

REGIONE AUTONOMA DELLA SARDEGNA ASSESSORATO DELL’IGIENE E SANITA’ E DELL’ASSISTENZA SOCIALE

Direzione Generale della Sanità

Servizio Affari Generali e Istituzionali e Sistema Informativo

“PROGETTO SISTEMA INFORMATIVO SANITARIO INTEGRATO REGIONALE SISAR”.

RISPOSTE AI QUESITI FORMULATI – 02/02/2007

QUESITO	RISPOSTA AL QUESITO
Si chiede di chiarire se nella dichiarare se nella dichiarazione da inserire nella busta A1 a firma del procuratore speciale si deve far riferimento all’art. 26 o come riportato nel modello allegato A1 par. 2 all’art. 27 capitolato.	Si conferma il riferimento all’art. 27 del capitolato d’oneri. Gli obblighi di cui all’art. 26, infatti, attengono a disposizioni normative di rilievo nazionale a cui comunque tutte le ditte devono attenersi nella redazione dell’offerta.
La durata dell’appalto è fissata in 24 mesi, decorrenti dalla data di stipulazione del contratto; resta inteso che l’Aggiudicatario resta vincolato per tutto il periodo di garanzia dell’intera fornitura. Domanda: Xx chiede di chiarire se il periodo di 24 mesi è da intendersi al netto di ritardi non imputabili al fornitore e se eventuali ritardi dovuti al committente siano oggetto di compensazione a favore del fornitore	Il termine di 24 mesi è riferito alla durata dell’appalto al netto di eventuali ritardi non imputabili al fornitore
Resta fermo che l’approvazione degli stati di avanzamento non comporta accettazione definitiva, ai fini e agli effetti previsti dal presente capitolato, delle forniture dei beni e servizi resi, che resta subordinata all’esito positivo del collaudo, in corso d’opera e finale, di cui all’art. 39. Domanda: Si chiede di chiarire se il riconoscimento dei corrispettivi sarà definito solamente a collaudo finale/parziale positivo.	Il riconoscimento dei corrispettivi sarà definito a seguito dell’approvazione degli Stati di Avanzamento del Direttore dei Lavori e/o Commissioni di Collaudo
Manutenzione evolutiva e adeguativa per ciascun	La manutenzione deve essere resa anche nel periodo di erogazione

sottosistema oggetto della fornitura e delle componenti di integrazione con i sottosistemi non oggetto della fornitura per il periodo contrattuale.

Si chiede di chiarire se la manutenzione è compresa sia nella fase di realizzazione che nella successiva fase di erogazione.

La realizzazione di un Centro servizi regionale (CRESSAN) a supporto del CUP integrato per le Aziende Sanitarie ed Ospedaliere comprensivo del servizio di prenotazione telefonica (tale servizio di prenotazione telefonica verrà svolto organicamente e prevalentemente nell’ambito degli attuali Call Center delle Aziende n. 8 di Cagliari, n. 1 di Sassari e n. 3 di Nuoro; verranno anche impiegati i sistemi di gestione delle chiamate attualmente presenti ed in funzione presso le altre Aziende;

Domanda: Si chiede di chiarire l’effettivo affidamento del servizio di Call Center, in quanto il testo riportato contrasta con quanto descritto a pag. 66 del documento “SISaR – Disciplinare”, paragrafo 6.3.6.3 in cui:

7 monitoraggio delle attività di Call-Center per la prenotazione e la disdetta telefonica di appuntamenti, nonché per l'informazione all'utenza (il servizio di Call Center è affidato alle Aziende sanitarie di Sassari e Cagliari);

Nel caso di servizio presso le province, si chiede di chiarire se la soluzione sia prevista per l’intera distribuzione territoriale dei CUP

Il contenuto del disciplinare al punto 7 del paragrafo 6.3.6.3 (pagina 66) va inteso come riportato nel paragrafo 6.3.6 a pag 63 dello stesso disciplinare, al punto 1, penultimo capoverso della stessa pagina. In tale punto si afferma che il servizio di prenotazione telefonica verrà svolto prevalentemente dagli attuali call center delle ASL di Cagliari, Sassari e Nuoro. Si afferma anche, nello stesso punto 1 di pag. 63 del disciplinare, che verranno anche impiegati i sistemi attualmente presenti ed in funzione presso le altre aziende.

Disaster Recovery

Per definire efficacemente una soluzione di

Disaster Recovery occorre individuare quelli che sono i punti critici del sistema informatico da proteggere, che nel caso del progetto in esame sono principalmente i seguenti:

- Server Centrali di Produzione

- Applicativi Software.

Domanda: Si chiede di chiarire se i server centrali e gli applicativi software gestiti dalla soluzione di Disaster Recovery debbano essere sia quelli presenti nel CRESSAN, sia quelli presenti nelle Aziende Ospedaliere.

In caso affermativo indicare i server/applicazioni delle AO.

Si rimanda alla progettualità della proposta tecnica che il concorrente farà pervenire al riguardo.

Il sistema di DS e BC richiesto deve riguardare l’intero dominio applicativo oggetto di fornitura.

Al fine di pervenire ad un efficiente impiego di risorse umane

e di tecnologie disponibili, nella progettazione e gestione del

La descrizione dei sistemi telefonici impiegati

presso le ASL/AO è la seguente:

sistema dovranno comunque essere utilizzati anche i sistemi di gestione delle chiamate telefoniche per il servizio CUP aziendale, che attualmente operano presso tutte le Aziende Domanda: Si chiede di descrivere i sistemi telefonici attualmente utilizzati nelle ASL/AO per l’erogazione del servizio CUP al fine di valutane l’effettiva possibilità di integrazione con la soluzione innovativa proposta.

Si chiede inoltre di fornire la durata media delle chiamate giunte presso i Call Center, per un adeguato dimensionamento.

ASL 1: non esiste piattaforma sw ma soltanto un centralino che smista le chiamate

ASL 3: esiste una gestione informatica del call center che si basa sulla piattaforma Linux.

Vengono gestite le code con ripartizione automatica verso gli operatori liberi del Call Center. Il sistema gestisce gli orari di apertura, di chiusura, di attesa e di occupato in automatico. Fornisce statistiche sulle chiamate e sull'attività degli operatori. Il sistema telefonico è associato ai PC degli operatori che visualizzano e permettono di gestire le chiamate in entrata.È un sistema di Call Center che attualmente gestisce 6 operatori e un supervisore, ma può arrivare fino 199 operatori.

ASL 8: la piattaforma utilizzata presso il Call Center C.U.P. di questa ASL è basata su una soluzione Siemens Telematica che prevede un Centralino Siemens Hicom 330 per la componente hardware, mentre la componente software utilizzata per la gestione delle chiamate da parte degli operatori è il Pro- Center - HPPC installato su Server Fujtsu- Siemens Primergy con s.o. Windows 2000 Server.

Per quanto riguarda la stima della durata media delle chiamate si rimanda alla proposta tecnica che il concorrente farà pervenire al riguardo, tenuto conto che rappresenta un dato che dovrà essere oggetto sia della

proposta che di valutazione.

Caratteristiche minime server per progetto MEDIR

Alla luce del fatto che le più recenti CPU dual-core non raggiungono il clock di 3,6 GHz, possono essere impiegate CPU con clock più basso, ma complessivamente più performanti delle CPU richieste ?

La configurazione proposta nell’Allegato 4 ha valore indicativo.

La soluzione proposta dalla Società in sede di offerta per quanto riguarda la fornitura di ’HW e SW di base deve possedere caratteristiche analoghe o migliorative rispetto a quelle

stabilite in sede di disciplinare.

Caratteristiche minime stazioni di lavoro per progetto MEDIR

Viene richiesta una CPU con clock a 3 GHz, senza altri vincoli; può essere utilizzata una CPU dual core, ma con clock inferiore ?

La configurazione proposta nell’Allegato 4 ha valore indicativo.

La soluzione proposta dalla Società in sede di offerta per quanto riguarda la fornitura di ’HW e SW di base deve possedere caratteristiche analoghe o migliorative rispetto a quelle

stabilite in sede di disciplinare.

Caratteristiche minime dell’HW

A supporto della piattaforma SPCR-SPCoop vengono richiesti server basati su tecnologia Intel 64bit con 4 processori ciascuno.

L’ indicazione “Intel 64bit” comprende anche CPU x86-64 bit compatibili, potendo quindi utilizzare anche CPU AMD Opteron ?

L’ indicazione “4 processori” è da intendersi come “4 core”, potendo quindi ad esempio utilizzare server con 2 CPU dual- core ?

La configurazione proposta nell’Allegato 4 ha valore indicativo.

La soluzione proposta dalla Società in sede di offerta per quanto riguarda la fornitura di ’HW e SW di base deve possedere caratteristiche analoghe o migliorative rispetto a quelle stabilite in sede di disciplinare.

Adeguamento HW e SW di base del Data Center del Centro Servizi Regionale - CRESSAN

Il datacenter del CRESSAN ed il CRESSAN stesso, risiedono nella stessa sede fisica ?

Se no, qual è la modalità di interconnessione prevista tra il Data Center e il CRESSAN?

Il nuovo Data Center prevede un accesso diretto a Internet? Eventuali sistemi di firewalling e/o IDS/IPS sono oggetto di fornitura?

Il Data Center del CRESSAN ed il CRESSAN possono risiedere su due sedi diverse, nell’ambito della stessa città di Cagliari. In questo caso, le modalità di interconnessione che saranno adottate si basano su canali trasmessivi a Larga Banda realizzati in fibra ottica.

Il Data Center che ospiterà la piattaforma tecnologica del CRESSAN disporrà di un proprio collegamento ad internet.

Per la fornitura di sistemi firewalling ed

IDS/IPS si rimanda all’offerta tecnica del concorrente.

Servizio di backup-recovery remoto

Il servizio di backup-recovery remoto a supporto delle applicazioni installate presso le Aziende, può essere inteso come un puro servizio di emergenza, per sopperire alla caduta dei sistemi di backup locali installati presso le Aziende

stesse, come previsto dal progetto MEDIR ?"

Si rimanda alla progettualità dell’offerta tecnica del concorrente, tenendo conto che la scelta progettuale è oggetto di valutazione dell’offerta che verrà presentata.

Progettazione del Disaster Recovery

Nel caso di ripartenza entro 45 min e 15 min rispettivamente per le applicazioni amministrative e sanitarie, quale profondità storica di dati si è disposti a perdere?

Si rimanda alla progettualità dell’offerta tecnica del concorrente, tenendo conto che la scelta progettuale è oggetto di valutazione dell’offerta che verrà presentata.

Potenziamento dei Call Center delle ASL

Qual è la piattaforma attualmente in uso per il sistema di Call Center delle ASL di Cagliari, Sassari e Nuoro?

ASL 1: non esiste piattaforma sw ma soltanto un centralino che smista le chiamate

ASL 3: esiste una gestione informatica del call center che si basa sulla piattaforma Linux.

Criteri generali del capacity planning

dal DISCIPLINARE:

“Le risorse che dovranno essere messe a disposizione dalla fornitura, sia per il CRESSAN che a livello di ciascuna Azienda, dovranno essere idonee a supportare il corretto esercizio delle attività del SISaR per il periodo di cinque anni

decorrenti dalla data di messa in produzione e collaudo dei

1) I sistemi dovranno essere dimensionati secondo le indicazioni del disciplinare (5 anni).

2) La stima del volume dei dati iniziale e del bacino di utenza deve essere effettuata tenendo conto dei criteri di dimensionamento posti in ciascun allegato

per ciascun sottosistema del SISaR, e

sistemi informativi.”

dall’ ALLEGATO 7:

“Si richiede al fornitore che il dimensionamento ed il potenziale di queste risorse possa supportare:

1. l’incremento dell’occupazione di storage sia di dati che di programmi che si può verificare nel corso di almeno tre anni, durante i quali non si deve verificare il rischio di saturazione;

2. l’incremento dei carichi di lavoro per le cpu, dovuti ad un evolvere della richiesta di servizi che si può verificare sempre nel corso di almeno tre anni, che non può condurre alla situazione limite del potenziale previsto.”

I sistemi hardware forniti dovranno essere dimensionati per supportare un periodo di attività di almeno 5 anni, come indicato del disciplinare, oppure di 3 anni, come indicato nell’allegato 7 ?

Allo scopo di effettuare il suddetto dimensionamento occorre sapere:

1) Qual è la stima del bacino di utenza e del volume di dati iniziale che il sistema dovrà supportare

2) Qual è la stima dell’incremento annuo relativamente a numero di utenti e volume di dati da gestire?

sarà oggetto di valutazione della proposta di ciascun concorrente.

3) Il dimensionamento dei volumi di dati, ed in generale della piattaforma tecnologica proposta, che tenga conto dell’incremento nel tempo di produzione dei contenuti digitali, fa parte dell’offerta tecnica del con concorrente, ed è oggetto di valutazione dell’offerta.

Nodi di backbone delle MAN

I nodi di backbone RPR delle MAN di Cagliari e Sassari, sono coincidenti fisicamente (stessa sede) con le aziende oggetto di intervento ?

In altri termini, si chiede se per la MAN di Cagliari, i nodi della MAN stessa sono dislocati all’ interno di :

• ASL 8 Cagliari

• A.O. Brotzu Cagliari

• Policlinico di Cagliari

• CRESSAN

Mentre per la MAN di Sassari, i nodi della MAN stessa sono

La RTR della RAS consente l’interconnessione a larga banda al CRESSAN delle sedi interessate al SISaR di Cagliari e Sassari, ciascuna delle quali è dotata delle terminazioni della rete stessa.

dislocati all’ interno di :

• ASL 1 Sassari

• Policlinico di Sassari

Data di inizio delle attività progettuali

In riferimento alla data di inizio delle attività progettuali, il Disciplinare Tecnico, Paragrafo 7 pag. 72 – Tempistiche – specifica che “L’inizio del progetto decorre dalla data di approvazione del piano di lavoro definitivo”.

Sulla base di tale requisito, si chiede di chiarire se le tempistiche definite dal Disciplinare Tecnico e rispettivi Allegati in merito alla

• consegna dell’HW e de SW di base oggetto di fornitura,

• realizzazione del sistema informatico,

• installazione e test su un primo cluster di Aziende (primo rilascio),

• installazione sulle restanti Aziende (secondo rilascio),

• esecuzione di tutte le attività previste dal progetto decorrano a partire dall’approvazione del piano di lavoro definitivo.

Tutte le attività di progetto hanno inizio in corrispondenza della data di stipula del contratto. Il piano di lavoro definitivo dovrà prevedere come data di inizio progetto la data di stipula del contratto.

Sistema Informativo Veterinaria

In riferimento al Sistema Informativo Veterinaria , l’Allegato N. 5 del Disciplinare Tecnico, Paragrafo A.5.2.14.4 pag. 59, specifica che “Il sistema è unico a livello regionale, e verrà gestito nel nodo regionale del CRESSAN”.

In ragione di tale requisito, il SISaR-VET è da intendersi installato e dislocato fisicamente presso il Data Center del CRESSAN, ed accessibile quindi in outsourcing dalle ASL?

Il SISaR-VET viene installato centralmente presso il Data Center del CRESSAN.

Piattaforma di E-Learning

Qual è la piattaforma di E-Learning (denominazione, fornitore, tecnologia, ambiente di esecuzione, caratteristiche funzionali) attualmente in dotazione della Regione Sardegna, e che dovrà essere utilizzata nell’ambito del progetto secondo quanto specificato dall’Allegato N. 3 Paragrafo A.3.4.9 pag.

42?

Si tratta di una piattaforma che è in fase di sviluppo, basata sul protocollo SCORM, ecc.., e progettata in architettura Open source.

standard che i corsi devono rispettare sono

AICC, SCORM, IMS. La piattaforma è open

source.

Formazione

Esistono nell’ambito del CRESSAN, Regione, nonché delle Aziende Sanitarie, Ospedaliere e Policlinici Universitari regionali, aule / locali utilizzabili ai fini della formazione degli utenti SISAR sparsi sul territorio della Regione Sardegna? In tal caso si chiede di specificare la dislocazione di tali locali, e se questi siano attrezzati affinché possano essere erogati corsi di formazione in aula agli utenti dei sistemi oggetto di fornitura.

La definizione della domanda di logistica (sedi/locali) delle attività formative ed in particolare del Learning center del CRESSAN rappresenta un output della proposta del concorrente, da cui dovrà scaturire il fabbisogno di sedi/locali che verranno messe a disposizione dall’aggiudicatario. Le tecnologie di supporto a queste attività sono oggetto di fornitura

Schema di Dichiarazione

In riferimento allo Schema di Dichiarazione (Allegato A1), al punto “b” si cita: “Documento originale contenente l’impegno del garante a rinnovare la garanzia, su richiesta dell’Amministrazione, nel caso in cui al momento della sua scadenza non sia ancora intervenuta l’aggiudicazione” non è chiaro a cosa si riferisce la garanzia ivi citata.

E’ corretto interpretare la frase sopra riportata come facente riferimento ad una garanzia legata alla clausola compromissoria citata al punto “a” “Documento originale attestante la cauzione provvisoria cui all’art. 9 del Capitolato d’Oneri”?

L’osservazione è corretta. Il termine garanzia di cui al punto B dell’allegato A1 fa riferimento infatti alla cauzione provvisoria di cui all’art. 9 del Capitolato d’Oneri

Interfacce strumenti

In relazione agli strumenti da interfacciare per il centro trasfusionale si chiede di specificare per ogni presidio il numero di strumenti da interfacciare, per le due categorie seguenti:

1) bilance al prelievo, separatori cellulari, separatori cellulari di aferesi produttiva e terapeutica, frigoemoteche elettroniche, irradiatori, centrifughe;

2) strumenti analizzatori in generale.

Si rimanda alla progettualità dell’offerta del concorrente.

Costi Assistenza e Manutenzione Software Area Ospedaliera Esistente

Alla luce del requisito espresso nell’Allegato N. 4:

“Le Aziende che dispongono di propri applicativi per le

Ad integrazione e precisazione di quanto riportato nel seguente paragrafo dell’All. n. 4: “Le Aziende che dispongono di propri applicativi per le componenti indicate

nell’elenco con i numeri 1 (ADT – Ammissione

componenti indicate nell’elenco con i numeri 1 (ADT – Ammissione dimissione trasferimenti), 2 (PS – Gestione pronto soccorso), 5 (Gestione centro trasfusionale) possono esercitare l’opzione del mantenimento del sistema di cui già dispongono.”

si chiede di conoscere i dettagli relativi ai contratti di assistenza e manutenzione attualmente attivi nelle Aziende che dispongono di tali applicativi.

In particolare sono di interesse le seguenti informazioni:

1. condizioni economiche

2. data di scadenza

3. livelli di servizio definiti

4. tipologie di attività (es. help desk, manutenzione correttiva, evolutiva, ...) previste

5. modalità di esecuzione delle attività.

dimissione trasferimenti), 2 (PS – Gestione pronto soccorso), 5 (Gestione centro trasfusionale) possono esercitare l’opzione del mantenimento del sistema di cui già dispongono.” si comunica quanto segue: nella predisposizione dell’offerta le società partecipanti non dovranno tener conto della possibilità di opzione, che può essere esercitata da ciascuna Azienda successivamente all’aggiudicazione, di mantenere i propri sistemi attualmente in uso e di cui dispongono.

Si rimanda pertanto alle proposte progettuali di ciascun concorrente, che nella propria formulazione potranno tener conto della possibilità di mantenere i sistemi attualmente in uso, o di sostituirli con altri, nel rispetto dei requisiti funzionali e di integrazione posti dal

capitolato.

Numero di Poli-Ambulatori

Si chiede di specificare il numero di Poli-Ambulatori distribuiti sul territorio regionale, e per ciascuno di esso di specificare il numero di postazioni di lavoro?

Si rimanda alla progettualità dell’offerta del concorrente

Gestione ECM

In riferimento alla “Gestione ECM”, nell’ambito del SIA-HR, l’Allegato 3 specifica che:

“Il sistema informativo che verrà fornito dall’aggiudicataria dovrà essere in grado di integrarsi con il sistema informativo che la Regione Sardegna ha già avviato per la gestione dell’ECM,

e che verrà avviato entro il primo semestre 2007.”

Si chiede dunque di fornire le caratteristiche funzionali, architetturali e tecnologiche del Sistema Informativo che la Regione Sardegna ha già avviato per la Gestione dell’ECM.

Si tratta di un sistema informativo regionale basato su una architettura Open source, attualmente in fase di progettazione e sviluppo.

Con ECM qui si intende il sistema per la gestione degli accreditamenti dei corsi (frontali, on-line, etc.). La piattaforma di e- learning è distinta dal sistema per la gestione dell’ECM. I corsi devono essere realizzati in modo tale da essere interoperabili. In questo senso gli standard che i corsi devono rispettare sono AICC, SCORM, IMS. La piattaforma è open source.

Estensione Progetto Medir

In riferimento all’Estensione del Progetto MEDIR (vedi

A pag. 64 nel paragrado A.4.3.2 dell’Allegato Medir troviamo:

Allegato N. 4 Paragrafo A.4.3.2 pag. 64), si chiede se sia facoltà della Ditta Aggiudicataria proporre, per le Aziende coinvolte dal presente intervento, una soluzione applicativa alternativa che, garantendo la piena integrabilità e offrendo le medesime funzionalità previste dal progetto MEDIR, consenta una maggiore omogeneità ed uniformità tecnologica con l’intero Sistema Informativo Sanitario Regionale – SISaR oggetto di fornitura.

A.4.3.2 Estensione del progetto MEDIR – Rete dei MMG/PLS e Fascicolo sanitario

Per quanto riguarda le attività di change management, fermo restando che l’attività di manutenzione del sistema sw Medir sarà realizzato dalla Ditta che sta realizzando il sistema stesso, sono stati fissati i requisiti minimi. I principali requisiti minimi riguardano il servizio e i tempi di attivazione dell’help desk per le ASL non coperte dal primo intervento, il servizio di manutenzione correttiva del sistema che dovrà essere realizzato dalla Ditta che attualmente sta realizzando il sistema, la formazione, il supporto alla gestione del sistema, i convegni e le brochure da inviare agli Assistiti delle ASL non coperte dal primo intervento. Tutto quanto è migliorativo rispetto a questi requisiti minimi potrà essere proposto nell’offerta tecnica delle Ditte.

Per quanto attiene la fornitura di hw è invece richiesta la configurazione riportata nell’allegato; è possibile ovviamente migliorare la fornitura in termini di prestazioni ma ciò non deve prevedere cambiamenti della configurazione stessa del sistema; per quanto riguarda la configurazione del sw di base deve essere quella richiesta a meno degli adeguamenti tecnologici derivanti dall’eventuale messa fuori produzione dei sistemi stessi.

Per quanto attiene la soluzione applicativa, intendendo con questo il sistema sw del Fascicolo Sanitario Elettronico, questo non è oggetto della gara SISaR come già specificato nel disciplinare di gara 6.3.7.7 Completamento del progetto MEDIR: Il SW applicativo del Fascicolo Sanitario Elettronico, con le relative integrazioni con

i Sistemi Informativi presenti nelle Aziende

Sanitarie, e dei processi già previsti nel primo intervento non è oggetto di questa gara in quanto sarà già stato sviluppato nel primo progetto Medir in corso.

Inoltre a pag. 4 dell’all. 4 REQUISITI DEL SISTEMA INFORMATIVO SANITARIO

OSPEDALIERO è scritto: Si evidenzia che non potranno essere prese in considerazione offerte tecniche che prevedano la sostituzione fisica o anche funzionale dei sistemi regionali attualmente in corso di realizzazione, ed in questo caso dei sistemi ANAGS, RTP, MEDIR.

Inoltre, come scritto nel disciplinare a pag. 43 del cap. 6.1 Oggetto della fornitura è scritto: Il nuovo sistema informativo sanitario regionale dovrà essere progettato e realizzato in modo da integrarsi con tutti i sistemi i cui progetti sono in corso di attuazione quali: MEDIR, ANAGS, RTP, Tessera sanitaria, Sistema Informativo Assistenza Sociale, Gestione dei Sert, Gestione degli Screening oncologici, e , ove possibile, con i sistemi clinico – sanitari attualmente presenti nelle Aziende sanitarie.

Infine si sottolinea che il sistema Medir è

federato ma è unico e deve restare identico in tutte le Aziende Sanitarie.

Dotazione informatica

Nel disciplinare Tecnico viene specificata a dotazione informatica attuale delle diverse ASL/AO/Policlinici Universitari regionali coinvolte dal presente intervento progettuale, limitatamente ai soli servizi territoriali ed ospedalieri, tralasciando le componenti di area amministrativa. Si chiede pertanto di fornire informazioni di dettaglio (prodotto, fornitore, caratteristiche funzionali, architettura tecnologica, ecc…) in merito ai sistemi informativi di area amministrativa (protocollo,

contabilità, pianificazione e controllo, acquisti, magazzini,

I Sistemi informativi in uso presso le aziende sanitarie di cui è a conoscenza l’Amministrazione sono state inserite nei documenti di gara. L’onere di acquisire ulteriori informazioni necessarie sui sistemi informativi utilizzati dalle aziende sanitarie sono a carico delle Ditte concorrenti.

personale, ecc…) ad oggi adottati dalle diverse

ASL/AO/Policlinici coinvolti dal presente intervento

Opzioni di mantenimento

Le Aziende che dispongono di propri applicativi per le componenti indicate nell’elenco con i numeri 1 (ADT – Ammissione dimissione trasferimenti), 2 (PS – Gestione pronto soccorso), 5 (Gestione centro trasfusionale) possono esercitare l’opzione del mantenimento del sistema di

cui già dispongono. In questo caso il fornitore dovrà provvedere all’integrazione dei sistemi che vengono mantenuti con il sistema informativo sanitario ospedaliero del SISaR. A carico del fornitore rimane l’adeguamento dei sistemi da mantenere alle specifiche funzionali che fanno parte del presente disciplinare tecnico. Il fornitore dovrà aver cura di dotarsi, per questi sistemi che vengono mantenuti, di tutte le necessarie componenti previste per la interoperabilità con le applicazioni del SISaR che verranno individuate.

Con riferimento all’estratto della documentazione di gara sopra riportato, si chiede di meglio precisare le modalità e le tempistiche con cui potranno eventualmente essere esercitate le opzioni di mantenimento da parte delle aziende

Ad integrazione e precisazione di quanto riportato nel seguente paragrafo dell’All. n. 4: “Le Aziende che dispongono di propri applicativi per le componenti indicate nell’elenco con i numeri 1 (ADT – Ammissione dimissione trasferimenti), 2 (PS – Gestione pronto soccorso), 5 (Gestione centro trasfusionale) possono esercitare l’opzione del mantenimento del sistema di cui già dispongono.” si comunica quanto segue:

nella predisposizione dell’offerta le società partecipanti non dovranno tener conto della possibilità di opzione, che può essere esercitata da ciascuna Azienda successivamente all’aggiudicazione, di mantenere i propri sistemi attualmente in uso e di cui dispongono.

capitolato.

Per realizzare il progetto di Business continuità (omissis)

...in ottemperanza al D.Leg.vo 196. (omissis) che prevede

l'analisi del rischio come strumento per migliorare la sicurezza dei dati. Il DPS che ogni azienda ha elaborato può costituire una buona base di partenza.

Domanda : i DPS delle aziende sono disponibili?

L’Amministrazione fornirà alla Ditta aggiudicataria tutte le informazioni necessarie per la realizzazione del progetto.

Saranno disponibili servizi di housing ed hosting dei server dell'Amministrazione regionale e degli altri Enti, comprese le ASL/AO, di facility management, dì gestione della sicurezza, di System management, dì network management, di application management.

Domanda: Quali strumenti di facility management, di gestione della sicurezza, di System management, di network

management, di application management sono a

Nella fase attuale l’attività in questione è oggetto di progettazione e sviluppo. Il concorrente, nella elaborazione della proposta tecnica, dovrà adottare i requisiti tecnici e funzionali che devono essere rispettati dal Data center del CRESSAN per permettere una corretta ed adeguata gestione dei sistemi offerti.

disposizione? se sì, è possibile avere evidenza della tipologia di tali sistemi?
Si richiede se, nell'ambito del SISaR se presso il sito della Regione Autonoma Sardegna (CRESSAN) è possibile fare affidamento su specìfiche licenze riguardo ai prodotti • Oracle Database Server • Orade Application Server e di avere evidenza delle versioni dei sistemi (Standard Edition? Enterprise Edition? 8, 9i, I0g?), numero e tipologia (per utente, per processore?) di licenze dei sistemi presenti e utilizzabili.	La risposta è negativa. Tutto il software di base, quale quello indicato dal concorrente, necessario alla realizzazione del sistema informativo SISaR costituisce una fornitura interamente a carico del partecipante all’appalto.
Si richiede se, nell'ambito del SISaR, presso i siti ASL/Policlinici Universitari/AO coinvolti nel SISaR, è possibile fare affidamento su specifiche licenze riguardo ai prodotti • Oracle Database Server • Oracle Application Server e di avere evidenza delle versioni dei sistemi (Standard Edition? Enterprise Edition? 8, 9i, 10g?), numero e tipologia (per utente, per processore?) di licenze dei sistemi presenti e utilizzabili.	La risposta è negativa. Tutto il software di base, quale quello indicato dal concorrente, necessario alla realizzazione del sistema informativo SISaR costituisce una fornitura interamente a carico del partecipante all’appalto.
Riguardo il sistema di Disaster Recovery del data center del CRESSAN devono necessariamente essere usati entrambi i centri tecnici ubicati presso le ASL dì Cagliari e dì Sassari o e' possibile progettare un'architettura che garantisca le stesse funzionalità di ripristino utilizzando un solo centro tecnico?	La risposta è negativa. E’ necessario usare tutti e due i centri tecnici di Cagliari e di Sassari.
Sono già esistenti e funzionanti strumenti di Operation Management? Se si quali e rispetto a quali tematiche (e.g. network. System mgnt)?	Nella fase attuale l’attività in questione è oggetto di progettazione e sviluppo. Il concorrente, nella elaborazione della proposta tecnica, dovrà adottare i requisiti tecnici e funzionali che devono essere rispettati dal Data center del CRESSAN per permettere una corretta ed adeguata gestione dei sistemi offerti.

E’ già' esistente un sistema di Inventory centralizzato?	Attualmente non esiste un sistema di inventory centralizzato. Col progetto Medir verrà sviluppato un sistema per ciascuna ASL che consentirà di memorizzare gli Asset aziendali
Sono già' esistenti e funzionanti strumenti di automazione delle patch e/o distribuzione del software ?	Nella fase attuale l’attività in questione è oggetto di progettazione e sviluppo. Il concorrente, nella elaborazione della proposta tecnica, dovrà adottare i requisiti tecnici e funzionali che devono essere rispettati dal Data center del CRESSAN per permettere una corretta ed adeguata gestione dei sistemi offerti.
E' richiesto a pagina 39 dell'allegato tecnico, punto a, che il sistèma del backup presso SISAR dovrà espletare il backup di tutti I database che risiedono su tutti i nodi delie aziende (Backup Centralizzato). A pagina 66 dell'allegato 4, e successive, e' invece indicato che su ciascuna azienda sanitaria deve essere prevista una infrastruttura di backup server basata su un backup server (SLES/IBM TMS), una SAN ed una tape library. Si chiede di chiarire quale delle 2 indicazioni sia da ritenere valida.	Il sistema richiesto per ogni ASL si occuperà del back up per il sistema Medir-Fascicolo Sanitario Elettronico. A pagina 39 è richiesto un sistema di back up per il sistema SISaR e non per i dati del Fascicolo Sanitario Elettronico.
E’ richiesto a pagina 44 dell'allegato tecnico che, per il potenziamento delle piattaforme tecnologiche delle aziende, che il DBMS che si andrà ad utilizzare sia della stessa tecnologia (fornitore e release) di quello previsto per il CRESSAN. Considerando che a pagina 66 dell'allegato 4, e successive, è invece indicato che su ciascuna azienda sanitaria deve essere prevista una infrastruttura dì DBMS basata su MS SQL Server 2005 in configurazione MSCS su piattaforma Windows, si impone implicitamente che la tecnologia di DBMS per il centro sia MS SQL Server 2005. Si chiede di smentire od avallare questa specìfica deduzione,	Si smentisce questa deduzione. Nel contesto a cui si sta facendo specifico riferimento, a pag. 66, si stanno descrivendo le esigenze del solo sistema Medir e non di tutto il sistema SISaR. Per il DBMS del SISaR si rimanda alla offerta tecnica del concorrente.
In riferimento al progetto ICAR l'Ente Regione Autonoma Sardegna intende abilitare i servizi infrastrutturali elencati (INF 1, INF 2, INF 3) limitatamente per comunicare con le altre regioni italiane oppure per comunicare anche con altri soggetti? se sì, quali soggetti?	La domanda non è pertinente, in quanto attiene a scelte che la Regione può assumere indipendentemente dall’appalto in questione. Il sistema SPCR/SPCoop che verrà realizzato, coerentemente alle specifiche del sistema ICAR ed al sistema SPC nazionale, costituisce il framework di cooperazione applicativa del livello regionale.

Qual è il sistema di autenticazione da utilizzare nell'ambito del SISaR?	E’ un sistema che deve essere utilizzato per tutto il dominio del SISaR, si appoggia su un servizio di directory LDAP ove vengono memorizzati tutti i profili del personale del servizio sanitario regionale, deve poter gestire credenziali di tipo “forte” quali CNS e credenziali “meno forti” basate su userid e password. Deve essere possibile, tramite token SAML 2.0 realizzare il servizio SSO. Inoltre: I sistemi attualmente in fase di realizzazione (ANAGS, MEDIR, RTP) prevedono la strong e la autenticazione con credenziali deboli. Medir e RTP prevedono l’utilizzo della CNS (si veda progetto a carattere nazionale SAX) per l’accesso al sistema. I processi di autorizzazione e accounting al momento sono delegati ai singoli sistemi. Obiettivo del progetto SISaR è quello di realizzare un unico sistema di Autenticazione, Autorizzazione e Accounting che preveda l’utilizzo delle CNS.
E necessario prevedere di autenticazione federata fra l'Ente Regione e le Aziende Sanitarie? se sì, quali?	Come già sopra detto va assicurato il servizio di SSO nell’ambito del dominio del servizio sanitario regionale.
In riferimento al progetto ICAR, l'Assessorato Sanità della Regione Autonoma Sardegna intende utilizzare le componenti per ìnteroperare con le Aziende Sanitarie, quali sono i componenti che la Regione Autonoma Sardegna intende abilitare? si richiede un dettaglio tecnico (tipologia, funzionalità, modalità di interfaccia,...)	Si rimanda alla progettualità della proposta tecnica del concorrente. Sotto il profilo tecnico si evidenzia che gli standard adottati dal progetto ICAR sono coerenti con quelli adottati dal sistema nazionale SPC/SPCoop, di cui è disponibile ampia documentazione presso il sito del CNIPA. Sotto il profilo funzionale si evidenzia che il sistema SPCR/SPCoop che verrà realizzato dalla Regione ha il compito di far interoperare i sistemi ESB/EAI tra loro, o tra ciascuno di loro ed i componenti SISaR attivi presso il nodo regionale (Data Center-CRESSAN).
In riferimento al software infrastrutturale SPCR-SPCoop, si richiede un dettaglio tecnico (tipologia, funzionalità, modalità dì interfaccia, .„) relativamente a quanto elencato a pagina 27 dell'allegato 4.	Probabilmente si fa riferimento a pag. 27 dell’Allegato 7. Per questa domanda valgono le stesse considerazioni già illustrate nel precedente quesito.
Si richiede all'Amministrazione Appaltante se, nell'ambito del	La risposta è negativa.

Sistema Informativo Sanitario Amministrativo, il fornitore potrà far affidamento su specifiche licenze in esubero dal progetto SIBAR; se sì,

quali tipologie di licenze? in che numero?

Si richiede all'Amministrazione Appaltante se, nell'ambito del Sistema Informativo Sanitario Amministrativo, il fornitore potrà far affidamento su licenze di eventuali piattaforme di sistemi documentali già in esercizio presso la Regione Autonoma Sardegna; se sì, quali tipologie di sistemi? e quali

tipologie di licenze?

La risposta è negativa,

Allegato 4 - paragrafo 4.1 - le aziende interessate al progetto SIO sono le 8 ASL e la AO Brotzu.

Allegato 4 - paragrafo 4.3.2 - le estensioni del progetto Medir vengono invece incluse oltre alle Aziende del punto precedente anche il Policlinico di SS e di CA.

Domanda: i Policlìnici di SS e di CA devono essere previsti nella fornitura come Cluster (analogamente a Brotzu), o devono essere aggregati alla ASL 1 (policlinico di SS) ed ASL 8 (policlinico di Cagliari) o non rientrano affatto nel progetto?

I Policlinici di Sassari e Cagliari sono interessati al progetto del SIO, ma vanno aggregati rispettivamente al cluster territoriale di Sassari e di Cagliari.

Per il PS Gestione Pronto Soccorso è richiesta l'integrazione del PS con il centro Regionale 118.

Domanda: II centro regionale 118 quali servizi espone?

Il sistema informativo regionale per la gestione dell’emergenza sanitaria sarà oggetto di un adeguamento. Si rimanda alla progettualità della proposta tecnica, che dovrà evidenziare e definire i principali flussi di integrazione con il sistema informativo

dell’emergenza sanitaria

Non sono presenti dati di dimensionamento relativamente ai Policlinici di Sassari e di Cagliari.

Domanda: il progetto regionale del CUP deve essere previsto

anche per i policlinici di SS e di CA?

Il progetto CUP va previsto anche per i Policlinici di Cagliari e Sassari.

E’ richiesta l'assistenza per 36 mesi a partire dal collaudo Domanda: che tipo di servizi comprende l'assistenza per 36

mesi?

Manutenzione correttiva e garanzia

In riferimento allo Schema dell'Offerta Tecnica, si richiede conferma relativamente ai titoli dei paragrafi dal 10 al 21. In particolare si richiedono delucidazioni sui titoli dei paragrafi 18 e 19.

Come citato nel Disciplinare cap. 13.1.4: “In sede di offerta tecnica le Imprese concorrenti dovranno allegare il curriculum vitae del capo progetto (program manager) che verrà nominato nel caso di aggiudicazione dell’appalto e un capo progetto (project manager) e un responsabile tecnico per

ciascuno dei seguenti componenti o sotto-

sistemi:

o Sistema Sanitario Amministrativo

o Sistema Sanitario Direzionale

o Sistema Sanitario Epidemiologico

o Sistema Gestore Risorse - CUP

o Sistema Sanitario Ospedaliero oSistema Attività Assistenziali e di Prevenzione

o Sistema infrastrutturale

o Sistema di integrazione delle componenti

o Responsabile della qualità

L’impresa dovrà inoltre allegare all’offerta tecnica anche il curriculum vitae dell’esperto in standards internazionali nell’area clinico/sanitaria utilizzato per la realizzazione del progetto.”

Le Ditte concorrenti dovranno quindi produrre il CV delle figure richieste nel Disciplinare Tecnico:

CURRICULUM VITAE PROGRAM MANAGER

CURRICULUM RESPONSABILE QUALITA’

CURRICULUM VITAE PROJECT MANAGER

Sistema informativo sanitario amministrativo (contabilità, personale, acquisti, pianificazione e controllo)

CURRICULUM VITAE RESPONSABILE

TECNICO Sistema informativo sanitario amministrativo (contabilità, personale, acquisti, pianificazione e controllo)

CURRICULUM VITAE PROJECT MANAGER

Sistema informativo gestore risorse – CUP

CURRICULUM VITAE RESPONSABILE

TECNICO Sistema informativo gestore risorse – CUP

CURRICULUM VITAE PROJECT MANAGER

Sistema informativo sanitario ospedaliero

CURRICULUM VITAE RESPONSABILE

TECNICO Sistema informativo sanitario ospedaliero

CURRICULUM VITAE PROJECT MANAGER

Sistema informativo sanitario attività assistenziali e di prevenzione

CURRICULUM VITAE RESPONSABILE

TECNICO Sistema informativo sanitario attività assistenziali e di prevenzione

CURRICULUM VITAE PROJECT MANAGER

Sistema informativo sanitario direzionale

CURRICULUM VITAE RESPONSABILE

TECNICO Sistema informativo sanitario direzionale

CURRICULUM VITAE PROJECT MANAGER

Sistema informativo sanitario epidemiologico

CURRICULUM VITAE RESPONSABILE

TECNICO Sistema informativo sanitario epidemiologico

CURRICULUM VITAE PROJECT MANAGER

Sistema infrastrutturale (apparati HW e SW di base)

CURRICULUM VITAE RESPONSABILE

TECNICO Sistema infrastrutturale (apparati HW e SW di base)

CURRICULUM VITAE PROJECT MANAGER

Attività di Integrazione del sistema

CURRICULUM VITAE RESPONSABILE

TECNICO Attività di Integrazione del sistema

CURRICULUM VITAE esperto standard

internazionali nell’area clinico/sanitaria

In riferimento allo Schema dell'Offerta Tecnica, si richiede conferma relativamente ai titoli dei paragrafi dal 10 al 21. In particolare si richiede di confermare che - per il Sistema Informativo Sanitario Ospedaliere è richiesto di indicare solo il Project Manager

- per il Sistema Informativo Sanitario attività assistenziali e di prevenzione è richiesto di indicare solo il Responsabile Tecnico

- per il Sistema Informativo Sanitario Direzionale è richiesto di indicare solo il Project Manager

- per il Sistema Informativo Sanitario Epidemiologico è richiesto di indicare solo il Responsabile Tecnico

Vedi risposta al quesito precedente

In riferimento alle attìvià A8, A9 e A10, si richiede delucidazione in merito:

per le attività A8 e A10 si richiede di evidenziare la differenza fra l'oggetto di integrazione dei due punti

- per l'attività A9 si intende la fase di progettazione tecnica funzionale allo sviluppo/personalìzzazione?

Le attività A8 e A10 riguardano i servizi a carico del fornitore per pervenire alla progettazione sviluppo di un sistema informativo sanitario integrato regionale. Si deve agire sia sulla parte del sistema esistente ( azioni A8) sia su quella del sistema da realizzare come “nuovo” ( azioni A10).

Per quanto riguarda le attività previste nel punto A9 viene stabilito che lo sviluppo del sistema informativo integrato deve prevedere un adeguato “supporto al management aziendale e regionale per lo sviluppo del nuovo contesto organizzativo”.

Si rimanda all’offerta tecnica del concorrente

per la illustrazione di questi servizi.

Nell'allegato A2 "Schema offerta economica" si chiedono i prezzi del sw (DB e di base) per processore. Cosa si intende per processore? Come devono essere considerate la piattaforme dual core?

Le piattaforme dual (multi) core presentano una quotazione a seconda del tipo di software che le impiega e delle condizioni praticate dalla società che lo distribuisce. Per chiarezza i prezzi che vengono presentati nello schema di offerta economica vanno riferiti a ciascuna CPU fisica anche se multi-core, e contemporaneamente vanno evidenziati

anche a livello di ciascun core.

Premesso che apparentemente la documentazione di Xxxx fa riferimento principalmente ad un'architettura centralizzata, perché in Allegato 4 (pagine 66-67) è richiesta la fornitura

dell'hardware a livello ASL anche per il Middleware Biztalk,

Il sistema Medir-Fascicolo Sanitario Elettronico prevede un’architettura federata. Il middleware Biztalk richiesto è ad uso

esclusivo del sistema Medir

lasciando così intuire un'architettura di federato?
L'architettura rappresentata nella figura di pagina 68 dell'Allegato 4 è parzialmente incongruente rispetto all'elenco delle forniture riportato nella tabella delle pagine 66-67: come va interpretata questa differenza?	Si deve fare riferimento alle caratteristiche riportate nella tabella delle pagine 66-67. Lo schema è indicativo, si trasmette in Allegato n.1 al presente elenco di quesiti quello coerente con le richieste riportate nella tabella.
La tabella a pagina 96 indica come 21.826 il numero di unità di personale per il 2005 per le Aziende della Sardegna. In considerazione di tale numero, si chiede conferma della verosimiglianza del dato riportato a pag. 92 che indica il “Numero cedolini dipendenti” pari a 3.000.000 annui.	Si tratta di un refuso. La stima approssimata è di circa 300.000 cedolini annui.
"L’architettura di riferimento del sistema informativo ospedaliero (SIO) che viene proposta, tenuto conto anche delle considerazioni esposte nei precedenti capitoli,prevede la possibilità di integrare i sottosistemi del SIO realizzati da diversi fornitori ed in dotazione degli Ospedali della Regione Autonoma della Sardegna, che soddisfano i requisiti di integrazione attraverso web services e standard aperti (SOA, HL7 V3.) e profili di integrazione IHE. Ove questa attività non possa avere luogo, in quanto il singolo applicativo sw non è aggiornabile per realizzare l’integrazione secondo gli standard di mercato richiesti, si potrà procedere alla sostituzione parziale o completa dei sottosistemi del SIO interessati all’integrazione di comune accordo con l’Ente appaltante." E' corretta l'interpretazione secondo la quale: A) i sistemi che possiedono i requisiti sopra citati riceveranno dall'Aggiudicataria le informazioni e i profili necessari (specifiche tecniche) affinché tali sistemi possano essere integrati. Le attività di adattamento saranno a carico dei fornitori di tali sistemi per quanto riguarda il lato dell'applicativo da integrare. B) i sistemi non integrabili perché non soddisfano i requisiti sopra indicati saranno sostituiti parzialmente o totalmente di comune accordo con l'ente appaltante, nel senso che l'ente provvederà ad ottenere le necessarie autorizzazioni dalle ASL/AO/PU interessati.	I sistemi componenti del SIO da fornire sono stati stabiliti a pag. 58 del Disciplinare, ultimo capoverso punti da 1 a 5 (ADT, PS-Pronto soccorso, Gestione Order entry di reparto, Gestione sale operatorie, Gestione del Centro trasfusionale). Nella risposta al quesito richiamato sopra, si evidenzia che la progettazione ed implementazione di questi moduli non deve tener conto dell’obbligo di riuso dei moduli applicativi attualmente in funzione. Nella successiva pagina 59 del Disciplinare tecnico , sia nel primo capoverso che nel secondo capoverso si definiscono un insieme minimo di moduli applicativi (sottosistemi componenti-clinici del SIO) che devono essere oggetto di integrazione (LIS, RIS, PACS, AP) per ciascun cluster. Nella successiva pag.60 del Disciplinare tecnico si evidenzia la necessità di realizzare l’integrazione del SIO con il sistema Medir e con il sistema Anags, con il CUP-Gestione risorse e con il sistema informativo amministrativo. Le attività sopra riportate sono tutte a carico dell’aggiudicatario. Ad integrazione e precisazione di quanto riportato nel seguente paragrafo dell’All. n. 4:

“Le Aziende che dispongono di propri applicativi per le componenti indicate nell’elenco con i numeri 1 (ADT – Ammissione dimissione trasferimenti), 2 (PS – Gestione pronto soccorso), 5 (Gestione centro trasfusionale) possono esercitare l’opzione del mantenimento del sistema di cui già dispongono.” si comunica quanto segue:

capitolato.

"Sono previste tre tipologie di collaudo:

- Collaudo dell’analisi organizzativa e dell’analisi tecnica

- collaudo sistemistico

- collaudo funzionale e prestazionale

- collaudo di integrazione"

In considerazione del fatto che sono indicati tre (3) collaudi, ma ne sono listati quattro (4) si chiede di chiarire quanti e quali sono i collaudi previsti.

Vanno previsti i quattro tipi di collaudo.

"Sistema 118 Regionale, nel senso di esporre servizi compatibili con tale sistema (conferma arrivo e presa in carico al singolo Pronto Soccorso, destinazione delpaziente, codice triage assegnato, ecc.), utilizzo di servizi esposti dal sistema di emergenza sanitaria nel suo complesso (dati dispatch, dati di pre-allertamento ed attivazione del trauma team, dati della scheda di pre -intervento, ecc …). Il sistema di emergenza sanitaria attualmente in uso c/o la Regione Autonoma della Sardegna, comprende informazioni generate dalle Centrali Operative"

Si richiedono ulteriori dettagli relativamente alla procedura in

oggetto.

“Attribuzione DRG ai ciascun ricovero, da prevedersi anche in modalità interattiva con impiego dei software ufficiali di elaborazione (GROUPER 3M)”

In merito al citato punto:

1) Si chiede conferma che le ASL dispongono già di Grouper e questi non fanno parte dell’oggetto della fornitura.

2) Si richiede cosa si intende esattamente per “modalità interattiva”.

Ciascuna ASL/AO è dotata di software Grouper.

Per modalità interattiva si intende la possibilità di associare alla dimissione, con una modalità automatica, le informazioni che contengono i DRG all’atto della dimissione del paziente, in modo da disporre del flusso dei ricoveri (debito informativo).

Considerato che nel summenzionato articolo del capitolato si richiede di dichiarare di “aver tenuto conto degli obblighi di cui all’art. 26 del presente capitolato” e nell’Allegato A1: Schema dichiarazione – punto 2 si richiama, invece, l’art. 27

si chiede di chiarire quale dei due articoli debba essere preso in considerazione.

Si conferma il riferimento all’art. 27 del capitolato d’oneri. Gli obblighi di cui all’art. 26, infatti, attengono a disposizioni normative di rilievo nazionale a cui comunque tutte le ditte devono attenersi nella redazione dell’offerta.

Si chiede di confermare che il riferimento all’art. 27 del capitolato d’oneri contenuto al punto sub 2. della dichiarazione da Voi fornita (modello Allegato A1) sia dovuto ad un refuso di stampa. Il corretto riferimento da riportare nella dichiarazione è l’art. 26 del Capitolato d’oneri.

dell’offerta.

Posto che all’art. 7 del capitolato d’oneri ai punti sub 1., 2. e

10. si fa riferimento a tre documenti distinti in relazione alla cauzione provvisoria, si chiede di precisare se l’impegno di cui al punto sub 2. e l’impegno di cui al punto sub 10. possano essere contenuti all’interno della stessa cauzione provvisoria (stesso documento) di cui al punto sub 1.

Gli impegni di cui ai punti sub. 1, 2 e 10 possono anche essere contenuti all’interno dello stesso documento purché nello stesso vengano esplicitati in modo inequivocabile i contenuti relativi ai medesimi.

In riferimento alla dichiarazione di subappalto, si chiede di precisare cosa si intende esattamente per “elemento di offerta” componenti dell’offerta economica o elementi

dell’offerta tecnica?

Per “elemento di offerta” si intendono gli elementi dell’offerta tecnica.

In riferimento alle giustificazioni da presentare nella Busta 3.1 si chiede di confermare che nel costo (IVA esclusa) di subappalto di cui alla tabella 3.10.2 vada esposta l’offerta complessiva ricevuta dal subappaltatore, senza ulteriori

specificazioni.

Si conferma che nel costo (IVA esclusa) di subappalto di cui alla tabella 3.10.2 va esposta l’offerta complessiva ricevuta dal subappaltatore, senza ulteriori specificazioni

fermo restando che nel precedente punto

	3.10.1, occorre allegare una dettagliata descrizione.
Si chiede di voler precisare se nelle tabelle relative all’ “Elenco prezzi unitari” alla voce “costi unitari” si debba invece intendere il prezzo.	Si conferma che nelle tabelle relative all’ “Elenco prezzi unitari” alla voce “costi unitari” si deve intendere il prezzo.
Si chiede di voler precisare se le quantità offerte debbano essere indicate unicamente nelle tabelle indicate nell’allegato A5 Schema relazione giustificazione offerta economica ed in nessun modo nell’allegato A2. Infatti, nelle tabelle presenti in tale allegato (offerta economica) si parla di costo unitario e non si fa mai riferimento alle quantità. Nel caso in cui le quantità debbono essere esposte si chiede di precisare in che modalità.	Nell’allegato A5 occorre indicare le quantità perché tale elemento è necessario per dare evidenza delle voci di prezzo che concorrono a formare l’offerta economica. Viceversa nell’allegato A2, che riguarda un elenco di prezzi unitari, la quantità è sempre 1.
La somma delle singole tabelle deve corrispondere all’importo complessivo offerto? In caso di risposta affermativa, si chiede di indicare come rimodulare le singole tabelle tenendo conto della componente quantità.	La risposta è negativa.
Le 16 tabelle riportate nell’Allegato A2 esauriscono le componenti di cui deve comporsi l’offerta economica? In caso di risposta negativa, si chiede se è possibile aggiungere ulteriori tabelle.	La risposta è negativa sia per il primo che per il secondo punto del quesito.
Si chiede precisare se i costi di manutenzione e garanzia di hw e sw debbano essere inclusi in una delle tabelle presenti, nel qual caso si chiede quale, ovvero vadano inseriti in apposita tabella che va quindi aggiunta alle 16 già presenti.	Nell’allegato A modelli documentazione Offerta Economica i costi di manutenzione e garanzia devono essere inclusi nei costi delle apparecchiature e dei software
Si chiede di voler precisare se con riferimento alle tabelle allegate ai punti 7, 8, 9, 10, 11 e 16 il campo “Modello” sia correttamente inteso quale rispettivamente “tipo di corso” (tab. 7), “tipo licenza” (tab.8, 9, 10,11) e “figura professionale” (tab. 16).	L’interpretazione è corretta
Si chiede di voler precisare in quale tabella deve essere indicato il prezzo relativo alla formazione in aula	Non è stato chiesto un prezzo unitario per la formazione in aula. Sarà però indicato, insieme alle altre figure professionali, anche il prezzo giornaliero per il docente
Si chiede di voler precisare se la tabella 12 – Costo di ciascun altro tipo di apparato Hw e Sw fornito nel progetto SISaR può	Si se possono rientrare in qualche modo come apparati hw o software

essere utilizzata anche per eventuali altre tipologie di prodotti e/o servizi che non è possibile classificare in modo esatto nelle

altre 15 tabelle

8. CURRICULUM RESPONSABILE QUALITA’

9. CURRICULUM VITAE PROJECT MANAGER Sistema informativo sanitario amministrativo (contabilità, personale, acquisti, pianificazione e controllo)

10. CURRICULUM VITAE RESPONSABILE TECNICO Sistema informativo sanitario amministrativo (contabilità, personale, acquisti, pianificazione e controllo)

11. CURRICULUM VITAE PROJECT MANAGER Sistema informativo gestore risorse – CUP

12. CURRICULUM VITAE RESPONSABILE TECNICO Sistema informativo gestore risorse – CUP

13. CURRICULUM VITAE PROJECT MANAGER Sistema informativo sanitario ospedaliero

14. CURRICULUM VITAE RESPONSABILE TECNICO Sistema informativo sanitario attività assistenziali e di prevenzione

15. CURRICULUM VITAE PROJECT MANAGER Sistema informativo sanitario direzionale

16. CURRICULUM VITAE RESPONSABILE TECNICO Sistema informativo sanitario epidemiologico

17. CURRICULUM VITAE PROJECT MANAGER Sistema infrastrutturale (apparati HW e SW di base)Sistema informativo sanitario direzionale

18. CURRICULUM VITAE RESPONSABILE TECNICO Sistema infrastrutturale (apparati HW e SW di base)Sistema informativo sanitario epidemiologico

19. CURRICULUM VITAE PROJECT MANAGER Attività di Integrazione del sistema

20. CURRICULUM VITAE RESPONSABILE TECNICO Attività di Integrazione del sistema

In sede di offerta tecnica le Imprese concorrenti dovranno allegare il curriculum vitae e un capo progetto (project

manager) e un responsabile tecnico per ciascuno dei seguenti componenti o sotto-sistemi:

o Sistema Sanitario Amministrativo

o Sistema Sanitario Direzionale

o Sistema Sanitario Epidemiologico

o Sistema Gestore Risorse - CUP

o Sistema Sanitario Ospedaliero

o Sistema Attività Assistenziali e di Prevenzione

o Sistema infrastrutturale

o Sistema di integrazione delle componenti

o Responsabile della qualità

DOMANDA:

I due elenchi non sono congruenti, si chiede di precisare quali sono esattamente i CV da allegare all’offerta per ogni sotto- sistema e per le attività di Controllo Qualità.

o Sistema Sanitario Amministrativo

o Sistema Sanitario Direzionale

o Sistema Sanitario Epidemiologico

o Sistema Gestore Risorse - CUP

o Sistema Sanitario Ospedaliero oSistema Attività Assistenziali e di Prevenzione

o Sistema infrastrutturale

o Sistema di integrazione delle componenti

o Responsabile della qualità

Le Ditte concorrenti dovranno quindi produrre il CV delle figure richieste nel Disciplinare Tecnico:

CURRICULUM VITAE PROGRAM MANAGER

CURRICULUM RESPONSABILE QUALITA’

CURRICULUM VITAE PROJECT MANAGER

Sistema informativo sanitario amministrativo (contabilità, personale, acquisti, pianificazione e controllo)

CURRICULUM VITAE RESPONSABILE

TECNICO Sistema informativo sanitario

amministrativo (contabilità, personale, acquisti, pianificazione e controllo)

CURRICULUM VITAE PROJECT MANAGER

Sistema informativo gestore risorse – CUP

CURRICULUM VITAE RESPONSABILE

TECNICO Sistema informativo gestore risorse – CUP

CURRICULUM VITAE PROJECT MANAGER

Sistema informativo sanitario ospedaliero

CURRICULUM VITAE RESPONSABILE

TECNICO Sistema informativo sanitario ospedaliero

CURRICULUM VITAE PROJECT MANAGER

Sistema informativo sanitario attività assistenziali e di prevenzione

CURRICULUM VITAE RESPONSABILE

TECNICO Sistema informativo sanitario attività assistenziali e di prevenzione

CURRICULUM VITAE PROJECT MANAGER

Sistema informativo sanitario direzionale

CURRICULUM VITAE RESPONSABILE

TECNICO Sistema informativo sanitario direzionale

CURRICULUM VITAE PROJECT MANAGER

Sistema informativo sanitario epidemiologico

CURRICULUM VITAE RESPONSABILE

TECNICO Sistema informativo sanitario epidemiologico

CURRICULUM VITAE PROJECT MANAGER

Sistema infrastrutturale (apparati HW e SW di base)

CURRICULUM VITAE RESPONSABILE

TECNICO Sistema infrastrutturale (apparati HW e SW di base)

CURRICULUM VITAE PROJECT MANAGER

Attività di Integrazione del sistema

CURRICULUM VITAE RESPONSABILE

TECNICO Attività di Integrazione del sistema

CURRICULUM VITAE esperto standard internazionali nell’area clinico/sanitaria

“L’inizio del progetto decorre dalla data di approvazione del piano di lavoro definitivo.”

“La progettazione, la realizzazione del sistema informatico devono essere completati entro 12 mesi dalla data di inizio progetto.

L’avvio in esercizio del sistema informativo “Gestore risorse- CUP” dovrà avere inizio dopo 12 mesi dall’inizio del

progetto.

L'installazione ed il test del sistema nella primo cluster di .....

deve essere completato entro 15 mesi dalla data di inizio del progetto.

L’installazione nelle altre ASL/AO/PU dovranno completarsi entro 18 mesi dalla data di inizio del progetto.”

La progettazione, l’analisi, la realizzazione del sistema, la fornitura ed installazione presso il primo cluster di Aziende

........ , la realizzazione dei moduli formativi entro 15 mesi

dalla data di stipula del contratto (Xxxxx Xxxxxxxx); Fornitura ed installazione presso le altre Aziende Sanitarie entro 18 mesi dalla data di stipula del contratto (Secondo Rilascio).”

DOMANDA:

Si conferma che il piano di progetto deve essere sviluppato prendendo come inizio della decorrenza dei tempi di esecuzione la “data di approvazione del piano di lavoro definitivo” ?

L’inizio del progetto inizia dalla data di firma de contratto. Dunque:

“La progettazione, la realizzazione del sistema informatico devono essere completati entro 12 mesi dalla data di inizio progetto.

L’avvio in esercizio del sistema informativo “Gestore risorse-CUP” nel cluster di Aziende ASL 2, ASL 4, ASL 5, ASL 6, ASL 7 dovrà

avere inizio dopo 12 mesi dall’inizio del progetto.

L'installazione ed il test del sistema nella primo cluster di Aziende che verrà determinato dall’Assessorato regionale, e la formazione tecnica del personale interessato deve essere completato entro 15 mesi dalla data di inizio del progetto.

L’installazione nelle altre ASL/AO/PU dovranno completarsi entro 18 mesi dalla data di inizio del progetto.”

I tempi di consegna sono da intendersi a partire dalla data di firma del contratto che coincide con la data di inizio del progetto.

“A livello aziendale (Figura 12) vengono installate le applicazioni software ..........

La Figura 12 riferita nel testo non è presente nel Disciplinare, si richiede di fornirla

Il riferimento alla figura 12 è un refuso. Si faccia comunque riferimento alla descrizione di dettaglio riportata nell’Allegato 7 cap. A.7.4.6 Potenziamento piattaforme tecnologiche

delle Aziende

“Il progetto MEDIR per le Aziende L’estensione alle

altre ASL , all’AO-Brotzu a i due Policlinici di Sassari e Nuoro è a carico del presente appalto, come verrà meglio dettagliato nei successivi capitoli.

“l’estensione del progetto MEDIR alle seguenti Aziende Sanitarie: ......

Policlinico Universitario Cagliari

Policlinico Universitario Sassari.”

DOMANDA:

SI chiede di precisare quanti e quali sono i Policlinici

interessati dall’installazione del MEDIR che sono a carico del contratto SISaR

Il policlinico di Nuoro non esiste e quindi tale riferimento è un refuso. I Policlinici Universitari della Sardegna sono quello di Sassari e quello di Cagliari. Pertanto i Policlinici interessati all’estensione del progetto Medir sono quello di Cagliari e quello di Sassari.

“Piattaforma di Info Delivery (application server con Web intelligence / Business Object)”

La componente Business Object è da considerare indicazione di un prodotto mandatorio ?

In caso affermativo si richiede di specificare il numero di licenze già disponibili nell’Amministrazione e/o se esiste un accordo specifico con il fornitore sul prezzo applicato

Il riferimento al sistema Business Objects sta per sistema di reporting per la Business Intelligence. Business Object non è la piattaforma selezionata per cui le Ditte possono offrire sistemi differenti. Si rimanda comunque alla proposta progettuale del concorrente.

“. in modo da ampliarne le funzionalità (sistema CRM del

servizio sanitario regionale) ”

Si chiede di avere dettagli sul sistema esistente cui si fa riferimento.

Qualora esso non esista già, è richiesta la fornitura di una piattaforma CRM nel contratto SISAR ?

ASL 1: non esiste piattaforma sw ma soltanto un centralino che smista le chiamate

ASL 3: esiste una gestione informatica del call center che si basa sulla piattaforma Linux. Vengono gestite le code con ripartizione automatica verso gli operatori liberi del Call Center. Il sistema gestisce gli orari di apertura, di chiusura, di attesa e di occupato in automatico. Fornisce statistiche sulle chiamate e sull'attività degli operatori. Il sistema telefonico è associato ai PC degli operatori che visualizzano e permettono di gestire le chiamate in entrata.È un sistema di Call Center che attualmente gestisce 6 operatori e un supervisore, ma può arrivare fino 199 operatori.

ASL 8: la piattaforma utilizzata presso il Call Center C.U.P. di questa ASL è basata su una soluzione Siemens Telematica che prevede

un Centralino Siemens Hicom 330 per la

	componente hardware, mentre la componente software utilizzata per la gestione delle chiamate da parte degli operatori è il Pro- Center - HPPC installato su Server Fujtsu- Siemens Primergy con s.o. Windows 2000 Server. Si rimanda all’offerta tecnica del concorrente.
“Viene previsto il potenziamento tecnologico ed organizzativo (quest’ultimo nella misura strettamente necessaria) dei Call Center attualmente in funzione presso le ASL n. 8 di Cagliari, n. 1 di Sassari e n. 3 di Nuoro, in modo da ampliarne le funzionalità (sistema CRM del servizio sanitario regionale) e da adeguarne il numero di posti di lavoro.” Si chiede di avere dettagli sulla tecnologia e composizione dei sistemi attualmente installati, sia per le postazioni di lavoro, centralini telefonici, software di ticketing e sistemi centrali, etc.	ASL 1: non esiste piattaforma sw ma soltanto un centralino che smista le chiamate ASL 3: esiste una gestione informatica del call center che si basa sulla piattaforma Linux. Vengono gestite le code con ripartizione automatica verso gli operatori liberi del Call Center. Il sistema gestisce gli orari di apertura, di chiusura, di attesa e di occupato in automatico. Fornisce statistiche sulle chiamate e sull'attività degli operatori. Il sistema telefonico è associato ai PC degli operatori che visualizzano e permettono di gestire le chiamate in entrata.È un sistema di Call Center che attualmente gestisce 6 operatori e un supervisore, ma può arrivare fino 199 operatori. ASL 8: la piattaforma utilizzata presso il Call Center C.U.P. di questa ASL è basata su una soluzione Siemens Telematica che prevede un Centralino Siemens Hicom 330 per la componente hardware, mentre la componente software utilizzata per la gestione delle chiamate da parte degli operatori è il Pro- Center - HPPC installato su Server Fujtsu- Siemens Primergy con s.o. Windows 2000 Server.
“E’ previsto che il software infrastrutturale relativo al SPCoop venga individuato ed installato dal Centro Servizi Regionale.” E’ corretto interpretare che le porte di dominio siano fornite dal software infrastrutturale installato dall’Amministrazione per SPCoop ?	L’interpretazione è corretta
Al punto A.7.4.5 si specifica che le applicazioni installate	E’ da considerarsi valida la considerazione in

presso i cluster territoriali aziendali debbono essere oggetto di una soluzione di Disaster Recovery (DR) e che quella soluzione DR si deve basare su una ridondanza tecnologia condivisa tra le tre server farm di CRESSAN, l’ASL 1 e l’ASL

8. Si specifica un tempo di restart di 15 minuti.

Al punto A.7.4.4 (precisamente al sottopunto 12, pagina 39) si specifica che un ambiente di produzione delle applicazioni installate presso le Aziende deve essere installato anche presso CRESSAN in modo di provvedere alla ripartenza a caldo in caso di fermo di un nodo aziendale.

DOMANDA:

Nel caso si debba prevedere, sia una ripartenza a caldo su CRESSAN, sia un restart in DR entro 15 minuti, il bandwidth di rete inerente alla duplice sincronizzazione dei dati applicativi di tutte le aziende sarà notevole. Si chiede, quindi, se i sopra citati punti rappresentano due requisiti diversi e obbligatori contemporaneamente, oppure se il punto A.7.4.4 rappresenta l’ipotesi di soluzione per il DR richiesto punto

A.7.4.5.

cui “il punto A.7.4.4 rappresenta l’ipotesi di soluzione per il DR richiesto punto A.7.4.5.”

Si rimanda alla progettualità della proposta tecnica che il concorrente farà pervenire al riguardo.

Il sistema di DS e BC richiesto deve riguardare l’intero dominio applicativo oggetto di fornitura.

E’ confermato che sono oggetto del Disaster Recovery esclusivamente i sistemi del Data Centre del CRESSAN necessari a garantire gli SLA dei servizi erogati per via centralizzata da parte del CRESSAN alle Aziende ?

Si rimanda alla progettualità della proposta tecnica che il concorrente farà pervenire al riguardo.

Il sistema di DS e BC richiesto deve

riguardare l’intero dominio applicativo oggetto di fornitura.

L’allegato 2 pagina 9 recita : "Il sistema dovrà garantire uniformità di accesso alle prestazioni erogabili a carico del SSN, la documentazione e la contabilizzazione delle stesse, la gestione dei dati amministrativi e la creazione di indicatori di qualità dell’assistenza e di valutazione della spesa sostenuta."

Si chiede di specificare meglio la richiesta o eventualmente indicare se trattasi di refuso.

La frase contiene dei refusi. Va intesa nella seguente maniera:

ll sistema dovrà garantire uniformità di accesso alle prestazioni erogabili a carico del SSN, la documentazione e la

creazione di indicatori di qualità dell’assistenza.

Tra i moduli principali da integrare nel SiSaR vi è l'Anagrafe degli Assistibili, la cui realizzazione avviene nell'ambito del progetto ANAGS.

Si chiede quali interfacce di programmazione esponga il modulo AnagS-Client utilizzato per l'allineamento dei dati proveniente dalle ASL e dai Comuni (vedi pagine 12-13 del documento "AG01V1.0 Sintesi del progetto ANAGS" allegato

alla documentazione di gara).

Si precisa il modulo AnagS-Client ASL non comprende interfacce applicative.

Si conferma che l'aggiornamento e il download di porzioni anagrafiche dal sistema centrale sono previsti solo in modalità manuale.

Allo stato dell’arte del progetto le interfacce

applicative che è previsto siano disponibili

Si chiede inoltre conferma che l'aggiornamento e il download di porzioni anagrafiche dal sistema centrale ANAGS verso i sistemi anagrafici locali delle le ASL sia stato previsto solo in modalità "manuale", cioè su richiesta di un utente e non anche su richiesta di applicazioni automatiche (vedi pagina 19 del

documento citato).

direttamente sul sistema centrale in forma di Web Services, comprendono:

- ricerca cittadino: servizio che permette ai sistemi interni al centro regionale di ricercare un cittadino nell'anagrafe assistibili del sistema AnagS;

- ricerca prescrittore: servizio che permette ai sistemi interni al centro regionale di ricercare un medico prescrittore nell'anagrafe prescrittori ;

- notifica variazioni anagrafiche: servizio che permette ai sistemi interni al centro regionale di ricevere la notifica delle variazioni anagrafiche degli assistibili occorse all'anagrafe assistibili del sistema AnagS.

Tra i moduli principali da integrare nel SISar vi è il FSE, la cui realizzazione avviene nell'ambito del progetto MEDIR.

Si chiede conferma che:

1) non sia prevista la duplicazione centrale dei dati contenuti nei Repository locali ;

2) il Registry dei documenti sanitari sia unico e dislocato centralmente;

3) l'accesso ai documenti contenuti nei Repository possa avvenire solo attraverso l'interazione con il Registry, ovvero in caso contrario quali siano i meccanismi previsti per l'interazione applicativa diretta verso i Repository.

E’ confermato che non vi sarà alcuna duplicazione centrale dei dati contenuti nei Repository Locali

Al momento le linee guida del DIT prescrivono che il Registry dei documenti sanitari sia unico a livello centrale regionale; per il futuro è prevista una duplicazione dei dati dei registry di tutti gli FSE nazionali sul dominio centrale di tutte le regioni. Sul sistema delle Aziende Sanitarie potrebbero però essere realizzati una parziale duplicazione del registry: in tal caso in ogni sistema AS potrebbe essere presente il registry di tutte le prestazioni sanitarie erogate dall’azienda stessa e di tutte le prestazioni degli assistiti appartenenti alla Azienda stessa.

L’accesso ai documenti contenuti nel Repository potrà avvenire solo attraverso il Registry in quanto nel registry è registrata la posizione del documento di interesse.

Nell'allegato 1 al capitolato di gara "Requisiti del Sistema Informativo Sanitario Direzionale" nel paragrafo "Architettura tecnica del DW" a pag 16 viene citato espressamente il prodotto Business Objects

per la piattaforma di Info Delivery.

Si chiede conferma se il prodotto Business Objects è la

comunque alla proposta progettuale del

piattaforma selezionata e richiesta per la componente

di Info Delivery del Sistema Informativo Sanitario Direzionale

concorrente.

Nell'allegato 3 al capitolato di gara "Requisiti del Sistema Informativo Sanitario Amministrativo" nel paragrafo “Gestione Centro Formazione Personale SSR – Piattaforma e-Learning (SIA – HR09 )” si fa riferimento alla piattaforma di e-Learning già disponibile presso la Regione. Inoltre nel paragrafo “Gestione ECM (SIA – HR08 )” dello stesso allegato, viene richiesta l’integrazione del sistema informativo sanitario amministrativo con il sistema informativo per la gestione dell’ECM.

Si chiede conferma se vi è pertanto un unico sistema di e- Learning, utilizzato anche per la gestione dell’ECM, che deve essere integrato con il sistema informativo sanitario amministrativo per l’aggiornamento delle informazioni di ciascuna posizione individuale relative alla formazione "Requisiti del Sistema Informativo Sanitario Amministrativo – par. A.3.4.1 Trattamento Xxxxxxxxx ( XXX-XX00 )" e attraverso il quale verranno erogati i contenuti dei corsi on-line, così come indicato nel “Disciplinare - (Sezione 10.1.7)”.

A tal riferimento, si chiede di specificare la tecnologia su cui è sviluppata la piattaforma di e-Learning della Regione e gli

standard tecnologici previsti per i contenuti dei corsi.

Con ECM si intende il sistema per la gestione degli accreditamenti dei corsi (frontali, on-line, etc.). La piattaforma di e-learning è distinta dal sistema per la gestione dell’ECM. I corsi devono essere realizzati in modo tale da essere interoperabili. In questo senso gli standard che i corsi devono rispettare sono AICC, SCORM, IMS. La piattaforma è open source. Si tratta di una piattaforma che è in fase di sviluppo, basata sul protocollo SCORM, ecc..

Premesso che il Policlinico di Cagliari ed il Policlinico di Sassari non sono definiti come “cluster territoriali

ospedalieri”, l’Allegato A4 al par. A.4.1 definisce, infatti, “cluster territoriali ospedalieri” le singole

ASL e l’AO Brotzu, e quindi, entrambi i policlinici, non saranno dotati di un’infrastruttura HW per

l’installazione delle componenti SIO ad essi dedicati, ma utilizzeranno le funzionalità SIO installato

sull’infrastruttura HW dell’ASL di riferimento, rispettivamente ASL8 e ASL1.

Si chiede conferma che invece, in riferimento all’estensione del progetto Medir, ai due Policlinici, si richiede

di fornire l’infrastruttura HW e il SW di Base così come richiesto nell’allegato 4 par. (paragrafo

A4.3.2) pag. 66 ultimo capoverso.

E’ confermato che per il progetto Medir l’infrastruttura HW e SW di base deve essere rilasciato anche per i Policlinici Universitari.

Con riferimento all’estensione del progetto Medir, richiesto nell’Allegato 4 paragrafo A4.3.2 “Sistemi Hardware e Software di base” (pag 66) si chiede di precisare se per software di base

deve intendesi il solo sistema operativo o anche il software

Come sw di base deve intendersi tutto il sw descritto a pag. 66 incluso il middleware applicativo, indicato nella tabella, che è quello

necessario per il sistema Medir in fase di

meddleware applicativo indicato nella tabella dove si indicato le caratteristiche minime.

realizzazione. Si sottolinea che le licenze di tale Middleware sono ad uso esclusivo del sistema Medir ed ovviamente le stesse non potranno essere utilizzate per gli altri componenti del sistema SISaR. Eventuali altri Middleware necessari per gli altri componenti del sistema SISaR potranno anche essere diversi da quello del sistema Medir, e ciò dipenderà dalla proposta delle concorrenti.

Il "Disciplinare" pag. 113 primo capoverso recita: A tale riguardo si aggiunge che il sistema informativo dovrà associare ed integrare al sistema di accesso che attualmente realizza le funzioni di autenticazione (strong authentication, o autenticazione con credenziali deboli : user id e password) il sistema che svolge le funzioni di autorizzazione e quelle di accounting degli accessi, dando origine ad un sistema integrato (triple A= Autenticazione, Autorizzazione,Accounting).

Sull’argomento si pongono i seguenti quesiti:

1) Qual'è il "sistema di accesso che attualmente realizza le funzioni di autenticazione" in RAS e quali sono le modalità di integrazione ad esso che devono essere utilizzate dalle applicazioni verticali?

2) E' possibile avere i dettagli tecnici di integrazione?

I sistemi attualmente in fase di realizzazione (ANAGS, MEDIR, RTP) prevedono la strong e la autenticazione con credenziali deboli. Medir e RTP prevedono l’utilizzo della CNS (si veda progetto a carattere nazionale SAX) per l’accesso al sistema. I processi di autorizzazione e accounting al momento sono delegati ai singoli sistemi. Obiettivo del progetto SISaR è quello di realizzare un unico sistema di Autenticazione, Autorizzazione e Accounting che preveda l’utilizzo delle CNS.

Si richiede di confermare la figura riportata a pag. 60 del Disciplinare Tecnico, dalla quale si deduce che ogni Azienda Ospedaliera/Presidio Ospedaliero sia già dotato di propria porta di dominio (di seguito, PDD), fornita probabilmente nell’ambito del progetto MEDIR, e che tale porta sia già utilizzata nell’ambito dello stesso progetto MEDIR per effettuare l’integrazione tra i sistemi presenti nell’AO e il Repository CDA 2.0 realizzato dallo stesso progetto presso l’ASL e i sistemi regionali.

Si chiede di specificare la tecnologia su cui è sviluppata la PDD MEDIR e le modalità di integrazione tra la medesima ed i sistemi interni al Dominio Applicativo a cui essa fa da gateway.

E’ confermata la validità della Figura 6 Integrazione delle componenti del SIO territoriale (esempio) come descritto nel disciplinare a pag.59: “Nella Figura 6 viene rappresentato lo schema di riferimento per l’integrazione delle componenti del livello “cluster ospedaliero” e delle componenti del livello Aziendale (SIO territoriale)”. Dalla figura

6 non è però possibile dedurre che ogni Azienda sanitaria ha già una propria PDD. Infatti a pagina 27 dell’allegato 7 REQUISITI DEL SISTEMA INFRASTRUTTURALE (APPARATI HW E SW DI BASE) paragrafo

A.7.4.2 Fornitura HW e SW di base per installazione, avvio e gestione del sistema SPCRSPCoop è specificato: “Il presente

bando dovrà invece prevedere la fornitura

degli apparati HW e SW di base, per il sistema sanitario centrale e per ciascuna azienda sanitaria, per ospitare SPCR- SPCoop. Questa parte di fornitura dovrà essere consegnata dalla Ditta aggiudicataria entro due mesi dalla data di firma del contratto.” Come specificato nell’Allegato 7 “Il nuovo sistema informativo sanitario integrato regionale dovrà essere progettato prevedendo che lo scambio di informazioni tra i sistemi informativi delle ASL e quelli situati presso il CRESSAN avvenga attraverso il sistema pubblico di cooperazione applicativa regionale SPCR-SPCoop.A questo scopo si dovrà tenere conto anche di quanto definito nell’ambito del progetto interregionale ICAR,

..” Dunque il sistema pubblico di cooperazione si appoggerà al sistema utilizzato nell’ambito ICAR ed in particolare su “openspcoop” (si veda anche il sito per tutte le informazioni su questa infrastruttura applicativa). Le modalità di integrazione fra la PDD ed il dominio interno sono quelle standard di riferimento descritte nei documenti CNIPA sul sistema pubblico di cooperazione. Si rimanda inoltre ai documenti CNIPA sul sistema pubblico di cooperazione che prevede l’utilizzo delle PDD per lo scambio di dati tra amministrazioni diverse.

In sintesi:

Il sistema di interoperabilità del SISaR viene supportato da due sottosistemi tra di loro integrati

1. Il primo è rappresentato dal sistema SPCR/SPCoop. Questo sistema è parzialmente oggetto di fornitura, limitatamente per la parte di HW e SW di base (server e sistemi operativi). Per evidenziare il dimensionamento dei server da fornire è stato

prodotto un percorso progettuale

solamente per poter far comprendere i razionali del dimensionamento. Il sistema SPCR/SPCoop costituisce un dominio regionale a sé stante, che interagisce con tutti i sistemi informativi regionali interessati ad usufruire dei suoi servizi di cooperazione applicativa (sanità, agricoltura, ambiente, ec..) e presenta una o più porte di dominio.

2. Il sistema SPCR/SPCoop, per la parte che serve per assicurare la cooperazione applicativa tra componenti del SISaR, svolge la funzione di scambio di informazioni tra le componenti applicative centralizzate e quelle installate presso i cluster territoriali, ed a tal fine usa porte di dominio già predisposte, progettate e realizzate secondo le specifiche CNIPA (versione più aggiornata).

3. In particolare il sistema SPCR/SPCoop interopera con ciascun sistema ESB/EAI di cui è dotato ogni cluster territoriale.

Ogni sistema ESB/EAI rappresenta un “framework” (anche) di cooperazione applicativa, che svolge le sue funzioni limitatamente al cluster territoriale. Esso rappresenta un dominio a sé stante, dotato di una o più porte di dominio, in modo da gestire: a) sia i flussi intra-cluster (tra moduli applicativi del cluster), b) sia inter-cluster(tra moduli applicativi di diversi cluster, ove è necessario),c) sia flussi cluster-CRESSAN. Solo nei casi b) e c) la cooperazione applicativa avviene con l’intermediazione del

SPCR/SPCoop.

Si richiede conferma circa la possibilità di poter proporre un modello architetturale (*) che ottimizzi la distribuzione fisica dei nodi ESB/EAI, tenuto anche conto della dimensione molto modesta di alcune aziende e degli stessi policlinici universitari. Si chiede in particolae conferma della possibilità di proporre un modell che vede l’utilizzo di tre nodi fisici, opportunamente dimensionati, relativi alla componente ESB/EAI sui quali raggruppare più cluster di Aziende contemporaneamente. I tre nodi fisici potranno fungere da sistemi di back-up a vicenda ed installati uno presso il CRESSAN e gli altri due presso i due siti che fungeranno da disaster recovery.

(*) Questo modello considera come principio ispiratore quanto riportato nel disciplinare tecnico nelle note a pag. 38 in cui si esprime il concetto distintivo che la localizzazione logica delle componenti non necessariamente corrispondente ad una localizzazione fisica degli stessi.

Si vedano la figura 4 e il capitolo 6.3.4 Il sistema informativo sanitario ospedaliero nel disciplinare di gara ed l’allegato N. 4 REQUISITI DEL SISTEMA INFORMATIVO

SANITARIO OSPEDALIERO in cui si parla e si descrivono i cluster ospedalieri all’interno di ciascuna Azienda Sanitaria. Si rimanda comunque alla proposta progettuale dell’impresa concorrente.

Si richiede chiarimenti circa l’affermazione riportata nel disciplinare tecnico a pagina 58 in cui si dice: “…Per ogni cluster territoriale ospedaliero che fa capo a ciascuna ASL, cui va aggiunto l’Ospedale Brotzu della AO medesima, devono essere messi in funzione, secondo le modalità e le specifiche tecniche che verranno approfondite nel disciplinare tecnico, i seguenti sottosistemi-componenti, uno per ciascuna della Aziende Sanitarie regionali: ADT, PS, Gestione Order Entry, SO, Gestione Centro Trasfusionale ..”. Questa stessa frase viene ripresa a pagina 3 dell’allegato 4.

In riferimento a detta affermazione si richiede come debbano essere considerati i due policlinici universitari se come elementi assimilabili a loro volta ad un cluster al pari della AO o possono far riferimento al clistere dell’ASL a ciascuno più prossima

I Policlinici di Sassari e Cagliari sono interessati al progetto del SIO, ma vanno aggregati rispettivamente al cluster territoriale di Sassari e di Cagliari.

Si chiede conferma che nel rispetto dell’art. 37, comma 12, d.lgs. n. 163/2006, le RTI selezionate (giusta determinazione

n. 836 del 10/08/2006), possono modificare la loro composizione, ma senza modificare il ruolo dell’impresa mandataria (capogruppo), aggiungendo al RTI una o più imprese mandanti, in possesso dei requisiti minimi previsti dal bando di gara in sede di qualificazione, anche se non precedentemente prequalificate.

Nell’ipotesi di risposta affermativa, si chiede altresì quale

La risposta è negativa. E’ possibile modificare la composizione delle RTI soltanto accorpando RTI e/o Aziende ammesse in fase di prequalifica

ulteriore documentazione dovrà essere prodotta.

Nel Disciplinare di gara al paragrafo 13.1.4 pag. 116 (personale impiegato dall'aggiudicatario) si richiede

di allegare 19 curricula vitae. Infatti è scritto: "In sede di offerta tecnica le Imprese concorrenti

dovranno allegare il curriculum vitae del capo progetto (program manager) che verrà nominato nel caso

di aggiudicazione dell’appalto e un capo progetto (project manager) e un responsabile tecnico per

ciascuno dei seguenti componenti o sotto-sistemi:

• Sistema Sanitario Amministrativo

• Sistema Sanitario Direzionale

• Sistema Sanitario Epidemiologico

• Sistema Gestore Risorse - CUP

• Sistema Sanitario Ospedaliero

• Sistema Attività Assistenziali e di Prevenzione

• Sistema infrastrutturale

• Sistema di integrazione delle componenti

• Responsabile della qualità 2

L’impresa dovrà inoltre allegare all’offerta tecnica anche il curriculum vitae dell’esperto in standards internazionali

nell’area clinico/sanitaria utilizzato per la realizzazione del progetto."

Nello schema di "Offerta tecnica", riportato nell’ “Allegato A Documentazione” sono invece previsti solo quattordici CV, mancando nell'indice, ad esempio, il curriculum vitae del Responsabile Tecnico per il Sistema informativo sanitario ospedaliero e il curriculum vitae dell'esperto in standards internazionali.

Si chiede un chiarimento in merito.

Inoltre, nel caso sia necessario attenersi a quanto indicato nel Disciplinare, si chiede se sia possibile illustrare i venti curricula in un unico capitolo numerato come "8. Curricula

Vitae", che includa venti paragrafi ognuno corrispondente a un

o Sistema Sanitario Amministrativo

o Sistema Sanitario Direzionale

o Sistema Sanitario Epidemiologico

o Sistema Gestore Risorse - CUP

o Sistema Sanitario Ospedaliero oSistema Attività Assistenziali e di Prevenzione

o Sistema infrastrutturale

o Sistema di integrazione delle componenti

o Responsabile della qualità

Le Ditte concorrenti dovranno quindi produrre il CV delle figure richieste nel Disciplinare Tecnico:

CURRICULUM VITAE PROGRAM MANAGER

CURRICULUM RESPONSABILE QUALITA’

CURRICULUM VITAE PROJECT MANAGER

Sistema informativo sanitario amministrativo (contabilità, personale, acquisti, pianificazione e controllo)

CURRICULUM VITAE RESPONSABILE

TECNICO Sistema informativo sanitario amministrativo (contabilità, personale,

singolo curriculum.

acquisti, pianificazione e controllo)

CURRICULUM VITAE PROJECT MANAGER

Sistema informativo gestore risorse – CUP

CURRICULUM VITAE RESPONSABILE

TECNICO Sistema informativo gestore risorse – CUP

CURRICULUM VITAE PROJECT MANAGER

Sistema informativo sanitario ospedaliero

CURRICULUM VITAE RESPONSABILE

TECNICO Sistema informativo sanitario ospedaliero

CURRICULUM VITAE PROJECT MANAGER

Sistema informativo sanitario attività assistenziali e di prevenzione

CURRICULUM VITAE RESPONSABILE

TECNICO Sistema informativo sanitario attività assistenziali e di prevenzione

CURRICULUM VITAE PROJECT MANAGER

Sistema informativo sanitario direzionale

CURRICULUM VITAE RESPONSABILE

TECNICO Sistema informativo sanitario direzionale

CURRICULUM VITAE PROJECT MANAGER

Sistema informativo sanitario epidemiologico

CURRICULUM VITAE RESPONSABILE

TECNICO Sistema informativo sanitario epidemiologico

CURRICULUM VITAE PROJECT MANAGER

Sistema infrastrutturale (apparati HW e SW di base)

CURRICULUM VITAE RESPONSABILE

TECNICO Sistema infrastrutturale (apparati HW e SW di base)

CURRICULUM VITAE PROJECT MANAGER

Attività di Integrazione del sistema

CURRICULUM VITAE RESPONSABILE

TECNICO Attività di Integrazione del sistema

CURRICULUM VITAE esperto standard internazionali nell’area clinico/sanitaria.

E’ confermato che deve essere inserito un CV per capitolo.

Si chiede se, nel rispetto della legge sulla privacy, nei Curricula Vitae da produrre nell’offerta tecnica possa, in sostituzione dei dati personali, indicarsi un acronimo (ad esempio iniziali del nome e cognome).

E’ confermato che la produzione dei CV deve essere resa nel rispetto della privacy.

Si richiede un chiarimento su quanto riportato nella sezione

A.7.4.2 dell’allegato 7 a pagina 29. Ci si riferisce in particolare alla frase “…i server che devono essere forniti sono complessivamente 10, con analoga configurazione (ciascuno genericamente: 4 processori Intel 64 bit, 8 Gbyte Ram, doppio disco, doppia alimentazione, doppio raffreddamento, doppia scheda di connessione alla SAN in F.O., s.o, RedHat, VMWare ESX, connessione consolle remota, formato rack, fornitura dotata di rack di alloggiamento).

Come già detto, è preferibile disporre di sistemi blade, con chassis ridondati (n.2 o 3), e collegamenti ridondati con la SAN in F.O. I server vanno installati preso il Data center del

CRESSAN, insieme a tutti gli altri oggetto della fornitura.”.

All’inizio della frase viene evidenziata la richiesta della fornitura di complessivamente 10 server per l’installazione da parte dell’Amministrazione delle PDD necessarie, utilizzate presumibilmente da parte del nodo centrale CRESSAN che dai vari cluster aziendali. Alla fine della frase si richiede che detti server vengano forniti ed installati presso il CRESSAN stesso. Si chiede pertanto conferma del fatto che i server che ospiteranno le PDD dei cluster aziendali saranno ospitati ed instrallati presso il CRESSAN stesso.

I server che sono stati definiti nel paragrafo

A.7.4.2 dell’allegato 7 sono 10 server fisici, ciascuno con caratteristiche di configurazione indicativamente proposte nel paragrafo citato. Questi server, oggetto di fornitura, contribuiscono a realizzare l’infrastruttura di base per il framework SOA denominatoSPCR/SPCoop, che si colloca logicamente in un proprio dominio di rete, e che verrà dotato delle PDD che saranno necessarie. La realizzazione del framework SOA SPCR/SPCoop non è oggetto di fornitura.

Tale framework SOA è installato nello stesso Data Center regionale di cui farà uso il CRESSAN.

Presso ogni cluster aziendale viene previsto un framework SOA che è stato più volte richiamato con l’acronimo ESB/EAI (Enterprise Service Bus/Enterprise Application Integration).

Ciascun framework ESB/EAI in stanzia un proprio dominio di rete, con sue PDD quante ne sono state individuate in base al progetto concettuale e logico del partecipante, e consente la cooperazione applicativa tra applicazioni intra-cluster.

Ciascun framework ESB/EAI di cluster interopera con SPCR/SPCoop sia per comunicare con altri framework ESB/EAI di altri cluster (cooperazione applicativa tra applicazioni inter –cluster), sia per comunicare con le applicazioni su CRESSAN (coperazione applicativa tra applicazioni cluster e applicazioni CRESSAN).

L’insieme di framework ESB/EAI (HW e SW di base compreso) è oggetto di fornitura (9 piattaforme complete di sistema SOA e di HW e SW di base).

Ogni framework ESB/EAI è “ospitato”,ed

installato fisicamente, localmente presso ciascuna ASL/AO.

Per i due policlinici (Cagliari e Sassari), non si deve provvedere a fornire un framework ESB/EAI, in quanto inizialmente le due strutture vengono associate al xxxxxx territoriale ove hanno sede.

Si richiedono maggiori dettagli circa la numerosità delle PDD a cui ci si aspetta di far riferimento. In particolare, si chiede conferma del fatto che si aspetta di far riferimento a 12 PDD così distribuite: 1 PDD per il nodo regionale, 8 PDD per ciascuna delle ASL, 1 PDD per l’AO Brotzu e 2 PDD per i due Policlinici Universitari.

Relativamente ai 2 Policlinici si richiede all’amministrazione di chiarire anche per le PDD, similmente a quanto giù richiesto al quesito 4, circa l’assimilazione di questi alla definizione di cluster e quindi alla necessità di essere dotati di specifiche

PDD.

La risposta al quesito precedente chiarisce anche la domanda posta con questo quesito

Document Metadata

Table of Contents

PROCEDURA RISTRETTA PER L’AFFIDAMENTO DEL

Document Metadata