Linee Guida sull’infrastruttura tecnologica della Piattaforma Digitale Nazionale Dati per l’interoperabilità dei sistemi informativi e delle basi di dati, v2

Consultazioni pubbliche Aggiornamento LLGG PDND interoperabilità
1

Nell’ambito del modello di interoperabilità delle pubbliche amministrazioni (di seguito MoDI), le presenti Linee Guida (di seguito Linee Guida) concernono la Piattaforma Digitale Nazionale Dati di cui all’articolo 50-ter del decreto legislativo 7 marzo 2005, n. 82 e s.m.i. recante il “Codice dell’amministrazione digitale”, avendo ad oggetto l’infrastruttura tecnologica per l’interoperabilità dei sistemi informativi e delle basi di dati (di seguito Infrastruttura interoperabilità PDND) di cui al comma 2 del medesimo articolo.
[…]

Continua a leggere le Linee Guida sul sito AgID

2

Salve,
nel paragrafo 2.2 a pag. 3 sono elencati 7 allegati.

L’allegato "Allegato 7: Regole di popolamento " non è pubblicato, come mai ?

Saluti
Daniele Crespi

2 Mi Piace
3

Buongiorno,
in merito alla sua richiesta le segnalo che l’indicato allegato 7 sarà predisposto successivamente alla pubblicazione dell’aggiornamento alle LLGG ai sensi del capitolo 5 Processo di aggiornamento degli Allegati.

Grazie

1 Mi Piace
4

Par. 2.3, pag. 4: si suggerisce di valutare l’inserimento della “Direttiva Butti” fra i rifeirmenti normativi (https://www.governo.it/sites/governo.it/files/Decreto20231205_Direttiva_PDND.pdf) - v. anche paragrafo 11, lett. j. del terzo elenco - in parte pertinente e collegato.

Par. 4.25 e ss.: la sudidivisione in Produttore e Consumatore è proprio necessaria? Non si riesce a regolare il caso da gestire (il Segnale di variazione) facendo riferimento a Erogatore e Fruitore?

Par. 6: "nel caso in cui l’aderente sia un soggetto giuridico” sostituire “soggetto giuridico” con “persona giuridica”. Si consiglia una ricerca globale per “soggetto giuridico” per evitare altre occorrenze (anche una persona fisica è un soggetto giuridico).

Par. 6, ultimi tre capoversi: si suggerisce di mettere 3 tre DEVE (adesso solo 1). Soprattutto per l’ambiente di test/collaudo, che fra l’altro già esiste funzionante.

1 Mi Piace
5

Paragarafo 8 - Catalogo API

4° capoverso, “La registrazione degli e-service è realizzata degli Erogatori che DEVONO:…” Si suggerisce, nel secondo punto, di dare maggiore enfasi al fatto che un requisito di fruizione (tolti gli open data) deve essere presente.

7° capoverso: “Le informazioni presenti nel Catalogo API per ogni e-service sono almeno le seguenti:…”. Si suggerisce di inserire fra la documentazione obbligatoria un documento testuale che spieghi:

  • significato e valore dei dati scambiati (con riferimento ai tag dei file JSON/XML scambiati);
  • grado di aggiornamento dei dati (in caso di erogazione ordinaria);
  • illustrazione di casi d’uso.

Esempio di cosa potrebbe succedere (scelto a caso dalla prima pagina del catalogo): PDND Interoperabilità | PagoPA

Pag. 17: “Gli Erogatori nell’implementazione dei propri e-service al di fuori dell’Infrastruttura interoperabilità PDND DEVONO:”.

  • Che l’e-service sia implementanto fuori dalla PDND dovrebbe essere assodato, qui si vuole indicare qualcos’altro?
  • andrebbe chiarito cosa si intende per “documento informatico che provi la liceità dello specifico trattamento”. A rigore, un documento con un riferimento chiaro potrebbe non essere ancora perfezionato. Va bene anche un riferimento (univoco) a una pratica, un procedimento, un uuid di un servizio online ecc.?
  • il punto b. non è chiaro: per l’erogazione ordinaria OK, ti chiedo un ISEE e ti do un riferimento al numero di pratica che sto gestendo. Ma se ti carico dei dati di Welfare, dall’altra parte (INPS) che “documento informatico” specifico può esistere?

Ancora pag. 17: “Gli Erogatori DOVREBBERO: • dare seguito alla metadatazione degli e-service…”. Perché non DEVONO? Ammesso che esistano ontologie, vocabolari e modelli dati pubblicati, vanno usati quelli.

1 Mi Piace
6

Paragrafo 9, capoverso 4: “La richiesta di fruizione di un e-service è conclusa con esito positivo se risultano soddisfatte le seguenti condizioni: a… b… c” . Si suggerisce di valutare di dare maggiore enfasi al fatto che nei casi a e b la conclusione positiva p automatica e immediata (nel caso c, automatica e immediata dopo la comunicazione della verifica positiva da parte dell’erogatore).

Paragrafo 10: “L’analisi del rischio sulla protezione dei dati personali DEVE prevedere almeno i seguenti aspetti:…”. ATTENZIONE all’ultimo punto sulla conservazione dei dati personali, perché non sempre il tempo è quantificabile a priori e, inoltre, non è chiaro a quali dati ci si riferisca.
Spiego: un conto è impegnarsi a non memorizzare oltre misura la response dell’e-service (c’e’ chi lo farebbe “a riprova” dell’acquisizione del dato, ma l’idea di fondo sarebbe che si puo’ andare a verificarlo di nuovo alla fonte se serve) o infarcire i log di dati eccedenti, un conto è pretendere che, facendo un esempio, l’indirizzo di residenza che ho recuperato da ANPR lo cancelli - dopo un po’ di tempo - da una lettera che ho scritto e inviato…
Inviterei quindi a chiarire meglio.

Paragrafo 11, responsabiltà dell’Erogatore:

  • “l’Erogatore deve garantire, essendo nella sua esclusiva responsabilità… b. ’accesso all’e-service e la relativa fruizione da parte del Fruitore che possieda gli Attributi richiesti e, in caso di Erogazione Ordinaria, che abbia compilato l’analisi del rischio sulla protezione dei dati personali”

sembra che si richieda all’erogatore una nuova verifica degli attributi e della presenza dell’analisi del rischio, cosa che invece dovrebbe essere gestita in toto dalla PDND /attibuti verificati a parte). Se all’erogatore arriva il fuitore con il voucher (e altre amenità previste dai pattern di sicurezza) dovrebbe bastare. Quindi si suggerisce di riformulare nel senso di “garantire l’accesso al fuitore correttamente identificato/autenticato tramite PDND”.

Paragrafo 17, punto 1 del primo elenco numerato, manca un verbo:

  1. il Fruitore effettua richiesta all’Erogatore e, allo stesso tempo, –COMUNICA?– il riferimento al servizio di callback invocato, in modalità asincrona, dall’Erogatore quando la risorsa predisposta dallo stesso in risposta alla richiesta del Fruitore è disponibile.
    Paragrafo 18.2.2 , sui tempi di conservazione del Gestore:
  • “con riferimento all’Accordo di Adesione: 10 anni decorrenti dalla cessazione del rapporto contrattuale;” per “rapporto contrattuale” si intende l’accordo di adesione? altrimenti a quale contratto ci si riferisce?

SUGGERIMENTO IN TEMA DI MINIMIZZAZIONE: si può caldeggiare l’implementazione da parte delle banche dati di interesse nazionale di interrogazioni di mera verifica? Spiego con un esempio: non chiedo il valore ISEE ma solo se questo è inferiore o superiore a una certa soglia e ottengo una risposta VERO/FALSO.

TRUST MOLTI-A-MOLTI: si invita a disciplinare in qualche modo l’uso della PDND per la creazione di trust “molti-a-molti”, per esempio l’interoperabilità di protocollo, in cui 30mila amministrazioni dovrebbero strungere accordi di fruizione con le altre 29.999. Ingestibile. Forse il ruolo di Incaricato e Capofila risponde in parte a questa esigenza, ma resta da capire cosa ne e’ del catalogo API e di come richiedere/accettare le fruzioni.

1 Mi Piace
7

Pag. 17 il ripetuto riferimento a “documenti informatici che possano provare la liceità dello specifico trattamento dei dati personali” è poco comprensibile e di dubbia utilità a discernere la legittimità della richiesta di fruizione (condivido l’osservazione di @frantheman ). Se si riferisce alle fonti (basi giuridiche) del trattamento non si comprende perché la verifica non sia fatta invece preventivamente e in via generalizzata una sola volta a monte in sede di adesione all’e-service. Se invece si riferisce in modo puntuale a quel preciso procedimento amministrativo relativo a quella precisa persona fisica o giuridica per la quale si necessita dell’acquisizione del dato in sede istruttoria procedimentale si rammenta che, laddove la base giuridica ai sensi del GDPR lo consenta o preveda, la P.A. nel trattamento del dato prescinde totalmente dal consenso del soggetto destinatario (si pensi a procedimenti d’ufficio che sono potenzialmente destinati ad incidere nella sfera giuridica del soggetto, a volte con comunicazione di avvio, ma non necessariamente: p.es. in ambito tributario): il rischio di appesantire oltremodo l’iter procedimentale è purtroppo molto concreto, tanto più che si tratterebbe di una fase intermedia dell’istruttoria in cui l’eventuale “documento” acquisitivo del dato richiesto all’e-service sarebbe uno dei tanti endoprocedimentali e senza rilevanza esterna, che in quanto tale può non essere identificato e tracciabile (almeno finché non viene adottato il provvedimento finale … ammesso che il procedimento non venga abortito in istruttoria per infondatezza dei presupposti). Non voglio immaginare l’assurdità di dover fornire migliaia di “via libera” specifici per migliaia di trattamenti di natura massiva di dati di comune necessità e in assenza di una pur minima qualificazione “sensibile” o altrimenti riservata: si negherebbe alla radice l’essenza e l’efficienza dell’interoperabilità…

8

Punto 4.14 pag. 8: non si comprende la ragione di esistenza della c.d. “erogazione inversa”, in contrapposizione all’erogazione ordinaria, posto che, laddove il Fruitore metta a disposizione dell’Erogatore propri dati/informazioni, dovrebbe a sua volta considerarsi e qualificarsi Erogatore e il ricevente come Fruitore. A meno che tali dati non servano solo a corroborare la legittimità della richiesta in erogazione ordinaria fatta all’Erogatore o a delimitare l’ambito dei dati richiesti all’e-service, si ritiene che ciò introduca una complessità non necessaria rispetto alla normalità del flusso bilaterale richiesta-ricezione.

1 Mi Piace
9

Dal paragrafo 1:

Ai sensi dell’art. 50-ter, comma 2-bis, del CAD, il Presidente del Consiglio dei ministri o il Ministro delegato per l’innovazione tecnologica e la transizione digitale, ultimati i test e le prove tecniche di corretto funzionamento della Infrastruttura interoperabilità PDND, fissa il termine entro il quale i soggetti di cui all’articolo 2, comma 2, del CAD saranno tenuti ad accreditarsi alla stessa, a sviluppare le interfacce e a rendere disponibili le proprie basi dati.

Lo ha fatto con il Decreto 22 settembre 2022 recante “Obblighi e termini di accreditamento alla Piattaforma Digitale Nazionale Dati”, citato fra i riferimenti normativi. Si suggerisce di darne atto e sintetizzarne il contenuto, cioe’ che è già obbligatorio da settembre 2023 (p.a.) o marzo 2024 (gestori di pubblici servizi) o lo sarà da settembre 2024 (società a controllo pubblico). In fondo sono delle linee guida dalle quali chi legge si attende un po’ di pragmatica praticità…
Poi, a seconda del taglio che si vuole dare alle linee guida, si puo’ anche ricordare che per l’art. 18-bis, comma 5 del CAD, c’e’ pure la sazione amministrativa da 10.000 a 100.000 mila euro :slight_smile:

Inoltre:

I soggetti di cui all’articolo 2, comma 2, del CAD DEVONO aderire e utilizzare l’Infrastruttura interoperabilità PDND per tutte le API da essi realizzate e utilizzate, nei termini e con le modalità previsti dall’articolo 50-ter del CAD.

Ora, la mente va da sé ad alcuni casi:

  • ANPR per l’anagrafe comunale;
  • pagoPA;
  • app IO;
  • INI-PEC;
  • …

in cui le API esposte da “soggetti di cui all’articolo 2, comma 2” non passano da PDND.
Suggerisco di prevenire tale obiezione inserendo qualche argomento, altrimenti ci si disaffeziona subito allo strumento. Per esempio il Decreto [DTD 22/09/2022] fra le righe del comma 4 dell’articolo 2 sembra consentire di mettere a disposizione API senza passare da PDND:

Gli obblighi di cui ai commi precedenti vigono anche per i soggetti di cui all’art. 2, comma 2, del CAD che, ai sensi dell’art. 50-ter, comma 7, del CAD, decidono di continuare ad utilizzare anche i sistemi di interoperabilita’ gia’ previsti dalla legislazione vigente.

Segnalo, anche a uso di chi partecipa alla consultazione, che le API esposte non sono solo funzionali all’accesso a dati presenti nelle banche dati, ma, come da paragrafo 3.1.1:

I soggetti erogatori per il tramite della Infrastruttura interoperabilità PDND, favoriscono:
• la conoscenza e l’utilizzo del patrimonio informativo detenuto per finalità istituzionali nelle banche dati a loro riferibili;
• la condivisione dei dati/informazioni con i soggetti che hanno diritto di accedervi in attuazione dell’articolo 50 del CAD per la semplificazione degli adempimenti dei cittadini e delle imprese;
• l’integrazione di processi funzionali alla semplificazione degli adempimenti dei cittadini e delle imprese.

RICHIESTA: si suggerisce inoltre di chiarire se il passaggio da PDND è possibile/indicato/suggerito anche per esigenze di interoperabilità interna. Al momento non c’è unanimità di interpretazione al riguardo. Da un lato viene da dire “perche’ no, stai esponendo dati o servizi al mondo, perche’ non anche a te stesso?”, dall’altro suona un po’ strano stringere un accordo di fruizione con se stessi e, nel caso di API che hanno uso esclusivamente interno, ha senso affollare il catalogo di e-service che servono solo a chi li pubblica?

1 Mi Piace
10

Buongiorno @vintraAgID la consultazione si fa soltanto a partire dal PDF o è possibile anche l’eccezionale modalità basata su docs italia?
Se c’è anche la seconda, qual è URL?

Grazie

11

Buongiorno @aborruso,
per l’aggiornamento delle presenti LLGG è stata prevista solo la modalità PDF.

Grazie

1 Mi Piace
12

Nell’ottica di raccogliere in un unico documento tutte le indicazioni relative al tema PDND mi pare opportuno far confluire nelle LLGG anche la Guida alla nomenclatura degli e-service PDND

2 Mi Piace
13

Capitolo 16, sesto paragrafo, la frase:

A seguito della modifica del seme, tutti i nuovi segnali di variazione depositati presso l’Infrastruttura interoperabilità PDND riportano identificatori pseudonimizzati nuovi, pertanto gli Aderenti consumatori rafforzando la loro incapacità di associare tali segnali a soggetti per cui non hanno procedimenti in essere.

Risulta incomprensibile

1 Mi Piace
14

Capitolo 17, primo paragrafo, punto 1, la frase

il Fruitore effettua richiesta all’Erogatore e, allo stesso tempo, il riferimento al servizio di callback invocato, in modalità asincrona, dall’Erogatore quando la risorsa predisposta dallo stesso in risposta alla richiesta del Fruitore è disponibile;

dovrebbe essere riformulata nel modo seguente:

il Fruitore effettua una richiesta all’Erogatore includendo il riferimento al servizio di callback che dovrà essere invocato dall’Erogatore quando la risorsa predisposta dallo stesso in risposta alla richiesta del Fruitore sarà disponibile;

15

Peccato che sia così, perché l’altra modalità è molto ma molto più efficace. QUesta per me è una barriera.

Grazie

1 Mi Piace
16

Chiedo cortesemente di aggiungere al capitolo 9 “Richiesta di fruizione di e-service” il seguente punto 4. “L’Erogatore è tenuto a completare il processo di approvazione, con esito positivo o negatio, di una richiesta di fruizione per un e-service, entro 20 giorni dalla data di inserimento della stessa da parte dell’Aderente sull’Infrastruttura interoperabilità PDND”
Questo termine garantisce tempi certi per la gestione delle richieste, fornendo chiarezza e rapidità nel processo di fruizione dei servizi. Sono a conoscenza di richieste di fruizione che restano per mesi nello stato di “in attesa di approvazione”. Se si vuole che effetivamente PDND funzioni DEVONO essere definiti dei tempi per la gestione delle richieste di fruizione e al Gestore dell’Infrastruttura interoperabilità PDND deve necessariamente essere attribuito il compito di verificare il rispetto di questi tempi, per cui chiedo sia aggiunto al capitolo 11 “Responsabilità” il seguente testo tra i compiti del Gestore della Infrastruttura interoperabilità PDND come punto d: adottare misure tecniche e organizzative volte a monitorare il rispetto dei tempi di evasione delle richieste di fruizione tra gli Aderenti Fruitore e Erogatore comprese attività di sollecito nei confronti del responsabile dell’Erogatore ai sensi dell’Art 18-bis del CAD.

3 Mi Piace
17

Cap 3.1.2, primo paragrafo

hanno l’esigenza di fruire e riutilizzare i dati dei soggetti di cui al comma 2 dell’articolo 2 del CAD, alle condizione fissate dall’ordinamento

Diventa

hanno l’esigenza di fruire e riutilizzare i dati dei soggetti di cui al comma 2 dell’articolo 2 del CAD, alle condizioni fissate dall’ordinamento

18

Faccio parte di una società pubblica in house, svolgente attività di riscossione per conto degli Enti pubblici soci del nostro territorio, classificata in IPA come “SCEC” (Società in conto economico consolidato). Rilevo la nostra attuale difficoltà a poter beneficiare dei servizi offerti dall’interoperabilità, non rientrando espressamente in una delle categorie/lettere contemplate dall’articolo 2, comma 2 del CAD, a seguito della classificazione in IPA proprio come SCEC. Infatti le SCEC non sono previste come categoria a se stante dal CAD, pur avendo la necessità di beneficiare di tutti i servizi di interoperabilità per l’attività istituzionale svolta. Mentre in IPA è contemplata una classificazione di fatto in 5 categorie (PA, SCEC, Enti nazionali di previdenza e assistenza sociale in conto economico consolidato, GPS e residuali stazioni appaltanti), nel CAD sono invece previste solo 3 categorie, quindi le pubbliche amministrazioni (art. 2 comma 2 lett a), i gestori di pubblici servizi (art. 2 comma 2 lett b) e le società a controllo pubblico (art. 2 comma 2 lett c) e nulla si dice in merito alla riconducibilità ad una di esse delle SCEC.
Infatti per l’adesione ad interoperabilità viene fatto riferimento alla categoria di classificazione in IPA, ma il CAD determina la fruizione dei servizi di interoperabilità unicamente per soggetti censiti in IPA come:

  • PA (lett. a) art. 2 comma 2 CAD), Enti rientranti nella L. 165/2001, e non anche nella L. 196/2009 (in cui ricadono invece le SCEC);
  • GPS (lett. b) art. 2 comma 2 CAD),
  • stazione appaltante (lett. c) art. 2 comma 2 CAD).
    Posto che non è possibile per una società SCEC come la nostra modificare l’iscrizione in IPA in GPS o semplice stazione appaltante, in quanto obbligati all’iscrizione come SCEC per poter adempiere normativamente agli obblighi di fatturazione con codice SDI a 6 cifre, risultiamo paradossalmente esclusi dall’accesso a dati e servizi offerti da PDND, che siamo tenuti obbligatoriamente, per legge, ad utilizzare per svolgere la nostra attività istituzionale.
    Il CAD stabilisce, ad esempio, all’articolo 6 comma 1 quater che: soggetti di cui all’articolo 2, comma 2, notificano direttamente presso i domicili digitali di cui all’articolo 3-bis i propri atti, compresi i verbali relativi alle sanzioni amministrative, gli atti impositivi di accertamento e di riscossione e le ingiunzioni di cui all’articolo 2 del regio decreto 14 aprile 1910, n. 639, fatte salve le specifiche disposizioni in ambito tributario.
    Quindi le pubbliche amministrazioni (art. 2 comma 2 lett a), i gestori di pubblici servizi (art. 2 comma 2 lett b) e le società a controllo pubblico (art. 2 comma 2 lett c) notificano gli atti ai domicili digitali risultanti in INI PEC, IPA e INAD. Posto che tutti i soggetti indicati dall’art. 2 comma 2 del CAD hanno l’obbligo di notificare i propri atti ai domicili digitali risultanti da tali registri, è evidente che ad una società come la nostra debba essere garantito il pieno accesso ad interoperabilità, accesso attualmente garantito unicamente ai soggetti espressamente rientranti alle lettere a) e b) dell’art. 2 comma 2 del CAD, nelle quali, come detto sopra la nostra società SCEC attualmente non rientra. Pare inoltre incongruente che l’accesso in modalità massiva al registro INAD (art. 6 quater del CAD), dalla linee guida INAD, al punto 2.5. Estrazione dati (estrazioni multiple di domicili digitali relativi ad elenchi di codici fiscali forniti dai medesimi soggetti richiedenti mediante i meccanismi di cooperazione applicativa) sia reso disponibile solo ai soggetti di cui alle lettere a) e b), art. 2, comma 2 del CAD e non anche ai soggetti risultanti alla lettera c) della citata disposizione, quando lo stesso CAD all’art. 6 comma 1 quater prevede anche per essi l’obbligo di utilizzo di tali dati per le proprie notifiche. Anche ANPR, ad esempio, consente la fruizione del dato solo agli Enti delle lettere a) e b) art. 2 comma 2 del CAD, e quindi anche in questo caso si manifesta la medesima esclusione per le SCEC.
    Tale problematica si ravvisa in modo palese proprio in fase di adesione a PDND/interoperabilità, in cui si richiede di dichiarare, sotto la propria responsabilità, in quale categoria dell’art. 2 comma 2 del CAD rientri il soggetto aderente, non contemplando però il CAD la specifica categoria SCEC, che ha necessità di svolgimento di servizio e obblighi normativi assimilabili a quelli delle PA in senso stretto.
    Chiedo un cortese chiarimento e una soluzione a questa situazione. Grazie
19

Nelle definizioni, al paragrafo 4.16. Catalogo API, può essere utile per chiarezza specificare “anche nominato catalogo degli e-service”, in linea con il nome utilizzato in piattaforma e sul catalogo pubblico

20

Capitolo 8. Catalogo API
Quando si parla di:

riferimento ai documenti informatici che possano provare la liceità dello specifico trattamento dei dati personali effettuato

a cosa ci si riferisce? Al protocollo? Nel caso di richieste online, è possibile fruire di e-service per la verifica dei dati inseriti dal cittadino prima che la pratica venga protocollata? E’ possibile utilizzare un id interno della pratica (es. id del gestionale)?

Nell’Allegato 2 al Capitolo 3.1 Gestione dei descrittori degli e-service si fa riferimento

ad esempio, al consenso dell’interessato nei casi di applicazione dell’articolo 6, paragrafo 1, lettera a del GDPR

tuttavia le Pubbliche Amministrazioni non sono tenute a richiedere il consenso.