Requisiti funzionali Clausole campione

Requisiti funzionali. Il Fornitore, nell‟ambito del servizio “PaaS - Servizio base” deve garantire la disponibilità per l‟Amministrazione almeno delle seguenti funzionalità base / strumenti a supporto: ▪ possibilità di selezionare uno specifico template PaaS preconfigurato tra quelli disponibili: o solution stack preconfigurati, con le componenti necessarie a configurare uno dei servizi previsti tra le categorie Application Server, Web Server, DBMS, Monitoring del PaaS, almeno tra quelli indicati nel seguito in Tabella 4; o template originati/prodotti da una singola Amministrazione (es. originati dalla virtualizzazione dei propri server e utilizzati quindi per caricare tali server virtualizzati). Il Fornitore deve infatti prevedere funzionalità di upload in appositi slot di template di macchine virtuali, predisposte dalle Amministrazioni in formati standard (ad es. secondo Open Virtualization Format), anche utilizzando i servizi di Cloud Enabling descritti nel successivo paragrafo §1.6. I template creati dalle Amministrazioni dovranno essere disponibili anche in fase di creazione di nuove VM, come già descritto nel paragrafo §1.1.1; o template originati/prodotti da AgID/Consip (es. per sistemi cross-PA) e messi a disposizione in comune tra più Amministrazioni. Il Fornitore deve infatti prevedere appositi slot resi disponibili unicamente ad AgID/Consip per garantire l‟upload dei template. AgID/Consip potranno poi definire quali Amministrazioni da quel momento potranno selezionare tali template in fase di configurazione delle VM. Qualsiasi licenza software eventualmente richiesta dal template selezionato sarà a carico dell‟Amministrazione che selezionerà il template. Ciascuno specifico template selezionato includerà le risorse virtuali base “pre-configurate” (VM con dimensionamento prefissato in termini di CPU, RAM e Storage, come indicato in Tabella 4) nel “taglio” minimo necessario per il corretto utilizzo del server virtuale con il template selezionato. Sarà cura e responsabilità della singola Amministrazione determinare le proprie esigenze specifiche in termini di dimensionamento ottimale delle risorse virtuali; ▪ possibilità per l‟Amministrazione, in un qualsiasi momento di aumentare le risorse elaborative (HD, CPU e RAM) rispetto al taglio minimo della VM associata all‟elemento base del PaaS prescelto, mediante l‟utilizzo delle “Risorse Aggiuntive” previste nel paragrafo §1.1.1 del Servizio VDC. ▪ possibilità di modifica del template, in un qualsiasi momento ed in completa ...

Requisiti funzionali. Si sottolinea che, per completezza, sono da considerarsi parti integranti della presente specifica funzionale tutti i riferimenti bibliografici, documentali e normativi referenziati all’interno del presente documento.

Requisiti funzionali. Il Fornitore, nell‟ambito del servizio “SaaS - Comunicazione Unificata” deve garantire la disponibilità per l‟Amministrazione di servizi applicativi con almeno le seguenti funzionalità base: ▪ acquisto (in un qualsiasi momento) di licenze di sottoscrizione aggiuntive per l‟accesso e l‟utilizzo dei servizi applicativi; ▪ gestione completa del ciclo di vita delle chiamate tra utenti, eseguite in differenti modalità (audioconferenze, voce e video HD, uno a uno, uno a molti); ▪ gestione gruppi di utenti per IM, audio/video conferenze; ▪ possibilità di abilitare in qualsiasi momento la condivisione di desktop, applicazioni e lavagna; ▪ condivisione di audio/video/contenuti tra più di 3 utenti; ▪ pianificazione le audio/video conferenze; ▪ invio messaggi vocali; ▪ registrazione delle audio/video conferenze; ▪ funzionalità avanzate per la creazione e gestione di una riunione da remoto (ad. es. gestione almeno delle funzionalità di “Creatore”, “Membro”, “Relatore”, “Sala di attesa”, “Partecipa da” …), sia in modalità audio/video conferenza che in modalità chat room; ▪ disponibilità delle funzionalità di cronologia e di salvataggio del contenuto di ogni sessione in modo permanente per renderlo disponibile anche al termine di una sessione con la possibilità di eseguire ricerche avanzate (i.e. multi- criterio) all‟interno della cronologia; ▪ integrazione con i contatti personali presenti nel software di gestione della rubrica e verifica della presenza online; ▪ integrazione con strumenti per creare e condividere contenuti digitali durante la riunione (es. integrazione con i principali strumenti di produttività individuale).

Requisiti funzionali. Per il servizio di Backup as a Service sono disponibili cinque profili (Small, Medium, Large, X-Large e XX- Large), differenziati sulla base della quantità [in GB] di spazio di archiviazione disponibile. Il servizio è fatturato a scaglioni sul consumo per mese per gigabyte archiviato.

Requisiti funzionali. Ai fini dell’autorizzazione, l’Ente richiedente deve presentare una chiara descrizione del programma, comprensivo dell’elenco delle prestazioni svolte nelle singole unità operative, ed un regolamento. Il programma ed i regolamenti devono prevedere quanto indicato nell’art.5 dell’accordo 5 agosto 1999 relativo all’atto di intesa Stato-Regioni sui requisiti minimi standard per l’autorizzazione al funzionamento dei servizi privati di assistenza alle persone dipendenti da sostanze di abuso.

Requisiti funzionali. Il processo di iscrizione all’Albo IAP, da automatizzare con l’applicativo web, è il seguente: 1. il Richiedente presenta alla Provincia la domanda di iscrizione all’Albo IAP; 2. la Provincia carica a sistema i dati riportati nella domanda; 3. la Provincia avvia l’istruttoria per l’iscrizione all’albo e il rilascio del relativo certificato, con l’esecuzione della verifica (attraverso una checklist dei requisiti) sul possesso di determinati requisiti, legati al reddito e alle competenze professionali del richiedente: a) Se le verifiche hanno esito positivo, il richiedente è iscritto al registro IAP e gli viene rilasciata la relativa certificazione; b) Se le verifiche non hanno esito positivo: - il richiedente che si impegna ad acquisire i requisiti mancanti entro 24 mesi dal rilascio, è iscritto al registro IAP e gli viene rilasciata la relativa certificazione “sotto condizione”; - il procedimento viene chiuso con esito negativo e non avviene alcuna iscrizione al registro IAP. 4. Per certificazioni “sotto condizione”: a) il Richiedente presenta, entro 24 mesi, alla Provincia la documentazione che attesta il possesso dei requisiti non soddisfatti al momento dell’iscrizione al registro; b) La Provincia, allo scadere dei 24 mesi, verifica l’acquisizione dei requisiti mancanti: - Se l’esito della verifica è positivo, lo stato “sotto condizione” viene eliminato e l’iscrizione all’albo diventa definitiva; - Se l’esito della verifica è negativo, si procede alla radiazione dall’albo. In tal caso la Provincia informa esplicitamente il richiedente della revoca della certificazione e della radiazione dall’albo. - stampa in formato pdf della documentazione necessaria a supportare il procedimento: certificazioni, notifiche, registro, etc.; - gestione scadenzario delle certificazioni “sotto condizione”.

Requisiti funzionali. Sulla base delle esigenze di carattere generale sono di seguito elencati alcuni tra i requisiti principali che il nuovo sistema informativo dovrà rispettare. Tali requisiti sono riassunti nel seguito: - Completezza dal punto di vista funzionale; - Efficienza nel supporto di tutte le attività; - Modernità tecnologica; - Modularità, scalabilità, apertura verso le nuove tecnologie web e di facile estensione verso altri enti, e possibilità di evoluzione del sistema nella sua configurazione in conseguenza alle mutevoli esigenze; - Integrazione: i diversi sottosistemi e le applicazioni, devono supportare in modo adeguato la cooperazione e lo scambio di informazioni tra i vari enti della Regione; - Rispondenza alla normative comunitarie, nazionali e regionali: la soluzione dovrà essere coerente con le indicazioni emanate dal dipartimento della funzione pubblica, dal CNIPA, dalla Regione Sardegna nonché dalla Commissione della Comunità Europea, oltre che dalla vigente normativa di legge sia in materia agli aspetti tecnologici che architetturali dell'informatizzazione nella pubblica amministrazione; particolare riguardo sarà dovuto alle problematiche inerenti il trattamento dei dati personali e all'adozione di standard per la pubblica amministrazione; - Programmazione e controllo direzionale: il sistema informativo deve facilitare e supportare il controllo direzionale, in generale semplificare il monitoraggio dei parametri di efficienza ed efficacia dei singoli uffici; - Affidabilità ad elevato livello sulle informazioni e sui processi; - Indipendenza da hardware, software di base e da (sistema multi-piattaforma, multi- tasking, Operating System independent); - In grado di interfacciarsi con applicativi esterni per l’acquisizione/upload dei dati - In grado di eseguire anteprime di stampa, stampe locali o remote, invio di mail; - Corredato da strumenti di reporting configurabili dall'utente; - In grado di integrarsi con gli ambienti e prodotti di informatica individuale (fogli di scrittura, fogli elettronici, ecc.); - Fornito di help in linea; - Dotato di strumenti di configurazione dei profili con tracing delle relative attività; - Elevato livello di parametrizzazione e configurabilità: il sistema dovrà consentire un elevato livello di parametrizzazione limitando al minimo gli interventi di customizzazione e personalizzazione; tutti i parametri variabili dovranno poter essere gestiti direttamente dagli utenti responsabili del centro.

Requisiti funzionali. Sono richiesti i seguenti requisiti funzionali: in caso di avaria dell'attrezzatura dovrà essere garantito lo svuotamento del cassone (apertura portellone e ribaltamento cassone) tramite centralina a comando manuale; il terminale del tubo di scarico del motore termico di trazione orientato verso l'alto; la visibilità sulla spazzola dal posto di guida sia durante il servizio di spazzamento sul lato destro del veicolo e sia durante il servizio di spazzamento sul lato sinistro: questo requisito povrà essere garantito con l'applicazione di specchi aggiuntivi per ogni lato cabina o altro sistema equivalente (ad es. videocamere con schermo LCD); il gruppo spazzante, in caso di urto con un ostacolo quale un palo o un marciapiede dovrà rientrare automaticamente In sagoma senza danneggiarsi, questa prescrizione dovrà essere garantita prevedendo il gruppo spazzante laterale del tipo "trainato", cioè con l'ancoraggio del braccio portante la spazzola posizionato anteriormente alla spazzola stessa; la possibilità di cambiare il senso di marcia del veicolo, in servizio con attrezzatura in funzione, senza causare danni agli organi di trasmissione del veicolo stesso; tutti i componenti funzionali, di sicurezza, e di controllo degli impianti (serbatoio olio idraulico, filtri, distributori oleodinamici, valvole, manometri, elettrovalvole, fusibili, relè ecc.) dovranno essere facilmente accessibili dall'esterno; dovrà essere realizzata per quanto possibile l'installazione centralizzata dei componenti idraulici ed elettrici quali filtri, distributori oleodinamici, valvole, manometri, elettrovalvole, fusibili, relè e pressostati; le elettrovalvole dovranno essere del tipo con rilevatore ottico (led) di stato (on-off); i tecnici Asp potranno accettare l'installazione senza rilevatore delle elettrovalvole che non sono reperibili in commercio di questo tipo; impianto elettrico realizzato secondo le norme vigenti degli autoveicoli, cablaggi con cavi di colore differente o numerati, grado di protezione minimo IP 66 CEI EN 60529; tutti i collegamenti elettrici dovranno essere realizzati con connettori elettrici di facile smontaggio e rimontaggio; tutti i terminali delle tubazioni idriche ed idrauliche dovranno essere dotati di raccordi filettati e/o innesti a sgancio rapido facilmente smontabili; Il collegamento dei tubi non dovrà essere assicurato con fascette stringitubo; dovrà essere previsto, se possibile, un unico serbatolo combustibile per entrambi I motori diesel (motore cabi...

Requisiti funzionali. Il sistema oggetto del presente capitolato tecnico (d’ora in avanti, sistema) prevede una serie di funzionalità generali del servizio, nonché aspetti specifici dell’applicativo richiesto. Si sottolinea che, per completezza, sono da considerarsi parti integranti della presente specifica funzionale tutti i riferimenti tecnici e tecnologici (requisiti non funzionali), bibliografici, documentali e normativi referenziati all’interno del presente documento. I requisiti funzionali sono tutti da considerarsi “obbligatori” (ovvero, ATS li ritiene indispensabili per l’avvio del sistema in produzione). I requisiti funzionali e/o non funzionali "secondari” (ovvero, che potranno essere rilasciati dall’Aggiudicatario in tempi successivi, previo accordo con ATS) sono opportunamente evidenziati nel documento col testo “requisito opzionale”.

Requisiti funzionali. Il presente capitolato trae, come base di partenza e include quanto definito all’interno dei requisiti minimi funzionali dell’allegato 2° Capitolato Tecnico Speciale Lotti Applicativi per le aree tematiche trattate dal lotto 2 Cartella Clinica ed Enterprise Imaging CENTRO – SUD. Le funzionalità documentali lì citate vengono ampliate nel capitolo 4.1 del presente capitolato. In aggiunta, vengono specificate nel capitolo 4.2 le caratteristiche delle funzionalità di supporto all’attività clinica e assistenziale. Vengono inoltre esplicitati i requisiti minimi che la soluzione applicativa proposta dovrà soddisfare, al netto dei requisiti espressi nel Capitolato Tecnico Speciale dell’Accordo Quadro CONSIP “Servizi Applicativi in ambito “SANITA’ DIGITALE - Sistemi Informativi Clinico-Assistenziali” Per Le Pubbliche Amministrazioni del SSN” ed eventuali proposte migliorative e ampliative che dovessero essere presentate dai fornitori. Eventuali proposte migliorative ed ampliative saranno considerate come opzionali e, come tali, sarà facoltà di ciascun ES valutarne l’adozione. Nel contesto evolutivo della sanità abruzzese in cui si pongono gli ES e come definito all’interno del “Piano Sanità Digitale” di Regione Abruzzo per il triennio 2021-2023, non sono presenti linee guida in tema CCER comuni a tutti gli enti sanitari regionali, ma è presente una pluralità disomogenea di soluzioni CCE verticali alla singola disciplina e Unità Organizzativa. Pertanto, nel tentativo di uniformare il parco applicativo a disposizione degli enti sanitari e garantire una soluzione applicativa che possa ottimizzare la convergenza e l’integrazione di tutti i dati clinici dei pazienti e garantire la copertura di tutti i reparti, è richiesta in fase di rilancio competitivo la presentazione di un’architettura di funzionalità applicative CCER in grado di colmare le differenze e contemporaneamente rispondere alle diverse esigenze di ciascun ES. Ciò premesso, occorre sottolineare che la soluzione proposta dovrà essere rispondente alle specifiche architetturali e applicative identificate dal SSR abruzzese e definite nell’allegato B “Strategia digitale della Sanità della regione Abruzzo”. La soluzione CCER deve quindi potersi adattare al contesto evolutivo di riferimento della SSR. Dal punto di vista funzionale, la CCER dovrà configurarsi come una soluzione trasversale (rappresentata verticalmente in figura) che garantisca funzionalità di carattere generali grazie a cui sia possibile la raccolta...