Allegati

[ositalovignoli (Italo Vignoli)]

ANNOTAZIONI SULL’INTEROPERABILITA’

Allegato 2 - Formato dei File e Riversamento Pagina 25 - 107, Punto 19
I documenti in formato OOXML non sono interoperabili, secondo le più comuni definizioni di interoperabilità, per una serie di motivi: (1) la difficoltà nello stabilire la versione dello standard utilizzato per la creazione del documento stesso, (2) le differenze - apparentemente non documentate - tra versioni dello stesso documento salvate in date diverse con la stessa versione dello standard, (3) il fatto che le minute delle discussioni all’interno del comitato tecnico che gestisce lo standard, la cui composizione è altrettanto sconosciuta, non siano disponibili (le minute potrebbero dare risposta ai problemi dei punti 1 e 2), (4) l’assenza di implementazioni native dello standard da parte di più enti. Tutti questi punti sono chiaramente espressi nella definizione di standard aperto fornita dalle “Linee Guida su Acquisizione e Riuso di Software per le Pubbliche Amministrazioni”.

Allegato 2 - Formato dei File e Riversamento Pagina 41 - 107, Punto 2
Il formato XLSX contiene ancora oggi un bug vecchio di 42 anni, detto “Leap Year Bug” o “Bug dell’Anno Bisestile”, introdotto da VisiCalc nel 1977 e mantenuto sia da Lotus 123 che da Microsoft Excel. Il bug considera l’anno 1900 come bisestile, per cui ritiene che il giorno 29 febbraio 1900 sia esistito, e quindi introduce un errore di data per tutte le date successive, che viene corretto sia da Microsoft Excel che da tutti gli altri software attraverso un algoritmo. In un foglio elettronico, le date sono un elemento fondamentale di molti documenti e di molte formule, per cui l’esistenza di un errore che deve essere corretto in ogni documento che contiene una data rappresenta un problema per l’interoperabilità. Inoltre, il formato XLSX rappresenta le date non in formato data (per esempio, la mia data di laurea è 19/11/1978) ma con un numero progressivo a partire dal 1° gennaio 1900 (per esempio, la mia data di laurea è 28813, ovvero 28812 giorni dopo il 1° gennaio 1900, più il 29 febbraio 1900). Questo peggiora il problema dell’interoperabilità, in quanto forza un ricalcolo di tutte le date, con un secondo algoritmo che deve tenere conto di un altro algoritmo di correzione del bug dell’anno bisestile.

Allegato 2 - Formato dei File e Riversamento Pagina 61 - 107, Sezione 3.8
Esiste un progetto di software open source chiamato Croscore (Chrome OS core fonts) che fornisce una versione metricamente compatibile dei caratteri Arial (Arimo), Times (Tinos), Courier (Cousine), Calibri (Carlito) e Cambria (Caladea) per tutti i sistemi operativi. I caratteri citati al Punto 2, infatti, potrebbero essere a rischio in quanto la versione che può essere redistribuita, quella utilizzata attualmente, è quella rilasciata senza licenza d’uso in una vecchia versione di Microsoft Windows e i pacchetti originali non sono più disponibili (per cui si fa ricorso a versioni presenti in rete). Maggiori informazioni su Wikipedia: https://en.wikipedia.org/wiki/Core_fonts_for_the_Web.

[italovignoli]

Ho già fornito i miei commenti accedendo con le mie credenziali OSI.

[Luca_Braus]

ALLEGATO 1 – GLOSSARIO DEI TERMINI E DEGLI ACRONIMI

Per chiarire meglio alcuni concetti attualmente non presenti nel glossario, potrebbe essere un’idea inserire:

• la definizione di “documento amministrativo informatico”, anche prendendo spunto dalle 2 distinte definizioni di “documento amministrativo” contenute nell’art. 22, comma 1, della L. 241/1990 e nell’art. 1 del DPR 445/2000, e dalla definizione “indiretta” di documento amministrativo informatico presente all’art. 23-ter, comma 1, primo capoverso, del CAD.
• la definizione di “immodificabilità”, come nuova definizione, partendo dalla definizione presente nell’allegato 1 delle Regole tecniche 2013-2014 ed evitando la ripetizione iniziale della parola “contenuto” (ovvero io inserirei “caratteristica che rende il documento informatico non alterabile… […]”). In molte parti del CAD e delle Linee guida, parlando di documenti informatici, si citano quasi sempre le due caratteristiche di integrità e di immodificabilità come due concetti distinti. Per questo ritengo personalmente possa essere utile inserire la definizione di immodificabilità come concetto distinto, e non intrinseco, nel concetto di integrità.

Oltre a questi aspetti modificherei inoltre la definizione di “integrità” specificando a chi ci si riferisce con il “sua” (per esempio si potrebbe mettere “[…] garantisca l’inalterabilità nel tempo del documento stesso”).

---

Con questo mio commento ho concluso l’attività che personalmente, nel tempo libero, ho voluto dedicare a queste Linee guida.
Ringrazio fin da subito per la possibilità e l’attenzione che verrà posta ai miei come a tutti gli altri commenti.
Sono/siamo pronti ora per commentare la firma con SPID

[Fabrizio_Lupone]

ALLEGATO 5 - I METADATI
A mio parere rendere obbligatorio il metadato “Modalità di formazione” non ha senso in particolar modo nello scenario privato. La vedo come una complicazione rispetto al passato consiglio di renderlo opzionale ovvero obbligatorio solo per le PA o solo per il documento informatico amministrativo.

Sono d’accordo invece per l’aggiunta del metadato “Tipologia documentale” come obbligatorio in quanto è necessario sempre descrivere in modo appropriato la tipologia documentale che dal sistema di gestione documentale viene versata al sistema di conservazione (sono frequenti i casi in cui configurano tipologie documentali DOCUMENTI GENERICI o DOCUMENTI PROTOCOLLATI ed a mio avviso non vanno bene).

Il metadato “Dati di registrazione” va inteso sempre e solo obbligatorio per le pubbliche amministrazioni. Non può essere obbligatorio anche per i Privati ad eccezione della DATA DEL DOCUMENTO che invece serve. Come sottocampi ha senso lasciare obbligatorio per i Privati solo Data registrazione che in caso di documenti non protocollati è la Data di registrazione del documento intesa ad esempio come data pec, data firma, data marca temporale, data riferimento temporale in cui il documento è divenuto immodificabile, data del documento).

Sono molto sbalordito dell’obbligatorietà del sottocampo Ruolo del metadato “Agenti” che espressamente è stato pensato anche per i soggetti Privati, ma a mio parere è una complicazione non di poco conto richiedere obbligatoriamente di settare i valori:
• Creatore
• Mittente
• Destinatario
• Assegnatario
• Altro

Secondo tale logica se l’azienda produce il proprio libro giornale deve avere un metadato Agenti con un sottotipo che specifica che trattasi di Creatore, se conserva una PEC ricevuta avrà il metadato con un sottotipo in cui valorizza con Destinatario, un DDT passivo ancora Destinatario, un Ordine Elettronico tramite NSO il valore Mittente.
A mio avviso questo allontana la massa dalla digitalizzazione dei documenti perché complica. Si risolverà settando di default sempre “Altro” ma il discorso è quello di avere linee guida poco comprensibili per i milioni di partite Iva privati.

Consiglio di specificare come obbligatorio per i Privati il Tipo agente, il Nominativo, il Codice Identificativo e non il Ruolo che può rimanere obbligatorio per le PA o per i Documenti Informatici Amministrativi.

Perché non considerate di definire i metadati per il Documento Informatico con metadati più semplici ad uso privato e poi per il Documento Informatico Amministrativo allora inserite una maggior complessità per le pubbliche amministrazioni?

Anche il sottocampo “Versione” obbligatorio del metadato “Identificativo del formato” ossia l’obbligo di indicare all’atto della formazione il “Prodotto software utilizzato per la creazione del documento e relativa versione”, mi lascia perplesso e di difficile applicazione da parte di aziende e studi professionali. Consiglio di renderlo opzionale al fine di semplificare il processo.

Il metadato Verifica nel caso di firma elettronica avanzata che è basata su un processo tecnologicamente neutro la vedo un po’ difficile da gestire in modo obbligatorio, ad esempio pensate all’acquisizione come ricezione di un documento informatico sottoscritto con FEA da una controparte (caso di modalità di formazione b)). A mia personale opinione sarebbe giusto renderlo opzionale per chi desidera il check di controllo su firma, sigillo, attestazione conformità copia per immagine, ma non obbligatorio.

Il metadato Verifica modifica documento non è chiaro come applicarlo nella fase di conservazione. E’ quindi possibile nella fase di conservazione annullare, modificare, rettificare, integrare un documento conservato? Se questo metadato si riferisce solo alla fase di gestione (ad esempio per il protocollo delle PA) lo dovreste indicare altrimenti i soggetti privati come fanno ad applicare le Linee Guida?

[Fabrizio_Lupone]

ALLEGATO 4 – STANDARD E SPECIFICHE TECNICHE

Sono stati indicati una moltitudine di standard internazionali che quasi nessuno in Italia conosce, senza però indicare quando e come applicarli, in quali fase, per quali processi. A mio avviso tutto ciò rende il sistema ed il processo di gestione e conservazione molto complicato.

Di seguito elenco solo gli standard indicati nell’Allegato 4 per la fase di conservazione:

UNI 11386 - Standard SInCRO - Supporto all’Interoperabilità nella Conservazione e nel Recupero degli Oggetti digitali.

ISO 14721 - OAIS (Open Archival Information System), Sistema informativo aperto per l’archiviazione.

ISO 15836 - Information and documentation - The Dublin Core metadata element set, Sistema di metadata del Dublin Core

ISO/TR 18492 - Long-term preservation of electronic document-based information.

ISO 20652 - Space data and information transfer systems - Producer-archive interface -Methodology abstract standard.

ISO/CD TR 26102 - Requirements for long-term preservation of electronic records.

SIARD Software Independent Archiving of Relational Databases 2.0

Ministère de la culture et de la communication , Service interministériel des Archives de France, Standard d’échange de donnéès pour l’archiviage. Transfert – Communication – Élimination – Modification, ver. 2.1, 2018

METS - Metadata Encoding and Transmission Standard

PREMIS - PREservation Metadata Implementation Strategies

EAD (3)/ISAD (G)

EAC - CPF/ISAAR (CPF)/NIERA

SCONS2/EAG/ISDIAH

ICCU - Metadati amministrativi e gestionali (MAG) (metadati descrittivi, amministrativi-gestionali)

Al paragrafo 4.1 delle Linee Guida, AgID stabilisce che gli elenchi degli standard e delle specifiche tecniche ….(…) utilizzabili quali riferimento per il sistema di conservazione sono riportati nell’Allegato 4 “Standard e specifiche tecniche”. La domanda è: vanno rispettati obbligatoriamente tutti o sono di libera applicazione da parte del sistema di conservazione?tranne naturalmente UNI SInCRO che sappiamo essere d’obbligo.

Grazie

[Fabrizio_Lupone]

ALLEGATO 2 – FORMATI DI FILE E RIVERSAMENTO

Con l’entrata in vigore del Regolamento europeo GDPR, anche se già il previgente Codice della Privacy lo prevedeva come obbligo, sarà sempre più diffusa la necessità in caso di documenti con contenuto sensibile (ad esempio dati che possono fornire informazioni su stato di salute, religione, orientamento politico, ecc.) o documenti come file audio-video che possono essere considerati che potrebbero essere utilizzati per elaborazione di dati biometrici, oscurare i documenti con tecniche di crittografia.

Non si può esternalizzare ad un fornitore della gestione documentale e/o della conservazione facendo gestire i dati e documenti in chiaro, non oscurati, anche se accedono al sistema esclusivamente utenti autorizzati dal fornitore.

Ad esempio, nel caso di documenti sensibili sanitari possono accedere ai documenti in chiaro solo utenti autorizzati “addetti alla cura”, quindi non è ammessa la gestione documentale e/o la conservazione eseguita da un outsourcer senza oscuramento.

Le linee Guida e i suoi allegati non dicono nulla a riguardo se non per il Digital Cinema Initiatives (DCI) o sul formato Key Delivery Message (applicazioni crittografiche) raccomandato nella produzione dei master cinematografici per la distribuzione nelle sale. A mio avviso questi aspetti legati al cinema sono di scarsa applicazione per le esigenze realistiche nel mondo delle PA delle aziende e dei professionisti.

Quali tecniche di crittografia possono essere utilizzate? In caso di applicazione della crittografia, le estensioni dei formati cambiano? Come comportarsi se ad esempio l’estensione diventa .enc?

La crittografia serve a cifrare i referti medici, le immagini radiologiche, le cartelle cliniche, determinati documenti dell’area HR, ecc.

Forse sarebbe opportuna una disciplina in tal senso anche sulle tecniche e i formati di cifratura, questa è la proposta.

grazie

[Giancarla_Porro]

Aggiungo: Diversi passaggi risultano “forzati”. Non si capisce perché la certificazione di processo prevista dal CAD diventi improvvisamente “ certificazione del risultato di un processo”. Altrettanto forzato l’inserimento di un ambito “soggettivo”. Inoltre, un processo di dematerializzazione certificato ISO 9001 deve considerarsi di per sé sufficiente a garantire la conformità della copia, almeno fino a contestazione.

[Giancarla_Porro]

Allegato 5: Non è chiara la relazione tra l’elenco dei metadati minimi obbligatori e l’elenco dei metadati associati al documento informatico:
idDoc: è prevista la sola impronta HASH
L’allegato cita le modalità di formazione come elemento obbligatorio ma queste non rientrano nei metadati minimi
Le LG citano il riferimento temporale ma l’allegato no (a meno che non si intenda il valore “data di registrazione”). D’altro canto, i dati di registrazione NON sono compresi nell’elenco dei metadati minimi
Ecc. ecc.
Si suggerisce di rivedere la relazione tra metadati minimi previsti nelle Linee Guida con definizioni e obbligatorietà previsti nell’allegato 5

[Luigi_Foglia]

Allegato 2: Si suggerisce di sfruttare l’esperienza fatta in ambito di fatturazione elettronica, normando il formato dei principali documenti prodotti dalla PA come gli Atti e i moduli utilizzati per l’avvio dei procedimenti (come la “segnalazione certificata di inizio attività” ed altri).
Ciò garantirebbe non solo la loro leggibilità a lungo termine, ma anche la interoperabilità.
Si deve considerare che contenendo anche i metadati necessari (ed eventualmente anche le firme degli attori del procedimento e la marcatura temporale), tali formati documentali predeterminati sarebbero intrinsecamente autoconsistenti in termini di certezza giuridica anche fuori da un sistema informativo.
A ciò si aggiunga che essi potrebbero essere importati in qualsiasi sistema informativo mediante un semplice processo di indicizzazione e parsing standard, estraendo automaticamente i dati salienti senza necessità di costose procedure personalizzate, connessioni a db e quindi rimuovendo all’origine una ulteriore potenziale causa di inaccessibilità.
Questo ridurrebbe immediatamente i fenomeni di lock-in nei gestionali della PA e abbatterebbe i costi ed i tempi di migrazione tra un fornitore e l’altro quando le gare obbligano le PA a cambiare i gestionali.

[Luigi_Foglia]

Allegato 3: Diversi passaggi risultano “forzati”. Non si capisce perché la certificazione di processo prevista dal CAD diventi improvvisamente “certificazione del risultato di un processo”.
Altrettanto forzato l’inserimento di un ambito “soggettivo”.
Un processo di dematerializzazione certificato ISO 9001 deve considerarsi di per sé sufficiente a garantire la conformità della copia, almeno fino a contestazione.
Si ritiene, inoltre, assai difficoltoso implementare processi di dematerializzazione massiva che prevedano di concludersi con un rapporto di verifica sottoscritto da PU o soggetto privato “autorizzato” (vedasi capitolo 2.4, paragrafo 2)

[Luigi_Foglia]

Allegato 5: METADATI DEL DOCUMENTO INFORMATICO
• Manca uno schema di riferimento
• Dalla forma del documento in alcuni casi non si evince se alcuni valori vanno o meno valorizzati (es. IdDOC va valorizzato o vanno valorizzati solo i sottocampi Impronta e Algoritmo?)
• IdDoc - è un tag da valorizzare o vanno valorizzati solo i sottocampi Impronta e Algoritmo?
• Modalità di formazione – Dubbi sull’utilità del metadato e sulla suo obbligatorietà (e se l’informazione non è presente? Prevedere eventualmente un non noto oppure variare l’obbligatorietà
• Dati di registrazione – un documento deve essere conservato se ciò è previsto per legge o regolamento (dove per regolamento si potrebbe anche intendere un regolamento interno all’Azienda EP). In nessuna norma è richiesto che per conservare un documento essa debba essere necessariamente protocollato. Se così fosse tutta la documentazione clinica digitale (incluse le bioimmagini) che oggi vengono regolarmente conservate, risulterebbe non più conservabile perché non soggetta a protocollazione. Inoltre nel caso i documenti siano stati protocollati esistono per legge altri documenti e nella fattispecie “Registro giornaliero di Protocollo” e “Segnatura informatica” (il cui formato peraltro è normato) che tracciano tutti i metadati qui previsti e anche altri. Quindi si suggerisce di inserire solo il metadato numero di protocollo, attraverso il quale si può risalire a tutti gli altri dati qui richiesti che se ri-inseriti sarebbero ridondanti.
o Stato di trasmissione: non è sempre desumibile  togliere obbligatorietà
o Tipo registro: nessuno non è corretto, io potrei avere un registro che non è tra quelli indicati e quindi non noto
o Numero documento: non è meglio definire semplicemente un ID e poi dichiararne il type? Es. IdDoc 1234567 Type Numero di protocollo
• Oggetto – si suggerisce di tenere solo campo “oggetto” a testo libero. Tale campo se un’azienda AP vuole lo può codificare ma non ha senso averne due.
• Tipo Agente – da semplificare con Agent, Agent Type senza predeterminarlo e non obbligatorio
• Allegati – da togliere, gli allegati sono altri documenti che si possono legare al primo con delle relazioni
• Riservato – a parte che un metadato con valori booleani viene rappresentato con un testo alfanumerico, è importante sottolineare la caratteristica del documento che potrebbe essere “livello di confidenzialità” (o cose simili) ma non indurre la parte elaborativa relativa al fatto che tale documento deve essere nascosto (a chi peraltro …?) perché questo è un aspetto elaborativo che può cambiare nel tempo. (vedi differenza da caratteristiche proprie del documento e caratteristiche di elaborazione che si applicano come sovrastruttura al documento)
• Tempo di conservazione – da togliere è un’informazione di elaborazione
Le medesime informazioni possono essere considerate anche per i Metadati del documento amministrativo informatico
METADATI DELLE AGGREGAZIONI DOCUMENTALI INFORMATICHE
• Tipo di aggregazione – le opzioni sono estremamente riduttive es. Cartella clinica; dossier sanitario; diario di appello universitario, repertorio….
• Tipologia – assolutamente inutile
• Agenti – Ruolo: – le opzioni sono estremamente riduttive, adottare Agent e Agent Type
• Assegnazione – informazione applicabile al solo ambito del protocollo informatico
• Classificazione – Rendere non obbligatorio
• Chiave descrittiva – mantenere solo oggetto (vedi osservazione nei metadati del documento)
• Procedimento processo – informazioni applicabili al solo ambito del protocollo informatico
• Indice dei documenti – manca l’hash di ogni singolo documento contenuto nell’aggregazione documentale (eventualmente non obbligatorio)
• Posizione fisica dell’aggregazione documentale – aberrante! È un’informazione di elaborazione
• Tempo di conservazioni: vedi osservazioni precedenti sui metadati del documento, è un’informazione di elaborazione.
CARATTERISTICHE DEL DOCUMENTO E CARATTERISTICHE DI ELABORAZIONE
Le caratteristiche di un documento sono quelle che permangono nel tempo mentre quelle di elaborazione possono cambiare.
• Riservato
• Tempo di conservazione
• Luogo di conservazione …

• Si sono riscontrate, inoltre, difficoltà nel comprende quali siano le modalità (dove e come) per la pubblicazione di classificatore / titolario e del relativo URI