1. Quadro di riferimento e obiettivi del documento

La circolare n. 1/2019 avente ad oggetto “Attuazione delle norme sull’accesso civico generalizzato (c.d. FOIA)”, integra la precedente circolare FOIA n. 2/2017 del Dipartimento della funzione pubblica (di seguito DFP) e specifica ulteriormente le modalità di riutilizzo di sistemi di protocollo informatico e gestione documentale per la realizzazione del registro degli accessi presentati alle amministrazioni. Tale scelta deriva dall’opportunità di evitare la realizzazione di nuove infrastrutture e di poter disporre di una soluzione in tempi brevi. Ciascuna Amministrazione può comunque realizzare una autonoma versione del Registro degli accessi, anche difforme con quanto indicato nella circolare FOIA n.2/2017, purché tale soluzione garantisca agli utenti e ai soggetti che monitorano l’applicazione del FOIA la fruibilità dei dati e dei metadati previsti nelle linee guida della Autorità Nazionale Anticorruzione (di seguito ANAC) e nella circolare FOIA n.2/2017 e definiti in dettaglio nel presente documento. L’esposizione di dati e metadati serve per monitorare e per orientare la pratica amministrativa:

• Monitorare la trattazione delle richieste d’accesso, fornendo tutte le informazioni che permettano di analizzare (anche con metodologie di analytics o Business Intelligence – BI) le richieste di accesso ed i rispettivi esiti. Pertanto, sono necessari dati che permettano di categorizzare il più possibile le tipologie di richieste e di esiti.
• Orientare la pratica amministrativa, con la rilevazione di dati e informazioni, incluse le motivazioni associate agli esiti delle richieste, che consentano di rilevare eventuali criticità e di orientare gli altri uffici e le altre amministrazioni nel trattamento di analoghe richieste.

Al fine di supportare le amministrazioni nella realizzazione del Registro degli accessi, il presente documento presenta una serie di “istruzioni per l’uso”, condivise anche con i fornitori dei sistemi di protocollo informatico e gestione documentale, per la realizzazione di quanto accennato, e la definizione di un insieme di indicazioni operative per la realizzazione in formato XML dei dati minimi da gestire attraverso il Registro.

2. Il framework FOIA: l’integrazione tra sistema di protocollo informatico e registro degli accessi

La realizzazione del Registro tocca due aspetti: il Registro degli accessi da pubblicare nella sezione Amministrazione Trasparente e il flusso procedurale per la gestione del procedimento FOIA.

Nella Figura 1 è rappresentato graficamente il framework FOIA dove il suffisso INT indica i metadati necessari al procedimento mentre quello BULK indica i metadati relativi al Registro. Una generica amministrazione (ne sono mostrate tre per evidenziare la replicabilità del modello) configura il proprio Sistema di Protocollo Informatico (di seguito e nella figura, indicato con l’acronimo “SPI”) per definire i dati minimi del Registro degli accessi. Tale attività può essere svolta direttamente dall’amministratore del protocollo dell’amministrazione (se il sistema in uso lo consente) oppure dal fornitore. L’amministrazione espone un documento XML well formed e validato rispetto a XSD-FOIA-RA-BULK (ma anche un formato tabellare coerente con esso) conforme alle circolari FOIA ed alle presenti specifiche. La produzione di tale documento XML e/o formato tabellare è rimessa all’amministrazione. È tuttavia importante evidenziare che se il Registro degli accessi è realizzato appoggiandosi allo SPI, l’estrazione di metadati deve avvenire secondo le modalità specifiche dell’SPI impiegato in ciascuna amministrazione.

2.1. Gli standard di riferimento XSD-FOIA-RA

Di seguito si descrivono le tre componenti principali del c.d. framework FOIA:

• uno standard di riferimento, indicato come XSD-FOIA-RA-EXT (XML Schema Definition del Registro degli Accessi FOIA per l’Esterno), che definisce i dati minimi che ogni Registro degli accessi deve contenere e rendere disponibili a fronte di una singola richiesta di accesso. In attuazione delle linee guida ANAC e delle circolari FOIA, la pubblicazione periodica del Registro degli accessi comporta la realizzazione di un documento XML coerente con tale XSD. Tale documento XML permette sia l’accesso alle informazioni a livello applicativo, sia la produzione, attraverso opportuni fogli di stile, di un documento leggibile (ad es., tabella HTML, foglio di calcolo, ecc.) da pubblicare nella sezione Amministrazione Trasparente. Le amministrazioni possono adottare differenti approcci: possono pubblicare nella sezione Amministrazione Trasparente il documento XML e un documento di più agevole lettura ricavabile dal primo, o, ancora, offrire una API (coerentemente al Modello di Interoperabilità di AgID come interfaccia SOAP o REST) che restituisca tale documento XML in modalità applicativa (fermo restando la disponibilità di un documento leggibile nella sezione Amministrazione Trasparente come previsto dalle linee guida ANAC). Anche la periodicità della produzione di tali documenti è suscettibile di adattamenti alle specifiche esigenze di ciascuna amministrazione, che può, ad esempio, optare per un unico documento che contenga tutte le richieste, ovvero per più documenti che coprono archi temporali di dimensione fissa o variabile.
• Lo schema XSD-FOIA-RA-EXT permette di inviare informazioni relative ad una singola richiesta di accesso. Gli aggiornamenti relativi alle richieste di accesso vengono solitamente inviati in gruppo. A tal fine, viene definito lo schema XSD-FOIA-RA-EXT-BULK, che rappresenta una estensione di XSD-FOIA-RA-EXT.
• Uno schema, indicato come XSD-FOIA-RA-INT (XML Schema Definition del Registro degli Accesso FOIA per l’Interno), che indica quali metadati è possibile inserire nel sistema di protocollo informatico e gestione documentale utilizzato dall’amministrazione, per consentire la piena integrazione tra lo SPI e il Registro degli accessi e l’estrazione automatica del secondo dal primo. A tal fine, non sono in linea di principio necessari sviluppi ad hoc onerosi o tecnicamente complessi. Sono sufficienti interventi di configurazione e manutenzione evolutiva dei sistemi già in essere, così da preservare gli investimenti fatti dalle amministrazioni in materia di sistemi di protocollo informatico e gestione documentale, e da valorizzare tali sistemi come strumento preferenziale per realizzare il Registro degli accessi. Ogni amministrazione che intenda perseguire questa strada per realizzare il Registro degli accessi può operare di concerto con il proprio fornitore al fine di configurare e far evolvere il proprio sistema di protocollo nel senso di seguito indicato. Si ribadisce che lo schema XSD-FOIA-RA-INT è riportato ai fini di indicare i campi necessari per il supporto al fascicolo FOIA nei sistemi pre-eesistenti. L’implementazione interna può anche non essere basata su questo schema, a patto che si rispettino lo schema XSD-FOIA-RA-EXT e quello XSD-FOIA-RA-BULK.

Gli schemi XSD presentati contengono nelle definizioni dei namespace il numero di versione. In questa maniera sarà possibile fornire in futuro retro-compatibilità con nuove versioni.

Si precisa altresì che i documenti XML prodotti secondo gli schemi XSD-FOIA-RA-EXT-BULK/EXT, essendo destinati alla pubblicazione e/o trasmissione, devono contenere dati relativi alle richieste in forma anonimizzata, ovvero privi di dati personali del mittente, dei controinteressati o di terzi, che incidentalmente possono anche essere contenuti nell’oggetto della richiesta di accesso[1]. È cura del processo di estrazione operare tale anonimizzazione.

2.2. I passi per l’adozione del framework FOIA

I diversi passi del processo di adozione del framework FOIA, gli attori e la tempistica sono:

• L’emanazione da parte del DFP delle presenti specifiche che definiscono appunto il formato XML per eventuali realizzazioni basate su sistemi di protocollo e gestione documentale, ed il formato di esportazione. I destinatari di queste istruzioni operative del DFP sono, oltre ai funzionari responsabili del sistema di protocollo informatico di ciascuna amministrazione, anche i fornitori dei sistemi di protocollo e gestione documentale.
• Il secondo passo consiste nella configurazione dei sistemi di protocollo e gestione documentale da parte dei rispettivi fornitori secondo le presenti indicazioni operative, in modo da supportare nativamente il framework FOIA.
• In una seconda fase, anche al fine di rendere meno onerosa l’attività di monitoraggio da parte delle amministrazioni, si procederà alla realizzazione di un sistema di monitoraggio “federato”, che, utilizzando eventuali API offerte dai registri degli accessi, o semplicemente recuperando i registri degli accessi in formato XML dalle sezioni Amministrazione Trasparente delle singole amministrazioni, consenta di monitorare lo stato di avanzamento del FOIA con funzionalità di analytics e BI. Le pubbliche amministrazioni ed i rispettivi fornitori, dovranno dotarsi di adeguati strumenti per offrire tali registri degli accessi sempre secondo lo standard XSD-FOIA-RA e sue possibili evoluzioni.

3. Indicazioni operative

Al fine di realizzare il Registro degli accessi riutilizzando funzioni e servizi dei sistemi di protocollo informatico, di seguito sono indicate le informazioni (metadati) che le pubbliche amministrazioni devono rilevare e inserire nel Registro in relazione a ciascuna richiesta di accesso, in formato XML, e il modo in cui tali informazioni possono essere gestite “nativamente” dai sistemi di protocollo informatico già in uso presso le amministrazioni.

La soluzione proposta potrebbe non applicarsi a tutti i sistemi di protocollo informatico. I fornitori, al fine di dichiarare il loro prodotto compatibile con la specifica FOIA, dovranno essere in grado di produrre una metadatazione come descritta nella Sezione 3.2 (Metadati minimi – XSD-FOIA-RA-INT) ed esportata utilizzando lo schema proposto nella Sezione 3.3 (Schema XSD esportazione – XSD-FOIA-RA-EXT).

In termini generali, la presentazione di una nuova richiesta di accesso determina la creazione, nel sistema di protocollo e gestione documentale di una pubblica amministrazione, di un apposito fascicolo che contiene la richiesta di accesso, la corrispondenza con i soggetti interessati (es. chiarimenti forniti dal richiedente, comunicazione con controinteressati, ecc.), l’esito e gli eventuali documenti e dati forniti. Una volta aperto il fascicolo relativo alla richiesta di accesso, questo può essere collegato ad altri fascicoli o sotto-fascicoli correlati. In particolare, un fascicolo o sottofascicolo correlato può essere aperto nelle seguenti ipotesi:

• per la notifica a ognuno dei controinteressati, se esistenti, e le eventuali risposte;
• per ciascun insieme o tipologie di dati o documenti richiesti, posto che una stessa istanza può contenere la richiesta di accedere a diversi insiemi o tipologie di dati o documenti qualificabili come oggetti distinti;
• per l’eventuale riesame della richiesta di accesso da parte del Responsabile della prevenzione della corruzione e della trasparenza;
• per l’eventuale ricorso al giudice amministrativo (TAR e Consiglio di Stato).

Ogni sistema di protocollo gestisce queste relazioni in modo differente. In alcune versioni, esiste la possibilità di realizzare un multi-fascicolo, come appena indicato. In altre versioni, è possibile stabilire una correlazione tra fascicoli che appartengono allo stesso procedimento principale, relativo alla richiesta di accesso generalizzato. Di seguito, si propone un modello generale, adattabile a qualsiasi versione del registro di protocollo. Tale modello presuppone:

• la presentazione di una richiesta di accesso generalizzato o FOIA;
• la possibilità di registrare l’esito relativo a uno o più gruppi di dati o documenti (di seguito, “oggetti”) ai quali si richiede di accedere con un’unica istanza. Tale possibilità appare rilevante, perché a fronte di una richiesta con una pluralità di oggetti, possono aversi diversi uffici competenti e diversi esiti.

Per ogni richiesta, le informazioni relative, opportunamente  anonimizzate[2] e trattate in modo da non ledere altri interessi tutelati dalla legge, sono trasferite al Registro degli accessi in vista della pubblicazione dello stesso nella sezione Amministrazione Trasparente del sito istituzionale.

Come chiarito nella Sezione 3.2 (Metadati minimi – XSD-FOIA-RA-INT), la presenza di diversi oggetti legati a una singola richiesta di accesso non esclude comunque che la stessa sia rappresentata in forma unica (secondo quanto descritto dallo schema XSD) senza fare riferimento alla eventuale suddivisione interna in distinti fascicoli o sotto-fascicoli. Ai fini della fruibilità del Registro, è indispensabile fare riferimento al fascicolo relativo alla richiesta di accesso, comprensivo degli eventuali fascicoli “satellite” che permettano una più accurata analisi del trattamento di richieste plurime.

Per questo motivo, nello schema XSD di seguito presentato, parte dei metadati sono memorizzati e gestiti in riferimento alla richiesta di accesso; altri, invece, possono essere memorizzati in presenza (e in corrispondenza) di ciascuno specifico oggetto (si fa riferimento ai tipi XSD complesso oggettoAnonimizzatoType e oggettoCompletoType) oppure del provvedimento di diniego (totale o parziale) oggetto di riesame e/o di ricorso.

Ove possibile, si ritiene preferibile la suddivisione in sottofascicoli delle richieste di accesso che abbiano una pluralità di oggetti. Tuttavia, qualora il sistema documentale in uso all’amministrazione non lo renda possibile, è sufficiente rispettare lo schema XSD proposto in questo documento.

A fini puramente illustrativi, e senza che sia necessario riprodurre i seguenti passaggi all’interno del sistema di protocollo, riportiamo di seguito un diagramma che indica i possibili passaggi della procedura di trattazione di una richiesta FOIA, incluse le fasi eventuali di ricorso amministrativo e giurisdizionale. I campi all’interno degli schemi XSD permettono di seguire queste fasi in maniera flessibile.

3.1 Schema di base – XSD-FOIA-RA-COMMON

In questa sezione si riportano le tipologie di base per la definizione degli schemi FOIA. Queste sono contenute all’interno dello schema XSD-FOIA-RA-COMMON.

Schema XSD-FOIA-RA-INT

          <?xml version="1.0" encoding="utf-8"?>
            <xs:schema targetNamespace="http://governo.it/foia/common/v1"
                elementFormDefault="qualified"
                xmlns="http://governo.it/foia/common/v1"
                xmlns:mstns="http://tempuri.org/XMLSchema.xsd"
                xmlns:xs="http://www.w3.org/2001/XMLSchema">
              <xs:simpleType name="categoriaRichiedenteType">
                <xs:restriction base="xs:string">
                  <xs:enumeration value="Privato cittadino" />
                  <xs:enumeration value="Giornalista" />
                  <xs:enumeration value="Ricercatore/accademico" />
                  <xs:enumeration value="Rappresentante di impresa" />
                  <xs:enumeration value="Rappresentante di organizzazione non governativa (ONG)" />
                  <xs:enumeration value="Rappresentante di associazione di categoria" />
                  <xs:enumeration value="Rappresentante di gruppo politico" />
                  <xs:enumeration value="Altro" />
                  <xs:enumeration value="Non dichiarato" />
                </xs:restriction>
              </xs:simpleType>
              <xs:complexType name="geographyType">
                <xs:sequence>
                  <xs:element name="citta" type="xs:string" minOccurs="0"/>
                  <xs:element name="provincia" type="xs:string" minOccurs="0"/>
                  <xs:element name="regione" type="xs:string" minOccurs="0"/>
                  <xs:element name="paese" type="xs:string" minOccurs="0"/>
                </xs:sequence>
              </xs:complexType>
              <xs:simpleType name="esitoType">
                <xs:restriction base="xs:string">
                  <xs:enumeration value="Accoglimento" />
                  <xs:enumeration value="Rifiuto" />
                  <xs:enumeration value="Accoglimento parziale" />
                  <xs:enumeration value="Inoltro per competenza ad altra PA" />
                  <xs:enumeration value="Mancata risposta" />
                </xs:restriction>
              </xs:simpleType>
              <xs:complexType name="faseComplexType">
                <xs:sequence>
                  <xs:element name="datainizio" type="xs:date" />
                  <xs:element name="tipoesito" type="esitoType" minOccurs="0"/>
                  <xs:element name="dataesito" type="xs:date" minOccurs="0"/>
                  <xs:element name="sintesimotivazione" type="xs:string" minOccurs="0" />
                  <xs:element name="motivirifiuto_5bis_33_2013" minOccurs="0">
                    <xs:complexType>
                      <xs:sequence>
                        <xs:element name="sicurezzaPubblicaEOrdinePubblico" type="xs:boolean" />
                        <xs:element name="sicurezzaNazionale" type="xs:boolean" />
                        <xs:element name="difesaEQuestioniMilitari" type="xs:boolean" />
                        <xs:element name="relazioniInternazionali" type="xs:boolean" />
                        <xs:element name="politicaEStabilitaFinanziariaEdEconomicaDelloStato" type="xs:boolean"/>
                        <xs:element name="conduzioneDiIndaginiSuiReatiELoroPerseguimento" type="xs:boolean"/>
                        <xs:element name="regolareSvolgimentoDiAttivitaIspettive" type="xs:boolean" />
                        <xs:element name="protezioneDeiDatiPersonali" type="xs:boolean" />
                        <xs:element name="libertaESegretezzaDellaCorrispondenza" type="xs:boolean" />
                        <xs:element name="interessiEconomiciECommerciali" type="xs:boolean" />
                        <xs:element name="segretoDiStato" type="xs:boolean" />
                      </xs:sequence>
                    </xs:complexType>
                  </xs:element>
                  <xs:element name="motivirifiutodiversi" minOccurs="0">
                    <xs:complexType>
                      <xs:sequence>
                        <xs:element name="richiestaVessatoria" type="xs:boolean" />
                        <xs:element name="richiestaDatiDocumentiNonEsistenti" type="xs:boolean" />
                        <xs:element name="richiestaDatiDocumentiNonPosseduti" type="xs:boolean" />
                        <xs:element name="richiestaGenerica" type="xs:boolean" />
                        <xs:element name="richiestaReiterata" type="xs:boolean" />
                        <xs:element name="richiestaEccessivamenteOnerosa" type="xs:boolean" />
                        <xs:element name="altro" type="xs:string" minOccurs="0" />
                      </xs:sequence>
                    </xs:complexType>
                  </xs:element>
                </xs:sequence>
              </xs:complexType>
              <xs:complexType name="differimentoType">
                <xs:sequence>
                  <xs:element name="datadecisionedifferimento" type="xs:date" />
                  <xs:element name="dataacuisidifferisce" type="xs:date" minOccurs="0" />
                  <xs:element name="commentidifferimento" type="xs:string" minOccurs="0" />
                </xs:sequence>
              </xs:complexType>
              <xs:complexType name="primaFaseComplexType">
                <xs:complexContent>
                  <xs:extension base="faseComplexType">
                    <xs:sequence>
                      <xs:element name="differimento" type="differimentoType" minOccurs="0" />
                      <xs:element name="contattocontrointeressati" type="xs:boolean" />
                      <xs:element name="sospensionecontrointeressati" type="sospensioneType" minOccurs="0" />
                      <xs:element name="sospensioneperfezionamento" type="sospensioneType" minOccurs="0" />
                    </xs:sequence>
                  </xs:extension>
                </xs:complexContent>
              </xs:complexType>
              <xs:complexType name="riesameComplexType">
                <xs:complexContent>
                  <xs:extension base="faseComplexType">
                    <xs:sequence>
                      <xs:element name="differimento" type="differimentoType" minOccurs="0" />
                      <xs:element name="richiestopareregaranteprivacy" type="xs:boolean" />
                      <xs:element name="sospensionegaranteprivacy" type="sospensioneType" minOccurs="0" />
                      <xs:element name="contattocontrointeressati" type="xs:boolean" />
                      <xs:element name="sospensionecontrointeressati" type="sospensioneType" minOccurs="0" />
                    </xs:sequence>
                  </xs:extension>
                </xs:complexContent>
              </xs:complexType>
              <xs:complexType name="oggettoAnonimizzatoType">
                <xs:sequence>
                  <xs:element name="sintesianonimizzataoggetto" type="xs:string" />
                  <xs:element name="ambitoDiRiferimento" type="xs:string" minOccurs="0" />
                  <xs:element name="ufficioCompetente" type="xs:string" minOccurs="0" />
                  <xs:element name="primafase" minOccurs="0" type="primaFaseComplexType" />
                  <xs:element name="riesame" minOccurs="0" type="riesameComplexType" />
                </xs:sequence>
              </xs:complexType>
              <xs:complexType name="oggettoCompletoType">
                <xs:complexContent>
                  <xs:extension base="oggettoAnonimizzatoType">
                    <xs:sequence>
                      <xs:element name="sintesioggetto" type="xs:string" />
                    </xs:sequence>
                  </xs:extension>
                </xs:complexContent>
              </xs:complexType>
              <xs:complexType name="sospensioneType">
                <xs:sequence>
                  <xs:element name="datainiziosospensione" type="xs:date" />
                  <xs:element name="datafinesospensione" type="xs:date" minOccurs="0" />
                </xs:sequence>
              </xs:complexType>
            </xs:schema>

A fini statistici e di BI è importante identificare la categoria cui appartiene il richiedente. Le categorie di interesse nell’ambito del FOIA sono specificate tramite il tipo semplice categoriaRichiedenteType.

Sempre a fini statistici e di BI può essere utile riportare le informazioni geografiche riguardanti il richiedente. Queste informazioni sono contenute nel tipo dato complesso geographyType riportato di seguito.

I possibili esiti di una specifica fase di una richiesta di accesso fanno capo ad una enumerazione fissa descritta tramite il seguente tipo semplice esitoType.

Le informazioni relative a ciascuna fase vengono memorizzate tramite un tipo complesso faseComplexType.

Definizione

L’esito definisce il risultato del procedimento di accesso in relazione alla ostensibilità o meno dell’oggetto della richiesta. L’art.5/bis del d. lgs. n.33/2013 definisce i motivi per i quali l’accesso può essere negato del tutto o in parte. Per ognuno di questi motivi l’elemento motivirifiuto_5bis_33_2013  contiene una serie di elementi booleani. Nella prassi tuttavia possono darsi altri motivi di rifiuto di natura procedurale non previsti nella disciplina legislativa in materia. Per questi motivi di rifiuto, di seguito elencati, è stato predisposto l’elemento motivirifiutodiversi: 

• richiestaVessatoria nel caso di richiesta irragionevole;
• richiestaDatiDocumentiNonEsistenti nel caso di richiesta relativa a documenti o dati che non esistono;
• richiestaDatiDocumentiNonPosseduti nel caso di richiesta relativa a documenti o dati che non sono in possesso dell’amministrazione destinataria e quest’ultima non reinoltri all’amministrazione competente (in caso di inoltro si utilizza il tipo di esito specifico)
• richiestaGenerica quando l’oggetto della richiesta non è identificabile
• richiestaReiterata quando la richiesta è identica ad una richiesta precedentemente inviata dallo stesso interessato a condizione che la precedente richiesta sia stata adeguatamente trattata ed evasa;
• richiestaEccessivamenteOnerosa quando la trattazione della richiesta comporti un onere troppo elevato per la PA non compatibile con il buon andamento dell’attività amministrativa;
• altro è un campo opzionale (di tipo stringa) che può essere riempito con eventuali altri motivi di rifiuto.

Fermo restando che nessun vincolo è enforced a livello di schema il contenuto del campo tipoesito dovrebbe essere valorizzato in base alle regole seguenti:

• Se tutti gli elementi di motivirifiuto_5bis_33_2013 e motivirifiutodiversi  sono impostati a false allora il campo tipoesito conterrà il valore “Accoglimento”.
• Se almeno uno degli elementi di motivirifiuto_5bis_33_2013 e motivirifiutodiversi è impostato a true allora il campo tipoesito può contenere i valori “Accoglimento parziale” o “Rifiuto”.

Il campo sintesimotivazione (opzionale) dovrebbe essere popolato soltanto se il campo tipoesito è inizializzato a “Accoglimento parziale” o “Rifiuto”.

Alcuni eventi possono incidere sul termine di conclusione del procedimento di accesso civico generalizzato (30 giorni) oppure sulla esecuzione della decisione assunta mediante invio della documentazione richiesta. In particolare, nella fase di prima trattazione della richiesta e nella fase di riesame è possibile che la richiesta sia accolta (del tutto o in parte) ma che l’ostensione, con l’invio materiale della documentazione, sia differita a un momento successivo. Inoltre, nella prima fase di trattazione, vi può essere una sospensione di 10 giorni per notifica ai controinteressati o una sospensione necessaria al perfezionamento della richiesta. Nella fase del riesame, ferma restando la possibilità di sospensione di 10 giorni per notifica ai controinteressati, nel caso in cui il contraddittorio non sia stato garantito nella prima fase, è inoltre possibile una sospensione dovuta alla richiesta di parere al Garante, prevista soltanto nella fase di riesame (art. 5, c. 7, d.lgs. 33/2013). A tal fine si definiscono i tipi XSD complessi primaFaseComplexType e riesameComplexType come estensione del tipo faseComplexType per modellare le particolarità della prima trattazione e della richiesta di riesame.

Definizione

I casi di “Accoglimento” ed “Accoglimento parziale” possono essere accompagnati da un differimento (elemento differimento). Qualora il responsabile del riesame chieda il parere del Garante per la protezione dei dati personali, questa evenienza viene rilevata tramite l’elemento richiestopareregaranteprivacy. Se il campo richiestopareregaranteprivacy è impostato su True (vero), occorre compilare il campo sospensionegaranteprivacy. Nel caso in cui in una delle due fasi (prima istanza o riesame) si proceda alla consultazione dei controinteressati, questa evenienza viene rilevata tramite l’elemento contattocontrointeressati. Se il campo contattocontrointeressati è impostato su True (vero), occorre compilare il campo sospensionecontrointeressati. Se si è resa necessaria una sospensione per il perfezionamento della richiesta con il richiedente, occorre utilizzare il campo sospensioneperfezionamento.

Una singola richiesta di accesso può contenere oggetti distinti (diverse categorie di dati o documenti) che possono essere detenuti da uffici diversi, che decidono sull’ostensione in modo autonomo. L’esito di una richiesta di accesso dipende dagli esiti relativi ai singoli oggetti. Un oggetto è definito come il tipo complesso XSD oggettoAnonimizzatoType e la sua estensione oggetto oggettoCompletoType.

Definizione

Ogni oggetto può contenere un esito singolo che contribuisce all’esito complessivo della richiesta di accesso. Anche in caso di riesame, è previsto un esito da specificare. In caso di diniego, l’esito può essere corredato da due diverse motivazioni: una ad uso interno (sintesioggetto), della quale non è prevista la pubblicazione, e l’altra ad uso esterno (sintesianonimizzataoggetto), destinata alla pubblicazione previa eliminazione dei dati sensibili o comunque non pubblicabili. Il campo ambitoDiRiferimento può essere utilizzato dalle amministrazioni di riferimento per impostare categorie personalizzate. Il campo ufficioCompetente è previsto per indicare l’ufficio che si occupa della gestione dell’oggetto.

Il procedimento di accesso può incorrere in diverse tipologie di sospensione dovute all’instaurazione alla consultazione dei controinteressati oppure al perfezionamento della richiesta (richiesta di chiarimenti) o, nella fase di riesame, alla richiesta di parere al Garante per la protezione dei dati personali. Una sospensione è descritta mediante il tipo XSD complesso sospensioneType.

Definizione

Una sospensione ha come dato obbligatorio la data di inizio, mentre la data di fine viene popolata soltanto al momento della fine del periodo di sospensione.

3.2 Metadati minimi – XSD-FOIA-RA-INT

I metadati relativi alle richieste di accesso rappresentano una estensione dei metadati associati ai documenti standard. A questo scopo è indicato con il nome documentType il tipo complesso (strutturato) che rappresenta il tipo di base per i documenti così come definito nell’Allegato 5 al D.P.C.M. 3 dicembre 2013, pubblicato nel Supplemento ordinario n. 20 alla GAZZETTA UFFICIALE, Serie generale – n. 59 del 12-3-2014. Di seguito la definizione XSD di questo tipo (si rimanda al documento originale per il significato dei singoli campi).

Schema XSD-FOIA-RA-INT

<?xml version="1.0" encoding="utf-8"?>
    <xs:schema targetNamespace="http://governo.it/foia/int/v1"
        elementFormDefault="qualified"
        xmlns="http://governo.it/foia/int/v1"
        xmlns:common="http://governo.it/foia/common/v1"
        xmlns:xs="http://www.w3.org/2001/XMLSchema">
      <xs:import namespace="http://governo.it/foia/common/v1"
               schemaLocation="FOIA-Common.xsd"/>
    
      <xs:complexType name="documentType">
        <!--Base document type-->
        <xs:sequence>
          <xs:element name="datachiusura" type="xs:date" />
          <xs:element name="oggettodocumento" type="xs:string" />
          <xs:element name="soggettoproduttore">
            <xs:complexType>
              <xs:sequence>
                <xs:element name="nome" type="xs:string" />
                <xs:element name="cognome" type="xs:string" />
                <xs:element name="codicefiscale" type="xs:string" />
              </xs:sequence>
            </xs:complexType>
          </xs:element>
          <xs:element name="destinatario">
            <xs:complexType>
              <xs:sequence>
                <xs:element name="nome" type="xs:string" />
                <xs:element name="cognome" type="xs:string" />
                <xs:element name="codicefiscale" type="xs:string" />
              </xs:sequence>
            </xs:complexType>
          </xs:element>
        </xs:sequence>
        <xs:attribute name="IDDocumento" type="xs:string" use="required" />
      </xs:complexType>
    
      <xs:element name="richiestadiaccesso">
        <xs:complexType>
          <xs:complexContent>
            <xs:extension base="documentType">
              <xs:sequence>
                <xs:element name="provenienzarichiedente" type="common:geographyType" minOccurs="0" />
                <xs:element name="categoriarichiedente" type="common:categoriaRichiedenteType" />
                <xs:element name="primafase" minOccurs="0" type="common:primaFaseComplexType" />
                <xs:element name="riesame" minOccurs="0" type="common:riesameComplexType" />
                <xs:element name="TAR" minOccurs="0" type="common:faseComplexType" />
                <xs:element name="difensorecivico" minOccurs="0" type="common:faseComplexType" />
                <xs:element name="consigliodistato" minOccurs="0" type="common:faseComplexType" />
                <xs:element name="presenzacontrointeressati" type="xs:boolean" />
                <xs:element name="numerocontrointeressati" type="xs:int" minOccurs="0" />
                <xs:element name="oggetto" minOccurs="1" maxOccurs="unbounded" type="common:oggettoCompletoType" />
              </xs:sequence>
            </xs:extension>
          </xs:complexContent>
        </xs:complexType>
      </xs:element>
    </xs:schema>

Una volta definiti i tipi complessi di base, si può introdurre la struttura XSD della richiesta di accesso definita dal seguente XSD.

Definizione

Il campo numerocontrointeressati non è obbligatorio, ma se popolato e maggiore di zero implica il campo presenzacontrointeressati a true. Viceversa, se popolato e uguale a zero il campo presenzacontrointeressati è a false.

Si suppone che la richiesta di accesso abbia almeno un oggetto.

Nel caso più semplice, di richieste aventi un oggetto singolo e non plurimo, il singolo oggetto corrisponde all’intera richiesta di accesso.

3.3. Schema XSD esportazione – XSD-FOIA-RA-EXT

Lo schema XSD illustrato in Sezione 3.2 (Metadati minimi -XSD-FOIA-RA-INT), serve a immettere nel Sistema di Protocollo Informatico i metadati relativi alle richieste di accesso. Nello schema XSD compaiono informazioni sensibili (ad es. il nome del richiedente) che non devono essere rese pubbliche tramite il Registro degli accessi. Per questo, lo schema XSD-FOIA-RA-EXT individua il sottoinsieme dei metadati che possono essere esportati nel Registro degli accessi. Successivamente sarà indicato come rappresentare questo schema XSD in formato tabellare (ai fini della pubblicazione nella sezione Amministrazione Trasparente). Questo schema può essere utilizzato anche da tutte le amministrazioni che non adottano quanto descritto in precedenza per facilitare il monitoraggio federato ed esportare i metadati relativi alle richieste di accesso previsto nella fase 2 (supra, Sezione 2.2).

Nel caso si vogliano fornire aggiornamenti continui (in tempo reale) su una richiesta di accesso è possibile specificare opzionalmente un elemento guid da popolare tramite un GUID (definito come indicato in https://it.wikipedia.org/wiki/GUID) che permette di tracciare l’andamento del procedimento di accesso nel tempo. Questo elemento è utilizzato al fine di non esporre il numero di protocollo.

Schema XSD-FOIA-RA-EXT

  <?xml version="1.0" encoding="utf-8"?>
    <xs:schema targetNamespace="http://governo.it/foia/ext/v1"
        elementFormDefault="qualified"
        xmlns="http://governo.it/foia/ext/v1"
        xmlns:common="http://governo.it/foia/common/v1"
        xmlns:xs="http://www.w3.org/2001/XMLSchema"
    >
    
      <xs:import namespace="http://governo.it/foia/common/v1"
                 schemaLocation="FOIA-Common.xsd"/>
    
      <xs:complexType name="richiestadiaccessoType">
        <xs:sequence>
          <xs:element name="guid" type="xs:string" minOccurs="0" />
          <xs:element name="provenienzarichiedente" type ="common:geographyType" minOccurs="0" />
          <xs:element name="categoriarichiedente" type="common:categoriaRichiedenteType" />
          <xs:element name="primafase" minOccurs="0" type="common:primaFaseComplexType" />
          <xs:element name="riesame" minOccurs="0" type="common:riesameComplexType" />
          <xs:element name="TAR" minOccurs="0" type="common:faseComplexType" />
          <xs:element name="difensorecivico" minOccurs="0" type="common:faseComplexType" />
          <xs:element name="consigliodistato" minOccurs="0" type="common:faseComplexType" />
          <xs:element name="presenzacontrointeressati" type="xs:boolean" />
          <xs:element name="numerocontrointeressati" type="xs:int" minOccurs="0" />
          <xs:element name="oggetto" minOccurs="1" maxOccurs="unbounded" type="common:oggettoAnonimizzatoType" />
        </xs:sequence>
      </xs:complexType>
    
    </xs:schema>

3.4 Schema XSD esportazione massiva – XSD-FOIA-RA-EXT-BULK

Lo schema XSD definito nella Sezione 3.3 (Schema XSD esportazione –  XSD-FOIA-RA-EXT) permette di inviare informazioni relative ad una singola richiesta di accesso. Gli aggiornamenti relativi alle richieste di accesso vengono solitamente inviati in gruppo. A tal fine in questa sezione viene definito lo schema XSD-FOIA-RA-EXT-BULK, che rappresenta una estensione di XSD-FOIA-RA-EXT.

Lo schema XSD-FOIA-RA-EXT-BULK consente di effettuare un aggiornamento in merito alle richieste di accesso ricevute in un determinato periodo definito dagli elementi inizioperiodo e fineperiodo. Prendendo spunto dalla specifica tecnica UNIEMENS, l’XSD richiede di indicare il codice fiscale del fornitore (c.d. software house) responsabile per il prodotto (occorre specificare come attributo un codice univoco di identificazione del prodotto). Inoltre, l’XSD richiede di indicare il codice fiscale dell’amministrazione responsabile per l’invio dell’aggiornamento (specificando l’ufficio all’interno dell’amministrazione competente).

Schema XSD-FOIA-RA-EXT-BULK

  <?xml version="1.0" encoding="utf-8"?>
    <xs:schema targetNamespace="http://governo.it/foia/bulk/v1"
        elementFormDefault="qualified"
        xmlns="http://governo.it/foia/bulk/v1"
        xmlns:ext="http://governo.it/foia/ext/v1"
        xmlns:xs="http://www.w3.org/2001/XMLSchema"
    >
      <xs:import namespace="http://governo.it/foia/ext/v1"
               schemaLocation="FOIA-EXT.xsd"/>
      <xs:simpleType name="CodiceFiscaleType" final="restriction">
        <xs:restriction base="xs:string">
          <xs:pattern value="[A-Z]{6}[0-9]{2}[A-Z]{1}[0-9]{1}[A-Z 0-9]{1}[A-Z 0-9]{4}[A-Z]{1}"/>
          <xs:pattern value="[0-9]{11}"/>
        </xs:restriction>
      </xs:simpleType>
    
      <xs:element name="monitoraggiorichiestediaccesso">
        <xs:complexType>
          <xs:sequence>
            <xs:element name="inizioperiodo" type="xs:date" />
            <xs:element name="fineperiodo" type="xs:date" />
            <xs:element name="CFSoftwarehouse">
              <xs:complexType>
                <xs:simpleContent>
                  <xs:extension base="CodiceFiscaleType">
                    <xs:attribute name="TipoProcSH" type="xs:string" use="required" />
                  </xs:extension>
                </xs:simpleContent>
              </xs:complexType>
            </xs:element>
            <xs:element name="CFAmministrazione">
              <xs:complexType>
                <xs:simpleContent>
                  <xs:extension base="CodiceFiscaleType">
                    <xs:attribute name="Ufficio" type="xs:string" use="required" />
                  </xs:extension>
                </xs:simpleContent>
              </xs:complexType>
            </xs:element>
            <xs:element name="richiestadiaccesso" minOccurs="0" maxOccurs="unbounded" type="ext:richiestadiaccessoType" />
          </xs:sequence>
        </xs:complexType>
      </xs:element>
    </xs:schema>

Note