Risultati
182 risultati
-
AGID
2. Riferimenti e sigle
Tabella 2.3 Termini e definizioni. [AgID]. Agenzia per l’Italia Digitale. [PDND]. Piattaforma Digitali Nazionale Dati di cui all’articolo 50-ter del CAD. [Infrastruttura interoperabilità PDND]. L’infrastruttura tecnologica di cui al comma 2 dell’articolo 50-ter del CAD, volta a favorire l’interoperabilità dei sistemi informativi e delle basi di dati. [CAD]. Codice Amministrazione Digitale, D.lgs. 7 marzo 2005, n. 82. [MoDI]. Modello di Interoperabilità della PA definito dalle Linee Guida emanate in materia da AgID ai sensi dell’articolo 71 del CAD. [QoS]. Quality of Service, utilizzato per indicare i parametri usati per caratterizzare la qualità degli e-service. [SLI]. Service-Level Indicator, ovvero metriche atte a misurare l’efficienza dei servizi individuati dall’erogatore. [SLO]. Service-Level Objective, ovvero gli obiettivi degli SLI per i servizi definiti dall’erogatore. [SLA]. Service Level Agreement ovvero accordi sul livello di servizio frutto della contrattazione tra Erogatore e Fruitore. [Gestore]. La società PagoPA S.p.A a cui è affidata la realizzazione e la gestione dell’Infrastruttura interoperabilità PDND promossa dalla Presidenza del Consiglio dei Ministri ...
-
AGID
4. Definizioni
L’Infrastruttura interoperabilità PDND favorisce i processi di co-design individuati nella Governance della Trasformazione del Piano Triennale per l’informatica nella Pubblica Amministrazione tramite il meccanismo dei Template. Per Template e-service si intende la definizione di un modello dei descrittori di un e-service in cui restano liberi alcuni elementi operativi necessari alla reale operatività dell’e-service. In questa maniera il Template e-service resta un modello astratto a cui gli aderenti devono attenersi durante il processo di implementazione. Il Template e-service descrive quindi come un e-service DEVE erogare il servizio non entrando nel merito di come verrà implementato né indicando le tecnologie adottate per l’implementazione delle logiche di business. Solo dopo il processo di implementazione del Template e-service si avranno una o più istanze di un e-service reale pronto alla pubblicazione sul Catalogo API. Il co-design coinvolge:. API Co-design Manager: è un Aderente, che all’interno del gruppo di Pubbliche Amministrazioni interessate al co-design di un e-service, disegna e registra il Template e-service sull’Infrastruttura interoperabilità PDND provvedendo a:. dichiarare, nel rispetto del MoDI, il Template e-service delle API che implementa l’e-service;. definire quali informazioni sono necessarie per implementare il Template e renderlo operativo, in questa maniera vengono definiti i margini di libertà entro i quali può agire chi vuole implementare l’e-service. Implementatore: è un Aderente che decide di implementare l’e-service descritto da un Template e-service e provvede a:. compilare il Template e-service definito dal API Co-design manager nel rispetto dei margini di libertà previsti;. prendersi carico dell’implementazione della logiche di business per istanziare l’e-service. L’Infrastruttura interoperabilità PDND permette la ricerca e l’identificazione del riferimento del Template e-service registrato dall’API Co-design manager a tutte le Aderenti. L’Infrastruttura interoperabilità PDND promuove e comunica la pubblicazione di nuove versioni di Template e-service e supporta la pubblicazione sul Catalogo API delle istanza implementate dagli Aderenti ...
-
AGID
12. Livelli di servizio della Infrastruttura interoperabilità PDND
12.2.1. Tempestività di ripristino dell’operatività. Il presente indicatore si applica a non conformità funzionali e non funzionali rilevate dagli Aderenti ed è calcolato come la differenza in ore tra il momento dell’avvio del processo di risoluzione del malfunzionamento e il termine della risoluzione delle stesso da parte della Infrastruttura interoperabilità PDND. La fonte per la determinazione dell’indicatore è rappresentato dal momento temporale delle comunicazione di merito realizzate tra l’Infrastruttura interoperabilità PDND e gli Aderenti (presa in carico del ticket da parte del Gestore). 12.2.2. Tempestività di risposta a segnalazioni di anomalie. Il presente indicatore si applica a non conformità funzionali e non funzionali evidenziate dagli Aderenti. L’indicatore è calcolato come la differenza in ore tra il momento della segnalazione e la presa in carico della stessa da parte della Infrastruttura interoperabilità PDND. La fonte per la determinazione dell’indicatore è rappresentato dal momento temporale delle comunicazione di merito realizzate tra l’Infrastruttura interoperabilità PDND e gli Aderenti ...
-
AGID
6. Gestione degli Attributi degli Aderenti
L’Infrastruttura interoperabilità PDND registra gli Attributi degli Aderenti associati ad ogni singolo Aderente. L’Infrastruttura interoperabilità PDND assicura la gestione delle seguenti tipologie di Attributi degli Aderenti:. Dichiarati: i Fruitori dichiarano di possedere sotto la loro responsabilità, gli attributi richiesti al fine di soddisfare i Requisiti di Fruizione degli e-service per cui richiedono la stipula di un Accordo di Interoperabilità. L’Infrastruttura interoperabilità PDND registra gli attributi Dichiarati per singolo Aderente. Questa tipologia di attributi è immediatamente spendibile ai fini dell’autorizzazione all’accesso agli e-service in quanto la loro veridicità è garantita dal Fruitore sotto la sua esclusiva responsabilità. Verificati: i Fruitori dichiarano gli attributi posseduti al fine di soddisfare i Requisiti di Fruizione degli e-service per cui richiedono la stipula di un Accordo di Interoperabilità. L’Infrastruttura interoperabilità PDND registra gli attributi Dichiarati per singolo Aderente in relazione allo specifico Accordo di Interoperabilità e , a differenza degli attributi Dichiarati, a valle del riscontro positivo da parte dell’Erogatore di uno degli e-service richiesti dal Fruitore che prevedano lo stesso Attributo. L’Infrastruttura interoperabilità PDND assicura la memorizzazione del momento temporale della registrazione degli Attributi degli Aderenti. In merito agli Attributi Verificati si precisa che:. Un Erogatore PUÒ definire il periodo temporale di validità di un attributo Verificato ai fini della fruizione dei propri e-service, scaduto il quale l’attributo dovrà essere verificato nuovamente. Alla scadenza del periodo di validità individuato dall’Erogatore, l’attributo resta valido salvo il caso di un esplicito riscontro negativo della verifica fornito anche solo da un Erogatore. Un Erogatore PUÒ ritenere valida la verifica degli attributi realizzata da altri Erogatori in sede di stipula di un Accordo di Interoperabilità per la fruizione dei propri e-service. Nel caso in cui l’esito della verifica effettuata da un Erogatore relativamente ad un attributo di un Fruitore contrasti con quanto in precedenza constatato da un altro Erogatore per lo stesso Fruitore, l’Infrastruttura interoperabilità PDND comunica la circostanza agli Erogatori interessati invitandoli a dirimere l’ambiguità e a segnalare l’eventuale volontà di sospendere gli Accordi di Interoperabilità per i quali l’attributo risulta abilitante ai fini dell’accesso ai relativi e-service. L’Infrastruttura interoperabilità PDND DEVE inserire nel Registro degli Attributi:. gli attributi proposti dagli Erogatori al momento della definizione dei Requisiti di Fruizione degli e-service pubblicati sul Catalogo API. Gli Erogatori, al momento della definizione dei Requisiti di Fruizione dei propri e-service, DEVONO verificare se nel Registro degli Attributi sono presenti gli Attributi degli Aderenti a loro necessari. Effettuata la predetta verifica, gli Erogatori DEVONO:. in caso di riscontro negativo, proporre la definizione di un nuovo attributo specificando la relativa tipologia richiesta (Dichiarato o Verificato). Gli Erogatori, nel proporre la definizione di un nuovo attributo alla Infrastruttura interoperabilità PDND, DEVONO associare, quando possibile, all’attributo in questione riferimenti unici presenti nelle fonti autorevoli integrate sull’Infrastruttura interoperabilità PDND (ad esempio, riferimento normativo gestito dal sistema Normattiva). Ricevuta la proposta di definizione di un nuovo attributo formulata da un Erogatore, l’Infrastruttura interoperabilità PDND provvederà ad aggiungere l’attributo al Registro degli Attributi e comunicare tale circostanza all’Erogatore. L’Infrastruttura interoperabilità PDND DEVE mettere a disposizione del soggetto competente gli strumenti necessari a supporto della ispezione periodica alla ricerca di eventuali attributi equivalenti all’interno Registro degli Attributi. Nel caso in cui il soggetto competente constati la presenza di due o più attributi equivalenti, l’Infrastruttura interoperabilità PDND DEVE agevolare la comunicazione della circostanza agli Aderenti interessati coinvolti negli Accordi di interoperabilità che includono l’utilizzo dei suddetti attributi. Gli Aderenti interessati DEVONO comunicare le loro deduzioni sugli attributi equivalenti. In caso di riscontro positivo sull’equivalenza degli attributi a seguito dell’avallo dagli Aderenti, con l’obiettivo di ridurre lo sforzo di adeguamento degli aderenti, l’Infrastruttura interoperabilità PDND DEVE permettere agli Aderenti Erogatori:. la migrazione degli Accordi di interoperabilità precedentemente stipulati, dagli e-service non normalizzati verso i nuovi e-service normalizzati, prevedendo un’accettazione e conferma esplicita da parte dei Fruitori coinvolti. L’Infrastruttura interoperabilità PDND provvede a:. recepire le variazioni comunicate dalle fonti autorevoli integrate sull’Infrastruttura interoperabilità PDND (ad esempio aggiornamento del riferimento normativo ove segnalato dal sistema Normattiva), determinare se gli Attributi associati ai riferimenti unici indicati nelle variazioni ricevute sono Dichiarati o Certificati, e segnalare agli Aderenti interessati la necessità di valutare l’impatto delle variazioni sopravvenute. Gli Aderenti DEVONO segnalare all’Infrastruttura interoperabilità PDND ogni variazione sopravvenuta di loro conoscenza in relazione agli attributi, e nello specifico:. i Fruitori DEVONO segnalare le variazioni relativamente agli attributi verificati da essi indicati;. gli Erogatori DEVONO segnalare le variazioni relativamente agli attributi verificati relativi ad Accordi di interoperabilità dei propri e-service. L’Infrastruttura interoperabilità PDND, ricevute le segnalazioni di cui sopra, DEVE comunicare le circostanza agli Aderenti interessati che valutano l’impatto sugli Accordi di interoperabilità di loro interesse e comunicano alla Infrastruttura interoperabilità PDND le loro decisioni in merito agli stessi (mantenimento, sospensione o terminazione). ...
-
AGID
5. Accreditamento degli Aderenti
Chiunque può richiedere l’accreditamento sull’Infrastruttura interoperabilità PDND mediante il Processo di accreditamento, che prevede sommariamente i seguenti passaggi:. soggetto Aderente, qualora si tratti di persona fisica;. del rappresentante legale o di un suo delegato, qualora l’Aderente sia una persona giuridica;. 2. qualificazione del soggetto Aderente come pubblica amministrazione, gestore di pubblico servizio o società a controllo pubblico - ai sensi dell’articolo 2, comma 2 del CAD - oppure come soggetto privato;. 3. invio, da parte della Infrastruttura interoperabilità PDND al domicilio digitale dell’Aderente, della comunicazione recante le informazioni concernenti alla richiesta di accreditamento e il codice di controllo necessario ad abilitare la prosecuzione di tale processo;. 4. sottoscrizione con firma elettronica ai sensi del Regolamento eIDAS della Lettera di Adesione da parte dell’Aderente e relativo caricamento sulla Infrastruttura interoperabilità PDND;. 5. sottoscrizione della Lettera di Adesione da parte del Gestore e relativa disponibilità sull’Infrastruttura Interoperabilità PDND. La conclusione del Processo di accreditamento determina:. nei confronti dei soggetti privati l’abilitazione all’utilizzo delle sole funzionalità previste per il ruolo di Fruitore;. l’abilitazione del legale rappresentante dell’Aderente o del suo delegato, in qualità di Utente dell’Aderente, ad utilizzare per conto dell’Aderente le funzionalità rese disponibili dall’Infrastruttura interoperabilità PDND. Il Processo di accreditamento è dettagliatamente disciplinato nell’Allegato 1. ...
-
AGID
3. Ambito di applicazione
3.1.1. Soggetti erogatori nella Infrastruttura interoperabilità PDND. Le presenti Linee Guida sono destinate ai soggetti di cui all’articolo 2, comma 2, del CAD, i quali, per il tramite della Infrastruttura interoperabilità PDND, favoriscono la conoscenza e l’utilizzo del patrimonio informativo detenuto per finalità istituzionali nonché la condivisione dei dati con i soggetti che hanno diritto di accedervi ai fini dell’attuazione dell’articolo 50 del CAD e della semplificazione degli adempimenti dei cittadini e delle imprese, in conformità alla disciplina vigente, assicurando le modalità di scambio telematico per il tramite di API così come previsto dal MoDI. In particolare, i soggetti di cui all’articolo 2, comma 2, del CAD attuano le Linee Guida al fine di condividere i dati e le informazioni da essi detenuti, assicurando:. l’implementazione di interfacce di programmazione delle applicazioni accessibili tramite Internet (di seguito API) conformi alle [LG INTEROPERABILITÀ TECNICA];. la registrazione delle API, di cui al precedente punto, nel Catalogo API reso disponibile dell’Infrastruttura interoperabilità PDND. In tale contesto, i soggetti di cui all’art. 2, comma 2, del CAD agiscono in veste di soggetti erogatori. 3.1.2. Soggetti fruitori nella Infrastruttura interoperabilità PDND. Le Linee Guida sono rivolte, altresì, ai soggetti privati che, unitamente ai citati soggetti di cui all’art. 2, comma 2, del CAD, sono abilitati a fruire della PDND al fine di accedere ai dati e alle informazioni ivi resi disponibili, previa:. sottoscrizione degli Accordi di Interoperabilità nel Catalogo API, resi disponibili dall’Infrastruttura interoperabilità PDND. In tale contesto, i soggetti di cui all’art. 2, comma 2 del CAD e i soggetti privati agiscono in qualità di soggetti fruitori della PDND. 3.1.3. Gestore della Infrastruttura interoperabilità PDND. Le Linee guida, infine, sono rivolte altresì a PagoPA S.p.A. che le attua in merito alla progettazione, sviluppo e gestione dell’Infrastruttura interoperabilità PDND nella sua qualità di gestore, ai sensi dell’articolo 8, commi 2 e 3 del decreto legge 14 dicembre 2018, n. 135, convertito in legge 11 febbraio 2019, n. 12 ...
-
AGID
7. Catalogo API nella Infrastruttura interoperabilità PDND
Il MoDI individua nelle [LG INTEROPERABILITÀ TECNICA] il Catalogo delle API quale componente, unica e centralizzata, che assicura alle parti coinvolte nel rapporto di erogazione e fruizione la consapevolezza sulle API disponibili e, per ognuna di esse, i livelli di servizio dichiarati. Il Catalogo API è realizzato al fine di:. agevolare la gestione del ciclo di vita degli e-service;. mitigare la creazione di interfacce ridondanti e/o con semantica sovrapposta. Il Catalogo API permette agli Erogatori la registrazione e pubblicazione degli e-service. La registrazione degli e-service è realizzata dagli Erogatori che DEVONO:. definire i Requisiti di Fruizione individuando gli attributi che devono essere posseduti dai Fruitori per accedere allo specifico e-service. La pubblicazione degli e-service è realizzata dagli Erogatori per rendere gli stessi disponibili agli Aderenti che soddisfano i Requisiti di Fruizione definiti. Le informazioni presenti nel Catalogo API sono nella responsabilità degli Erogatori, che DEVONO provvedere alla gestione del ciclo di vita dei propri e-service per il tramite dei propri Utenti degli Aderenti oppure delegando questo compito a uno o più Capofila. Il Catalogo API permette ai Fruitori di consultare l’elenco degli e-service pubblicati dagli Erogatori al fine di conoscerne le modalità di accesso e i Requisiti di Fruizione, nonché verificarne l’utilità di utilizzo per il raggiungimento delle proprie finalità. Ogni e-service pubblicato sul Catalogo API si compone delle seguenti parti:. di una interfaccia (idl) per usufruire dell’e-service;. la documentazione accessoria e manualistica per l’utilizzo del e-service. Gli Erogatori, relativamente ai singoli e-service registrati nel Catalogo API, DEVONO assicurare l’utilizzo di una delle tecnologie indicata dal MoDI e, in particolare, dalle [LG INTEROPERABILITÀ TECNICA] attraverso la definizione di interfacce. Nella definizione dei propri e-service, gli Erogatori DEVONO prevedere un campo per l’inoltro da parte dei Fruitori del riferimento ai documenti informatici che possano provare la legittimità dello specifico trattamento dei dati personali effettuato in occasione di ogni singolo utilizzo degli e-service. In occasione di ogni singolo utilizzo degli e-service a seguito della stipula di un Accordo di Interoperabilità:. l’Erogatore NON DEVE dare seguito alla richiesta da parte del Fruitore in assenza del suddetto riferimento. La raccolta e la memorizzazione dei riferimenti ai documenti informatici che possano provare la legittimità degli specifici trattamenti dei dati personali effettuati in occasione di ogni singolo utilizzo di un e-service non avviene sulla Infrastruttura interoperabilità PDND. Nel caso in cui il Fruitore sia un soggetto privato, gli stessi DEVONO implementare e assicurare la disponibilità di una API per recuperare i documenti che attestano la legittimità dello specifico trattamento dei dati personali a partire dal riferimento indicato dal Fruitore nel singolo utilizzo dell’e-service. Contestualmente all’utilizzo degli e-service:. l’Erogatore DEVE memorizzare la richiesta del Fruitore e associarla univocamente al suddetto riferimento, assicurandone l’autenticità e l’integrità;. il Fruitore e l’Erogatore DEVONO assicurare, in qualsiasi momento, l’accesso dell’interessato e degli organi di controllo alle informazioni memorizzate. Per la pubblicazione degli e-service sul Catalogo API, gli Erogatori DEVONO assicurare la disponibilità di un’interfaccia utilizzabile dai Fruitori. Gli Erogatori DOVREBBERO:. utilizzare i vocabolari controllati e le ontologie definiti in attuazione della “strategia nazionale dati” di cui al comma 4 dell’articolo 50-ter del CAD per la metadatazione dei dati oggetto dei propri e-service nelle modalità supportate dall’Infrastruttura interoperabilità PDND. Relativamente agli e-service pubblicati, gli Erogatori NON POSSONO modificare elementi che impattano sui Fruitori e gli Accordi di interoperabilità già stipulati. Gli Erogatori NON POSSONO dismettere una versione di e-service in presenza di un Accordo di Interoperabilità attivo che ne consente l’utilizzo da parte di un Fruitore. L’Allegato 2 individua le modalità che gli Erogatori DEVONO attuare per registrare, pubblicare e aggiornare le informazioni relative ai propri e-service sul Catalogo API. L’Allegato 2 individua le modalità che i Fruitori DEVONO attuare per consultare l’elenco degli e-service pubblicati sul Catalogo API. ...
-
AGID
9. Analisi del rischio sulla protezione dei dati personali
A valle della stipula dell’Accordo di Interoperabilità per un determinato e-service, il Fruitore, per abilitare l’utilizzo dello stesso relativamente a una specifica finalità, DEVE effettuare, sotto la propria esclusiva responsabilità e tramite gli strumenti messi a disposizione dall’Infrastruttura interoperabilità PDND, l’analisi del rischio sulla protezione dei dati personali con riferimento al trattamento derivante dalla fruizione dell’e-service. Tale analisi del rischio DEVE prevedere almeno i seguenti aspetti:. dichiarazione della finalità per cui il Fruitore intende accedere ai dati personali messi a disposizione mediante l’e-service;. riflessione in merito all’effettivo rispetto dei principi di cui all’articolo 5 del GDPR nella fruizione dell’e-service per la specifica finalità dichiarata;. conferma dell’avvenuta individuazione del periodo di conservazione dei dati personali ottenuti mediante la fruizione dell’e-service. Il Fruitore DEVE effettuare l’analisi del rischio sulla protezione dei dati personali ogni volta che intende fruire di uno specifico e-service, oggetto di un Accordo di Interoperabilità già stipulato, per una nuova e differente finalità. ...
-
AGID
3. Ciclo di vita degli e-service
Per descrittori degli e-service si intende l’insieme di dati registrati per un determinato e-service e il cui insieme fornisce le informazioni sulle caratteristiche e il funzionamento del e-service stesso. I descrittori degli e-service sono definiti dagli Erogatori attraverso la descrizione della natura dei propri e-service. Gli e-service di un Erogatore sono resi disponibili ai Fruitori attraverso la pubblicazione sul Catalogo API dello specifico descrittore di e-service. Un Erogatore DEVE definire per ogni e-service una delle tecnologie previste nel MoDI (quali REST, SOAP, …). Un Erogatore PUÒ deprecare la pubblicazione di un descrittore di e-service per esprimere la volontà di non accettare nuovi Fruitori per il relativo e-service. Un Erogatore PUÒ pubblicare una nuova versione di un descrittore di e-service previa deprecazione della versione precedente. La nuova versione di un descrittore di e-service DEVE assicurare l’invarianza dei requisiti di fruizione e del modello di interoperabilità applicato per essa. Alla pubblicazione di una nuova versione di un descrittore di e-service, l’Infrastruttura interoperabilità PDND DEVE comunicare tale circostanza ai Fruitori che hanno stipulato un Accordo di interoperabilità per l’e-service. Un Erogatore NON PUÒ avere più di un descrittore di e-service in stato “attivo” per un dato e-service. Gli Erogatori DEVONO prevedere un campo per l’inoltro, da parte dei Fruitori, del riferimento ai documenti informatici che possano provare la liceità dello specifico trattamento dei dati personali (ci si riferisce ad esempio al consendo dell’interessato nei casi di applicazione dell’articolo 6 paragrafo 1 lettera del GDPR). Nel caso in cui l’Erogatore preveda soggetti privati tra i Fruitori di un proprio e-service, lo stesso Erogatore DEVE definire per l’e-service una API che i Fruitori privati DEVONO implementare per assicurare il recupero dei documenti che attestano la liceità dello specifico trattamento dei dati personali. L’Infrastruttura interoperabilità PDND DEVE archiviare una versione di un descrittore di e-service deprecata dall’Erogatore nel caso in cui non siano stati sottoscritti Accordi di Interoperabilità per quello specifico descrittore di e-service. 3.1.1. Ciclo di vita. Un descrittore di un e-service è legato allo stesso e-service durante tutto il suo ciclo di vita. Gli stati di un descrittore di e-service sono:. “bozza”, l’Erogatore provvede a popolare gli attributi del descrittore di e-service;. “attivo”, l’Erogatore rende disponibile l’e-service agli Aderenti per la stipula di Accordi di Interoperabilità;. “deprecato”, l’Erogatore esprime la volontà di non accettare nuovi Fruitori ma ne assicura la disponibilità per i Fruitori che hanno già stipulato un Accordo di Interoperabilità ;. “archiviato”, le informazioni del descrittore di e-service sono conservate dall’Infrastruttura interoperabilità PDND nel caso in cui non siano stati sottoscritti Accordi di Interoperabilità relativi allo specifico descrittore di e-service. Le azioni realizzate dall’Erogatore per variare lo stato di un descrittore di e-service sono:. SALVA, da “bozza” a “bozza”: l’Erogatore popola i dati e i metadati del descrittore di e-service indicati in 4.1.2. Data model e registra quanto popolato per completarlo successivamente. PUBBLICA, da “bozza” a “pubblicato”: l’Erogatore pubblica il descrittore di e-service a condizione che i dati e i metadati obbligatori siano stati popolati;. AGGIORNA, da “pubblicato” a “pubblicato”: l’Erogatore aggiorna i dati e i metadati modificabili del descrittore di e-service;. DEPRECA, da “pubblicato” a “deprecato”: l’Erogatore rende non più disponibile l’e-service per la stipula di Accordi di Interoperabilità;. CANCELLA, da “bozza”: l’Erogatore cancella il descrittore di e-service quando ancora in bozza. L’Infrastruttura interoperabilità PDND provvede a cambiare lo stato di un descrittore di e-service da “attivo” a “deprecato” quando l’Erogatore pubblica una nuova versione dello stesso descrittore. L’Infrastruttura interoperabilità PDND effettua controlli periodici sui descrittori di e-service e provvede a cambiare lo stato dello stesso in “archiviato” di un descrittore di e-service nel caso in cui lo stato risulti “deprecato” e non sono presenti Accordi di Interoperabilità per lo specifico e-service notificando all’Erogatore il passaggio di stato. Il successivo diagramma di stato riporta gli stati di un descrittore di e-service e per essi le relative transizioni caratterizzate dall’azione realizzata dall’Erogatore e dai vincoli per la loro esecuzione, separati da “:”. Si precisa che in assenza di azioni indicate si assume che l’Infrastruttura interoperabilità PDND esegue in automatico la transizione al presentarsi della condizione abilitante la stessa. mermaid.initialize({startOnLoad:true});. graph TD avvio((start)) b[bozza] p[attivo] np[deprecato] e[archiviato] fine((end)) avvio --> b b --> |CANCELLA| fine b --> |PUBBLICA: tutti i campi obbligatori sono valorizzati | p b --> |SALVA| b p --> |AGGIORNA| p p --> |DEPRECA| np np --> |: nessun accordo di interoperabilità presente| e e --> fine. L’Infrastruttura interoperabilità PDND DEVE assicurare la possibilità agli Erogatori di utilizzare i dati e metadati di un descrittore di e-service registrati per definire e pubblicare una nuova versione dello stesso descrittore di e-service o un nuovo e-service. L’Infrastruttura interoperabilità PDND DEVE assicurare le funzionalità agli Utenti degli Aderenti, tramite interfacce web, per la gestione dei descrittori di e-service che assicurano quanto descritto in precedenza. L’Infrastruttura interoperabilità PDND DEVE assicurare le funzionalità agli Aderenti, tramite API REST, per la gestione dei descrittori di e-service che assicurano quanto descritto in precedenza. 3.1.2. Data model. Nella seguente tabella sono riportati i dati minimi del descrittori di e-service. nome. descrizione. tipo. cardinalità. obbligatorio. modificabile. id eservice. identificativo univoco dell’eservice. uri. [1..1]. SI. NO. nome. nome dell’e-service. text. [1..1]. SI. NO. descrizione. descrizione dell’e-service. text. [0..1]. NO. SI. versione. versione dell’e-service. number. [1..1]. SI. NO. versione. versione dell’e-service. number. [1..1]. SI. NO. contatti amministrativi. contatti dell’Erogatore utili ai potenziali Fruitori per avviare le interazione in merito all’e-service. CONTATTO. [1..n]. SI. SI. tecnologia. tecnologia dell’interfaccia. (‘REST’,’SOAP’). [1..1]. SI. NO. id erogatore. identificativo univoco dell’erogatore. uri. [1..1]. SI. NO. id capofila. identificativo univoco del capofila. uri. [0..1]. NO. NO. requisiti di fruizione. requisiti di fruizione per l’accesso all’e-service. ATTRIBUTO. [0..1]. SI. NO. modello accordo di interoperabilità. modello di accordo di interoperabilità utilizzato per l’e-service. uri. [0..1]. NO. NO. interfaccia. interfaccia che descrive la modalità di accesso al servizio. INTERFACCIA. [1…1]. SI. NO. interfaccia retrive. interfaccia che descrive la modalità di accesso al servizio che il Fruitore privato deve implementare per assicura all’Erogatore la possibilità di recuperari i documenti che attestano la legittimità dello specifico trattamento dei dati personali. INTERFACCIA. [0…1]. NO. NO. data registrazione. data dell’ultima modifica dei dati dell’eservice. date. [1..1]. SI. SI. data pubblicazione. data della pubblicazione dell’eservice. date. [0..1]. NO. NO, l’attributo è valorizzato una sola volta all’esecuzione della transazione di stato PUBBLICA dall’Infrastruttura Interoperabilità PDND. data revoca. data della revoca dell’eservice. date. [0..1]. NO. NO, l’attributo è valorizzato una sola volta all’esecuzione della transazione di stato REVOCA dall’Infrastruttura Interoperabilità PDND. data archiviazione. data dell’archiviazione dell’eservice. date. [0..1]. NO. NO, l’attributo è valorizzato una sola volta all’esecuzione dell’archiviazione dall’Infrastruttura Interoperabilità PDND. I metadati minimi associati ai descrittori di e-service dagli Erogatori rispettano le indicazioni fornite dal Gestore nella documentazione tecnica da esso definita per attuare quanto disposto nel presente Allegato. L’Infrastruttura interoperabilità PDND gestisce i dati di servizio necessari ad assicurare l’implementazione delle funzionalità per la gestione dei descrittori di e-service coerentemente quanto descritto in precedenza ...
-
AGID
1. Introduzione
Il presente allegato individua le funzionalità rese disponibili dall’Infrastruttura interoperabilità PDND agli Aderenti e, nel contempo, riporta i ruoli degli Utenti degli Aderenti gestiti dalla stessa infrastruttura. Il Gestore definisce la documentazione tecnica per attuare quanto disposto nel presente Allegato, considerando anche le linee guida emanate ai sensi dell’articolo 71 del CAD che hanno rilevanza per la realizzazione Infrastruttura interoperabilità PDND. La documentazione tecnica definita dal Gestore e resa disponibile agli Aderenti attraverso la pubblicazione sul portale della Infrastruttura interoperabilità PDND. ...
-
AGID
2. Riferimenti e sigle
Di seguito sono elencate le linee guida emesse dall’AgID che verranno espressamente richiamate nelle presenti Linee Guida. Tabella 2.4 Linee Guida. [LG INTEROPERABILITÀ TECNICA]. Linee Guida sull’interoperabilità tecnica delle Pubbliche Amministrazioni. [LG SICUREZZA]. Linee Guida Tecnologie e standard per assicurare la sicurezza dell’interoperabilità tramite API dei sistemi informatici ...
-
AGID
5. Data model condivisi
Riporta uno service level objectives, nella seguente tabella sono riportati i dati minimi dell’entità SLA. nome. descrizione. tipo. cardinalità. obbligatorio. modificabile. id sla. identificativo univoco di uno slo. uri. [1..1]. SI. NO. id slo. riferimento allo sli. SLI. [1..1]. SI. NO. descrizione. descrizione dello sla. text. [1..1]. SI. NO. funzione. funzione di calcolo dello sla. text. [1..1]. SI. NO ...