Piattaforma Digitale Nazionale Dati (PDND): i casi d’uso per i comuni come erogatori di interfacce API

Non ci sono documenti senza dati e non ci sono dati (attendibili) senza documenti. Questo per giustificare la presenza della Piattaforma Digitale Nazionale Dati (PDND) in un blog che, dal nome intenderebbe trattare di archivi e quindi di documenti (digitali ma anche non).

Del resto, per formare un documento informatico, recuperare dati da una o più banche dati e rielaborarli è quanto di più desiderabile e indicato. E’ anche uno dei quattro metodi per formare documenti esplicitamente menzionati nelle Linee guida sul documento informatico.

La Piattaforma Digitale Nazionale Dati in breve: a cosa serve, cosa fa e perché è importante

La Piattaforma Digitale Nazionale Dati (PDND) è quanto di più concreto e tangibile si sia fin qui proposto per dare concretezza a questo tipo di formazione di documenti e, anche, per dare concretezza al principio cosiddetto del once-only, che, sotto il nome di “autocertificazioni”, “dichiarazioni sostitutive” o “acquisizioni d’ufficio”, esiste nel fare amministrazione in Italia già da prima che si iniziasse a usare nomi inglesi per tutto…

Banalmente, per fare un esempio, la PDND rende praticabile a basso costo un processo in cui un cittadino che presenta un’istanza telematica per un beneficio economico non deve indicare nome e numero di familiari (il sistema preleva le informazioni direttamente dall’ANPR – Anagrafe Nazionale della Popolazione Residente), né il proprio indicatore ISEE (il sistema lo preleva direttamente dall’INPS).

Quando era ancora in fase di teorizzazione la PDND è stata anche chiamata DAF (Data & Analytics Framework – qui in controtendenza l’inglese è stato accantonato) o, in testi di regolamentazione più formali “Catalogo delle API” (v. linee guida sull’interoperabilità tecnica dell’AgID) o, quando le si vuole dare assoluta importanza, “piattaforma di cui all’articolo 50-ter del decreto legislativo 7 marzo 2005, n. 82 e s.m.i. recante il ‘Codice dell’amministrazione digitale'”.

Nei fatti, la PDND è ben più di un catalogo. Infatti:

• certamente cataloga ed espone ai potenziali fruitori le API messe a disposizione dagli erogatori, con tanto di descrizione dei casi d’uso e specifiche tecniche;
• in più funge da intermediario amministrativo per raggiungere il necessario accordo di fruizione (accreditamento) che lega il proprietario della banca dati e chi desidera utilizzarla, vincolando entrambi ai dovuti obblighi, limitazioni d’uso e precauzioni di sicurezza;
• funge anche da intermediario tecnologico, poiché gestisce – tramite il sistema del voucher o token JWT – l’identificazione e i livelli di autorizzazione dei fruitori, facilitando anche all’erogatore il processo di autenticazione del fruitore alla banca dati e sollevandolo da oneri di censimento meticoloso e manutenzione costante degli utenti autorizzati.

Considerazioni più approfondite sul ruolo chiave della PDND, che media fra chi detiene i dati e chi ne ha bisogno senza impossessarsi dei dati stessi, potrebbero seguire sulle pagine de larchivistadigitale.it e, nell’attesa, rimando a un paio di post su Linkedin: 1 e 2. Per adesso ci basta sapere che ci sono dei soggetti erogatori e dei soggetti fruitori. Banalizzando possiamo anche dire che essere fruitori è meno oneroso di essere erogatori. Con poco rigore scientifico e tanta approssimatività possiamo dire che l’erogatore è il server e il fruitore è il client: tutti siamo in grado di procurarci e usare su un qualsiasi dispositivo un browser web che fa da client, ma è più difficile allestire il server che distribuisce i contenuti web ai vari client che lo interrogano, anche contemporaneamente.

Il PNRR e i comuni come erogatori

In concomitanza con il varo della PDND sono comparsi anche degli avvisi PNRR per l’adesione alla PDND e la pubblicazione di API a catalogo. Uno di questi rivolto ai comuni (link). Sottolineo: si tratta di finanziamenti per diventare erogatori di dati, non fruitori.

C’è da dire che per buona parte dei comuni italiani, l’idea di poter fruire efficacemente dei dati contenuti nelle cosiddette “banche dati di interesse nazionale” è già un sogno che diventa realtà. Basti pensare che, per quanto ANPR sia alimentata dagli uffici d’anagrafe dei comuni d’Italia, agli altri uffici comunali è precluso accedervi. Non si possono nemmeno allestire servizi online usabili: se il residente nel comune confinante vuole iscrivere il figlio all’asilo nido, perché magari il suo comune, piccolo, ne è sprovvisto, se anche trova un servizio online per presentare domanda di iscrizione, deve inserire a mano tutti i dati, magari sbagliando una cifra del codice fiscale o una data di nascita (non è così banale nemmeno controllare quei dati), con ripercussioni varie anche a medio e lungo termine.

L’avviso PNRR però non finanzia l’uso della PDND come fruitori, ma chiede ai comuni di esporre loro stessi dei dati. La domanda sorge spontanea: quali dati? A chi esporli? Sono due domande, vero, ma entrambe con risposte difficili. Durante presentazione e promozione del bando il DTD ha annunciato di essere allo studio di casi d’uso da proporre ai comuni per diventare erogatori di dati.

Da qualche giorno, anche se il documento circolava, non definitivo, da qualche settimana, il DTD ha pubblicato cinque casi d’uso rivolti ai comuni per aderire alla PDND come soggetti erogatori:

• come notizia sul sito del Dipartimento;
• come brochure PDF, raggiungibile anche dalla pagina di approfondimento degli avvisi PNRR targati DTD.

Invito a leggere almeno la notizia per comprendere la portata dei cinque casi d’uso, che elenco di seguito:

1. servizi sociali/welfare;
2. scambio di documenti protocollati;
3. API geografiche;
4. albo pretorio;
5. dati della trasparenza.

Commento sui cinque casi d’uso proposti

Dico la mia sui cinque casi d’uso proposti dal Dipartimento per la trasformazione digitale (DTD) ai comuni come erogatori di dati. Anzi, meglio dire come erogatori di API, di interfacce, giacché alcuni casi d’uso chiedono di esporre interfacce per farsi comunicare dati e non per consegnarli.

1) Servizi sociali/welfare. Mi sorprende il verso del flusso. Trovo dispersivo e poco sostenibile che l’INPS interroghi i 7901 comuni per recuperare i dati da tenere nel suo sistema informativo. Attualmente è il contrario: periodicamente il Comune carica i dati sul sistema (a mano o tramite un file) tramite l’area riservata sul sito dell’INPS. In questo nuovo modello, ogni quanto l’INPS interrogherà le API dei comuni? Non alla bisogna, in tempo reale, visto che ci saranno bene quei comuni di 1.000 anime di abitanti e 5 dipendenti che con le API al più ci fanno il miele e se hanno quei dati su file di foglio di calcolo è già tanto. 

2) Scambio di documenti protocollati. Questo è un buon caso, uno di quelli in cui l’erogatore non distribuisce dati ma li riceve (in questo si scambiano documenti, quindi larchivistadigitale può dire la sua a pieno titolo, olé). Si dà attuazione al CAD, che prescrive che le pubbliche amministrazioni si scambino documenti anche in cooperazione applicativa, e, in particolare, all‘allegato 6 delle citate linee guida sul documento informatico, che prevedono che oltre alla consueta PEC i documenti si scambino anche tramite web service (o API che dir si voglia). I dubbi sulla mole di accordi di fruizione da stringere (teoricamente oltre un miliardo!), ma confidiamo in ravvedimenti operativi. Purché lo storytelling non viri verso l’apologia di protocollazioni del tutto automatiche non presidiate, altrimenti è la morte della documentazione amministrativa.

3) API geografiche. Pur non riuscendo a penetrare la potenza di sistemi cartografici, GIS e dintorni, mi sembra bello. Da specialisti per scambio di informazioni tecniche. La dimensione ideale per dati e API, anche perché esistono degli standard internazionali per metadati e interoperabilità in questo dominio, come i citati INSPIRE.

4) Albo pretorio. Questo caso d’uso, a mio avviso, non è centrato e va contro la natura dell’albo online, che ha lo scopo di integrare l’efficacia di atti amministrativi e dare pubblicità ad altri atti o fatti tramite “affissione” per un periodo limitato e per un pubblico circoscritto di interessati, in modo anche da contemperare le esigenze di pubblicità legale e di riservatezza dei dati.
Calarci sopra interfacce per interrogazioni massive va contro lo spirito dell’albo. Per le finalità proposte nella brochure (aggregazione di dati relativi a bandi o concorsi) esistono gli strumenti di trasparenza ad hoc e gli open data. Potenzialmente, visto che si parla di aggregare dati e documenti, si potrebbero creare addirittura aggregazioni di dati non desiderate: per esempio un registro parallelo dei matrimoni, a partire dalle pubblicazioni di matrimonio (una delle tante tipologie documentarie presenti nell’albo). Certo, bisognerebbe vedere che tipo di interfaccia si ha in mente, con quali limitazioni di consultazione.
Nella brochure, inoltre, l’albo viene presentato quasi esclusivamente come strumento di pubblicità e integrazione di efficacia di determine e delibere, ma in realtà ospita molto di più, inclusi documenti destinati agli irreperibili (semplificando).
L’ontologia citata, infine, l’avevo vista tempo fa e la ricordo piuttosto scarna, embrionale, con dizionari ai minimi termini. Mi auguro si sia arricchita.

5) Dati della trasparenza. Questi li trovo centratissimi. Al momento, però, a parte la tassatività delle sezioni dettata da ANAC (ma non sempre rispettata), i contenuti delle sezione dell'”Amministrazione trasparente” sono organizzati e formati da ogni ente in modo diverso (dati, tabelle, file da scaricare, PDF da scanner, testo, immagini ecc.). Questa potrebbe essere l’occasione per dettare finalmente forme standard di pubblicazione di dati e documenti, oltre che di condivisione via API. Sarebbe un grande aiuto anche per esporre i dati sui siti web in modo ordinato e uniforme, magari automatizzando anche il loro caricamento da parte di eventuali software gestionali. Anche per la gioia del solito malcapitato che.. “ti piacerebbe occuparti della trasparenza?”…

Conclusioni

Non sono io il primo a dirlo, ma senza le specifiche di una e una sola interfaccia standard per ciascuno dei casi d’uso che consenta a tutti di esporre dati omogenei allo stesso modo, dare il via libera ai comuni nel diventare erogatori rischia di dare origine a una Babele ingestibile. Siamo fiduciosi che la strada intrapresa sia questa e ci attendiamo sviluppi pratico-operativi a breve.

Proseguo “andreottianamente”: tempo fa in risposta a un post su Linkedin mi meravigliavo del numero esorbitante di API da pubblicare a catalogo posto come milestone di progetto, per valutare la riuscita dell’operazione PDND. Ora, fin tanto che ANPR distingue l’API per verificare la maternità da quella per verificare la paternità ci può stare, ha senso, perché rende granulare il sistema di autorizzazioni. Ma se si cambia il verso dei flussi…

Chiudo propositivo: parallelamente ai casi d’uso proposti, lavoriamo anche sul mondo delle autorizzazioni/licenze/titoli vari rilasciate dai comuni, nei settori commercio (su sede fissa ma soprattutto ambulante) ed edilizia privata, ma in modo semplice, slegato da trattazioni complessive e onnicomprensive delle tematiche SUE e SUAP, dove si finisce per fare confusione fra dati, pratiche e registri, fra punti di accesso e uffici responsabili, fra concetti astratti di sportello e portali software…

Foto di Gerd Altmann da Pixabay