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. 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. 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. 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 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...
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, l’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. I servizi informatici dovranno garantire almeno il set di elementi di integrazione/interoperabilità e cooperazione applicativa di seguito riportati: • integrazione contabilità-gestione atti: gli atti amministrativi creati devono innescare le relative operazioni contabili e collegati ai capitoli di bilancio, secondo tutte le competenze istituzionali di un ente locale secondo quanto disposto del D. Lgs. n. 267 del 18/08/2000 e successive normative; • integrazioni gestione atti-controlli e monitoraggi per adempimenti obiettivi PEG: il software deve essere personalizzato in modo da svolgere tali funzioni; • integrazione con atti dei servizi demografici in modo da aggiornare la anagrafica del protocollo e le notifiche dei messi da effettuarsi, se necessario, tramite una vista dal software dei servizi demografici in modo che il software a riuso "Simel2" possa attingere in maniera schedulata; • flussi informativi previsti dall’ANAC • integrazioni dirette con i sistemi ANPR per protocollo e messi Anagrafe, se necessario, con una integrazione tramite una vista dal software dei servizi demografici in modo che il software a riuso "Simel2 " possa attingere in maniera schedulata; • integrazioni con controllo di gestione come da documento rilasciato in conferenze per web service dove si evincono i passaggi dei servizi da erogare per le interfacce con la contabilità ADS. Gli applicativi dovranno essere impostati, secondo gli strumenti di programmazione e gestione individuati dalla normativa vigente quali l'organigramma-funzionigramma dell'Ente, il Documento Unico di Programmazione (DUP), il Bilancio e il Piano Esecutivo di Gestione (PEG). Gli applicativi dovranno garantire la possibilità di decentrare ai servizi e ai dipendenti indicati funzioni di consultazione con diverse modalità di visualizzazione di lettura oppure la possibilità di accedere ai soli dati di propria competenza. Il sistema dovrà essere improntato al principio dell’unicità delle operazioni contabili negli atti. Il sistema deve garantire il mantenimento degli accessi e modalità operative differenziate per gli utenti abilitati. Il sistema deve, per quanto possibile, evidenziare agli operatori le situazioni di errore (bloccando l’operatività) ovvero l’incoerenza delle operazioni con messaggi di avviso non bloccanti. Le operazioni di interrogazione possono essere effettuabili su qualsiasi atto o documento del protocollo o dei fascicoli informatici. Non deve essere necessaria nessuna attività di assistenza s...
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. Si riportano nel seguito le caratteristiche generali che il sistema deve avere oltre ai requisiti espressi nei capitoli precedenti. Tali caratteristiche hanno carattere obbligatorio eccetto quelle espressamente indicate come migliorative e/o preferenziali: ID Requisito Obbligatorio/ Migliorativo/ Preferenziale
F1.1 Possibilità di gestire campioni biologici e contenitori nel biobanking, basato su una struttura 1 PATIENT (parent) n SAMPLES (child) n ALIQUOTS (grandchild) n Transactions (great grandchild) obbligatorio F1.2 Assegnazione in automatico di un numero identificativo univoco e NON modificabile per ciascun campione (sample). Assegnazione in automatico di un numero identificativo univoco e NON modificabile per ciascuna aliquota (aliquot) in modo che campioni ed aliquote mantengano le loro identità univoche e separate. obbligatorio