5 Formato software di rappresentazione dei documenti

5 Formato software di rappresentazione dei

documenti

L’identificazione dei formati elettronici da utilizzare per la produzione dei documenti informatici conservabili è una scelta di fondamentale importanza nella progettazione di un sistema di archiviazione dei documenti.

Il formato con cui un documento viene creato è alla base della sua successiva fruizione. Perciò il formato scelto deve essere adeguato affinché il documento rimanga accessibile nel tempo.

Un file senza software che lo interpreta è una sequenza di bit senza significato. Condizione necessaria per l’intelligibilità nel lungo periodo è che il formato destinato alla conservazione sia uno standard aperto. Pare infatti che i formati aperti e standard abbiano in media una vita più lunga rispetto ai formati proprietari. Inoltre anche in futuro le specifiche di questi formati saranno note e chiunque potrà sviluppare software adeguati a processare i file conformi a tali formati (nel caso in cui non sia stato effettuato un riversamento sostitutivo, ovvero una trasposizione dei file con formato obsoleto in un formato adeguato10_).

È opportuno considerare una volta ancora che l’attuale fruizione dei dati organizzati in un documento è ancora conseguenza di identificare il dato con il documento su cui è scritto. In futuro, come già detto molte volte, probabilmente non si parlerà più di conservazione di documenti, ma di dati. Per ora un sistema di conservazione di documenti elettronici a norma deve poter conservare la “forma” del documento, oltre che il suo contenuto. I sistemi a norma quindi, in prima istanza, devono poter conservare documenti “originali” (firmati digitalmente) qualsiasi sia il loro formato, anche se questo risulta essere inadeguato per la conservazione a lungo termine.

10 _{Il riversamento sostitutivo è il processo tramite il quale la rappresentazione digitale del} documento viene cambiata (cambia la sequenza di bit che compone il documento perché ne viene cambiato il formato), senza che però vari la rappresentazione “esteriore” di esso.

Il periodo in cui viene scritta questa tesi è un periodo transitorio, durante il quale viene prodotta ancora in abbondanza documentazione cartacea, che, a volte, si cerca di “digitalizzare”11_.

In ogni caso ad oggi, è raro che un documento venga prodotto in un formato “autodescrittivo” (XML); come già detto spesso viene data una “forma” specifica al documento contenente le informazioni da archiviare, cosa che non è possibile (in modo semplice) effettuare con l’XML. A conferma di questo, è il fatto che quasi la totalità dei documenti prodotti digitalmente da procedure informatizzate ha formato PDF (Portable Document Format), anche se questo formato non è adatto, come verrà spiegato più avanti, per la conservazione a lungo termine e tantomeno per un parsing sulla struttura del file.

Oggi quindi, a meno che non vengano escluse determinate tipologie di file, i sistemi di archiviazione devono poter archiviare documenti qualsiasi sia il loro formato. Accettare solo documenti in formati autodescrittivi renderebbe molto più semplice l’indicizzazione dei file sui database per la ricerca ed il conseguente storage delle informazioni, ma non sarebbe adeguato ai tempi.

In questo caso, oltre che la conservazione dei documenti, è necessario il mantenimento dei software per l’interpretazione del formato con cui i documenti sono espressi. Poiché i software per la lettura dei documenti dipendono dal sistema operativo su cui sono fatti girare, è necessario che, ad un’eventuale aggiornamento del sistema operativo venga testata la compatibilità dei software. Se la compatibilità non sussiste, è necessario aggiornare, se possibile, i software “obsoleti”. Nella versione aggiornata tali software devono mantenere la compatibilità con le versioni precedenti.

Se uno di questi due passi fallisce, allora, è necessario effettuare un riversamento sostitutivo dei documenti che possiedono un formato il cui software di lettura è obsoleto.

11 _{Come accade nel già citato progetto avviato dalla Regione Lazio per la dematerializzazione} delle impegnative mediche, che ad oggi, e si presume ancora per anni, vengono prodotte in formato cartaceo. Uno dei motivi per i quali è stato avviato questo progetto, tra l’altro, riguarda la prevenzione della truffa delle false impegnative che per anni è stata attuata ai danni della Regione Lazio. In tale frode si falsificavano impegnative che venivano rimborsate più volte dal Sistema Sanitario Regionale. La digitalizzazione delle impegnative previene in modo radicale questo tipo di truffa.

Per la conservazione dei documenti anche nella forma, i formati indicati, in generale, sono quelli che consentono la rappresentazione univoca del documento, la stessa rappresentazione cioè che è stata data dall’autore del documento (si pensi ad esempio ad una pagina HTML che viene visualizzata diversamente a seconda del browser che la interpreta).

Inoltre è indicato che il formato elettronico scelto non dia strumenti per poter contenere macro istruzioni o “collegamenti ipertestuali” a file o comunque oggetti informativi esterni. Bisogna avere la garanzia che il documento risulti statico rispetto all’ambiente e al sistema in cui viene visualizzato.

Come già detto i formati autodescrittivi sarebbero i più indicati per la conservazione e per la fruizione delle informazioni, perché indipendenti dalla piattaforma e poiché strutturano l’informazione in modo che essa sia autodescritta.

Questi formati però, non definiscono una rappresentazione visuale univoca perciò non vengono utilizzati molto spesso per la generazione dei documenti “ufficiali”.

Nei prossimi paragrafi vengono descritti alcuni formati utili per la conservazione per lungo periodo di documenti.

5.1 PDF/A

Il PDF/A (Portable Document Format For Archive)[DOC11][DOC12] è un formato per la rappresentazione di documenti divenuto standard ISO nel 2005 (ISO 19005:2005) [DOC13]. Questo standard, sviluppato dall’Adobe e che deriva dal PDF, è aperto e progettato per la conservazione a lungo termine dei documenti.

Come il PDF, questo formato consente la visualizzazione dei documenti in maniera indipendente dalla piattaforma hardware, software, e dal sistema

operativo. Questo avviene perché il formato è “self-contained”, cioè al suo interno contiene tutte le informazioni necessarie alla corretta visualizzazione da parte delle applicazioni che processano il file.

Il PDF/A è un formato creato apportando delle restrizioni alle funzionalità del PDF, restrizioni necessarie per garantire una visualizzazione “statica” del documento; molte delle funzionalità consentite nel formato PDF non si adattano infatti alla conservazione a lungo termine. Ad esempio nel PDF/A non sono consentite variabili d’ambiente o macroistruzioni: tali variabili o operazioni potrebbero modificare infatti il documento in maniera non trasparente all’utente.

Il formato PDF permette inoltre riferimenti a fonti esterne, caratteristica che non concorda con la proprietà d’immutabilità che deve possedere un file archiviato. Questa caratteristica non è infatti consentita nel PDF/A

5.1.1 Caratteristiche

Lo standard PDF/A è progettato in “parti”: questo permette l’eventuale aggiunta di nuove parti senza che tale aggiunta determini l’obsolescenza delle parti precedenti.

Le caratteristiche principali del PDF/A, descritte nella sua documentazione, sono le seguenti:

- indipendenza dalla piattaforma;

- self contained: ogni elemento necessario alla visualizzazione del file è contenuto all’interno del file stesso;

- self documenting: il PDF/A richiede che i metadati interni al file siano descritti tramite il formato Adobe Extensible Metadata Platform (XMP). Altri schemi di descrizione dei metadati possono comunque essere usati purché siano inglobati nel file;

- inibizione della crittografia. Non è permesso inibire la visione di un documento in formato PDF/A. Un file PDF/A può comunque essere contenuto in una struttura più ampia che può essere crittografata;

- accessibilità: il formato è basato su specifiche disponibili pubblicamente.

In un file PDF/A non sono permessi:

- riferimenti esterni;

- la crittografia (non ci può essere il campo Encrypt nell’header del documento);

- file eseguibili;

- fonts non definiti nelle Reference. Tutti i fonts devono essere incorporati all’interno del file;

- contenuti o annotazioni nascosti;

- contenuti multimediali audio o video;

- firme digitali non conformi ai vincoli del formato.

5.1.2 Struttura

La struttura del PDF/A [WWW13], come quella del PDF, è formata da due sottostrutture, una “fisica” che descrive come è organizzato il file, e una struttura “logica” che definisce come i contenuti del file sono utilizzati per rappresentare gli elementi che descrivono il documento PDF.

Gli elementi base di cui si compone un file PDF sono gli oggetti (Object): in un documento PDF vengono definiti alcuni Object che, inclusi all’interno di strutture più complesse, consentono l’inserimento di vari attributi utili nella visualizzazione del file.

Un file PDF/A è formato da quattro elementi (Header, Body, Cross Reference Table, Trailer) che compongono la sua struttura (figura 5-1). Se un file PDF/A viene modificato, questa struttura, escluso l’Header, viene ripetuta in modo tale da contenere gli aggiornamenti. In questo modo la struttura del file cresce in maniera incrementale: praticamente viene effettuato un aggiornamento degli oggetti anziché una sovrascrittura.

figura 5-1: struttura fisica PDF/A

La struttura logica del documento PDF/A (figura 5-2), come quella del PDF, può essere rappresentata come una gerarchia di Objects. L’ordine con cui compaiono gli Objects all’interno del file non ha un significato semantico. In generale, un’applicazione può processare un file attraverso i riferimenti successivi da oggetto a oggetto piuttosto che attraverso un processamento sequenziale degli oggetti nell’ordine in cui essi compaiono.

Figura 5-2 struttura logica documento PDF/A

5.1.3 Considerazioni

Nel 2006 il CNIPA e Adobe Systems Inc. hanno sottoscritto un protocollo d’intesa [LEX9][WWW14][WWW15] tramite il quale il PDF è stato riconosciuto come

Header

Body

Cross Reference Table

Trailer Outline Entry Content Document Catalog Outline Hierarchy Outline Entry Page Tree Page Page Images Annotations

formato valido per la firma digitale, così come definita dal Codice dell’Amministrazione Digitale. Al PDF sono stati riconosciuti i requisiti previsti dall’articolo 12, comma 9 della Deliberazione CNIPA 4/2005, in particolare per quanto concerne la disponibilità pubblica e gratuita sia delle specifiche del formato, sia di un prodotto di verifica, l’Adobe Reader appunto.

Il PDF si è affiancato quindi al P7M, formato aperto valido per la firma digitale.

A questo punto però appare un controsenso. Come è stato spiegato precedentemente il PDF non è un formato adatto alla conservazione, infatti proprio per questo è nato il PDF/A. Quindi è una contraddizione firmare un documento utilizzando il formato PDF e successivamente archiviare tale documento firmato. Si rischierebbe, nel futuro, di non poter più verificare la firma del documento (visto che il PDF permette variabili d’ambiente e hyperlink), oppure di non poter più leggere correttamente il documento stesso a causa dell’obsolescenza del formato PDF.

L’utilizzo del formato PDF per la firma di un documento è ancora da chiarire.

Sicuramente è ragionevole utilizzare il formato PDF/A per la conservazione di documenti nel tempo. Il formato ha le specifiche aperte ed è inoltre uno standard ISO. Non si rischia insomma, che nel futuro non vi siano lettori di tale formato. IL PDF/A però rimane proprietario e quindi ogni eventuale modifica dello standard deve essere approvata anche da Adobe. Questo non dovrebbe però costituire un problema, visto che, anche per motivi economici, all’Adobe comunque conviene sempre apportare modifiche a un suo prodotto per poterlo continuare a mantenere all’apice del mercato.

I documenti, per avere il formato PDF/A, oltre ovviamente a seguire le specifiche di tale formato, devono essere riconosciuti come tali da un software, il cosiddetto “validatore”.

Esistono alcuni validatori di PDF/A sia open source che a pagamento; alcuni di questi sono più affidabili, altri meno. In altre parole non è detto che documenti in formato PDF/A vengano riconosciuti come tali da tutti i validatori. Può

accadere che alcuni di questi software considerino non validi anche documenti che invece lo sono.

Questo problema accade soprattutto per i software scaricabili gratuitamente e pare che sia dovuto a diverse interpretazioni di alcuni punti delle lunghe specifiche del formato PDF/A.

Questo può costituire un grosso problema: alcuni documenti approvati come PDF/A oggi, non potrebbero più essere riconosciuti come tali nel futuro, perché controllati da un validatore diverso.

C’è però da dire che la maggioranza dei software proprietari in grado di generare documenti in formato PDF/A e alcuni di quelli gratuiti generano file conformi alle caratteristiche del PDF/A. Quindi se il software che genera questi file è un programma affidabile, non ci dovrebbero essere problemi di alcun tipo.

Senz’altro si può dire che il PDF/A è un formato congruo alla conservazione di documenti “originali”, mantenendo inalterata anche la loro forma. Altri formati standard, come il Rich Text Format (rtf), hanno delle caratteristiche che non sono adatte all’archiviazione (ad esempio perché permettono link esterni).

Il parsing di un documento PDF/A, come per i documenti PDF, è praticamente inattuabile. Per un’indicizzazione su un database del documento in base al suo contenuto è necessario che a corredo del documento siano presenti attributi che lo descrivano.

5.2 XML

5.2.1 Caratteristiche

L’XML, acronimo di eXtensible Markup Language [DOC14], è un (meta)linguaggio di markup tramite il quale è possibile dare un formato strutturato ed una semantica ai dati.

Definito dal W3C a partire dal 1998, l’ XML basa la sua struttura su testo, ovvero la rappresentazione di un file XML è semplicemente costituita da una sequenza di caratteri Unicode o ISO/IEC 10646. La natura testuale di XML ne garantisce l’interoperabilità e la continuità nel tempo; non è necessario utilizzare particolari software per leggere contenuti di un file XML, ma è sufficiente un text editor.

Un documento XML, è simile ad un documento HTML in quanto offre una struttura sintattica caratterizzata da tag; come l’HTML, l’XML non ha bisogno di validazione per essere visualizzabile, ma è sufficiente che sia ben formato, ovvero sintatticamente corretto.

La principale differenza che esiste tra HTML e XML consiste nella strutturazione semantica di quest’ultimo. Un documento HTML, non indica nulla sul significato degli elementi demarcati dai tag: ad esempio, il tag <h1> _indica

che l’elemento successivo a quel tag deve essere visualizzato con caratteri di dimensione maggiore rispetto alla dimensione usuale, ma tale tag non indica nulla sul significato dell’elemento che demarca. L’informazione che offrono i tag HTML riguarda la struttura sintattica, non semantica.

Tramite l’XML invece è possibile definire strutture semantiche con le quali strutturare i dati che tali strutture dovranno contenere e descrivere.

5.2.2 Struttura

Il documento è composto da elementi. L’entità radice è detta Document Entity; gli elementi sono delimitati da <tag> all’inizio della Entity, e da </tag> al termine di essa; all’interno degli elementi possono essere presenti, nidificati, altre elementi.

Ogni elemento può avere attributi propri, ai quali viene associato un valore, in questo modo: <tag attr1=”val” attr2=”val”>

Una struttura generica di un documento XML è nella forma seguente:

<?xml VersionInfo EncodingDecl ...> <tag0>

<tag1-1 attr3=“...“ ...> … </tag1-1> </tag1> <tag2> … </tag2> … <tagN> … </tagN> </tag0>

L’elemento radice del documento XML può contenere o puntare a Markup Declaration, che forniscono una grammatica per quel documento. Questa grammatica, che dà vincoli sintattici, tipicamente è espressa mediante Document Type Definition (DTD) oppure tramite XML Schema; in questo modo è possibile definire un numero illimitato di elementi, e quindi di tag, utili per strutturare al meglio l’informazione.

Raramente per un documento XML viene utilizzata la forma generica. Spesso si fa uso di forme specifiche standardizzate secondo metalinguaggi definiti da XML Schema o DTD, che permettono di aggiungere vincoli sintattici alla struttura originale dell’XML. Un esempio è il WSDL, metalinguaggio derivato da XML (e conforme ad uno specifico XML Schema) che permette di descrivere le funzionalità offerte da un web service.

5.2.3 Considerazioni

I documenti XML, se ben formati e conformi alle regole formulate dal W3C, sono detti autodescrittivi, poiché contengono essi stessi sia i dati, sia le regole che descrivono la struttura dei dati.

L’informazione strutturata nei file XML è facilmente ottenibile utilizzando parser XML ai quali vanno passati in input i file XML Schema o DTD utilizzati

per dare regole sintattiche. La maggior parte dei linguaggi di programmazione possiede librerie che permettono il parsing di documenti XML ben formati.

Dal punto di vista della conservazione a lungo termine i file XML appaiono molto adatti per la conservazione dei dati e della loro strutturazione. Tali file, come detto, non sono assolutamente dipendenti da sistemi operativi o da software, ma sono costituiti da testo codificato secondo standard internazionali (oltretutto il testo è leggibile ed interpretabile anche da occhio umano). I file XML non richiedono particolari strumenti per la loro elaborazione, ma sono sufficienti funzionalità di parsing che, come detto, sono presenti nella maggior parte dei linguaggi di programmazione. Inoltre l’XML è uno standard anch’esso (W3C) che, come espresso precedentemente, permette la descrizione della struttura dei dati presenti nel file: queste caratteristiche sono ottime nell’ottica della conservazione di dati nel lungo periodo.

Ad oggi però, è raro che venga utilizzato il formato XML per la generazione di documenti. In generale si continua a preferire sempre una struttura “visiva” del documento simile a quella che potrebbe avere lo stesso documento in formato cartaceo, forse perché molto spesso i documenti creati digitalmente vengono comunque stampati su carta.

Come detto nei capitoli precedenti, una delle idee alla base della dematerializzazione è la produzione di documenti originali in formato digitale, senza che i documenti debbano essere stampati su carta (altrimenti il processo non avrebbe alcun senso). Vista la semplicità di interpretazione automatica dei formati come XML, si può dire che in futuro certamente i documenti verranno prodotti in formati autodescrittivi, ma ancora oggi questo non accade spesso.

Il sistema di conservazione deve essere rivolto al futuro, quindi pronto ad accogliere documenti in formato autodescrittivo; allo stesso tempo non è possibile ignorare gli altri tipi di documento aventi formati che possono dare una formattazione stile cartaceo, anche se tali formati non permettono assolutamente di raggiungere in modo automatico le informazioni.

5.3 DICOM

Ormai da parecchi anni esistono formati elettronici per la rappresentazione e visualizzazione di documenti digitali di ambito strettamente medico (come immagini radiologiche, cartelle cliniche, analisi mediche varie ecc.).

Alcuni di questi formati non sono standard ISO, ma possono essere comunque considerati standard “de facto”, quindi ufficiali: in particolare il formato DICOM (Digital Imaging and COmmunication in Medicine), standard industriale, è un formato ormai diffuso in tutto il mondo e che sta prendendo piede sempre più nell’ambito della diagnostica medica.

5.3.1 Caratteristiche

Il formato DICOM [DOC15] definisce i criteri per la rappresentazione (ma anche per la comunicazione e la stampa) di documentazione medica, in particolare di immagini digitali relative alla diagnostica medica.

Questo formato, nato nel 1993 da una collaborazione tra la NEMA (National Electrical Manufacturer Association) e l’ACR (American College of Radiology) ed elaborato a partire da formati precedenti, gestisce sia le immagini digitali, sia le informazioni correlate ad esse. Tramite questo standard si è posto fine all’utilizzo di formati proprietari non esportabili realizzati dai produttori di macchinari radiologici; DICOM ha definitivamente stabilito la non divisibilità tra i dati contenuti nell’immagine medica ed il referto, cioè la descrizione dell’immagine stessa.

Questo standard ha promosso un radicale cambiamento della diagnostica per immagini promuovendo un’interconnessione tra apparecchiature di diagnostica medica, postazioni di visualizzazione e refertazione, server e computer paragonabile alla nascita delle reti di computer nell’ambiente informatico.

La diffusione del DICOM è dovuta in parte al fatto che questo formato adotta protocolli come TLS e ISCL (standard ISO) per garantire integrità e

confidenzialità dei dati. Allo stesso modo i formati utilizzati per rappresentare le immagini allegate ai documenti DICOM sono formati standard (es. JPEG, TIFF).

Vista l’enorme diffusione di DICOM, pare che questo formato diventi uno standard anche per altre tipologie di documenti che oggi vengono prodotti in formati diversi e non molto diffusi. In ambiente medico sanitario l’ideale sarebbe avere un unico formato standard per ogni documento di carattere informatico medico e sembra che DICOM possa essere un candidato per questo scopo.

A differenza del CDA il DICOM, come detto, è specifico per documenti derivanti da esami di diagostica per immagini. Gli attributi che definisce sono, in generale assimilabili a quelli definiti dal CDA, ma spesso vanno più nello specifico.

5.3.2 Struttura

DICOM oltre che immagazzinare l’immagine, archivia i dati relativi sistemandoli in Group. I possibili Group sono: Patient, Study, Series e Image (figura 5-3):

- Patient: in questo gruppo vengono riportate le informazioni relative alla persona sottoposta all’indagine medica;

- Study: in Study sono riportate le caratteristiche dell’esame diagnostico effettuato;

- Series: questo gruppo contiene le informazioni relative alla modalità di acquisizione dell’immagine;

- Image: nel gruppo Image sono definiti gli attributi relativi all’immagine, come la dimensione, profondità dei pixel interpretazione fotometrica, ecc..

figura 5-3: esempio di Information Object Data relativo ad un documento DICOM (tratto da TableA.2-1 di [DICOM])

L’insieme dei Group forma uno IOD, ovvero un Information Object Data, nel quale sono specificate le informazioni che quel particolare documento DICOM possiede. Sono definiti IOD capaci di descrivere immagini CT (Computed Tomography), immagini US (UltraSound, ovvero ecografie), immagini radiologiche ecc..

In particolare, all’interno delle strutture IOD i dati, codificati in una maniera piuttosto complicata, vengono inseriti in strutture dette Attribute Module.

Esistono specifici Attribute Module per ogni Group che forma lo IOD (in figura 5-4 è riportato un estratto dell’Attribute Module relativo al Group Patient). Ogni Attribute Module possiede una lista di attributi (Data Element) specifici per la descrizione di un Group.

Ad ogni attributo presente in un Attribute Module è assegnato:

- Data Element Tag (tag): il tag è sostanzialmente un identificatore costituito da un byte di cui i primi quattro bit specificano il Group cui quell’Attribute Module si riferisce, e gli ultimi quattro bit specificano l’attributo all’interno dell’Attribute Module;

- Value Representation (VR): campo opzionale che specifica il tipo (intero, stringa ecc..) dell’attributo. La VR di ogni Data Element è specificata anche nel Data Dictionary;

- Value Length: specifica il numero di byte necessari a rappresentare il campo Value Field;

figura 5-4: Attribute Module relativo al Group Patient (tratto da Table C.2-3 di [DICOM])

Il formato DICOM non si limita a ben specificare e definire attributi per ogni Group, ma dà la possibilità di espandere il set di attributi, dando strumenti per la definizione di nuovi Data Element. In questo senso la struttura DICOM è relativamente plasmabile ed è per questo che in futuro si pensa che il formato DICOM possa divenire utilizzabile anche al di fuori della diagnostica medica.

DICOM assicura inoltre l’interoperabilità tra le apparecchiature in quanto definisce un protocollo di comunicazione basato su TCP/IP [DOC15][DOC16]. L’unico requisito richiesto affinché una macchina possa entrare a far parte di una

rete DICOM è che adotti il protocollo definito da DICOM per dialogare con le altre componenti della rete.

DICOM rifonda in qualche modo il paradigma Client/Server definendolo User/Provider: sono Provider le macchine in grado di fornire servizi verso l’esterno, sono User le entità che usufruiscono di tali servizi.

In una rete DICOM i principali servizi che è possibile intraprendere sono:

- Storage: servizio tramite il quale è possibile inviare un’immagine DICOM ad un server;

- Storage Committment: servizio che perette di dare allo User conferma che l’immagine DICOM che ha spedito è stata correttamente recapitata al Provider;

- Query/Retrieve: servizio che permette allo User di ricercare un’immagine DICOM presente in un server;

- Modality Worklist: servizio che permette di gestire una lista di esami che il paziente deve effettuare. La lista ed il referto degli esami vengono aggiornati tramite la chiamata di questo servizio;

- Print: servizio per la stampa delle immagini DICOM.

5.3.3 Considerazioni

Tramite le reti DICOM è possibile costituire una sorta di archivi di documenti DICOM relativi alla diagnostica medica

Una rete DICOM, anche se apparentemente potrebbe essere adottata per gestire un sistema per la conservazione digitale di documenti sanitari (almeno per quanto riguarda la diagnostica per immagini), non è in effetti utilizzabile a questo scopo. Come è già stato spiegato una rete DICOM permette la modifica dei dati che la rete stessa contiene. Modalità di firma digitale dei documenti sono state previste solo recentement. Il sistema comunque è privo di sistemi di sicurezza per il recupero di eventuali dati perduti.

Un sistema di archiviazione digitale parte da una concezione completamente diversa da quella che si ha in una rete DICOM, però proprio dal sistema DICOM sono stati ripresi dei concetti, come si vedrà più avanti, in particolare per quanto

riguarda la definizione di una modalità “standard” di comunicazione e per la gestione degli attributi dei documenti da archiviare.

Il DICOM dà una struttura autodescrittiva ai dati che contiene, e per questo motivo è assimilabile a documenti XML conformi a determinati XML Schema. È possibile ottenere le informazioni dal DICOM in maniera automatica, ma questa operazione non è così semplice come lo era per l’XML. Per far questo esistono specifici software, sia Open Source che proprietari, tramite in quali è possibile, in modo semplice, ricavare le informazioni che un documento DICOM contiene.

Anche se il formato DICOM è in continua evoluzione, i software utilizzati per la lettura dei documenti DICOM garantiscono la compatibilità anche con le versioni più “antiche” del formato.

Sicuramente un sistema per la conservazione di documenti a carattere prevalentemente medico clinico deve poter archiviare documenti in formato DICOM.

5.4 Considerazioni

Come esposto nei capitoli precedenti, il problema dell’archiviazione digitale non riguarda soltanto il mantenimento sicuro nel tempo dei documenti archiviati, ma è altresì necessario che tali documenti debbano rimanere leggibili ed inalterati (anche nella forma) nel tempo. Archiviare dati in formati potenzialmente non usufruibili in futuro è assolutamente inutile.

I formati ideali per la conservazione dei documenti sono quelli autodescrittivi, come l’XML, perché, come detto, possono mantenere sia l’informazione, sia la semantica di essa. C’è da dire però che spesso le procedure informatizzate producono documenti direttamente in formato PDF o simili. Tali documenti, se necessitano di essere conservati, devono pervenire al sistema di archiviazione

corredati da attributi descrittivi dell’informazione contenuta al loro interno: in questo modo tali documenti potranno essere indicizzati nel migliore modo possibile.

Per questi documenti nati in formati diversi dall’XML o dal DICOM, il PDF/A sarebbe il formato più ragionevole, per le motivazioni già esposte nei paragrafi riguardanti il PDF/A.

Per documenti di ambito prettamente medico più complessi è necessario utilizzare altri formati, come il DICOM.

L’archiviazione di tali documenti, una volta firmati, non dovrebbe presentare particolari problemi riguardanti il mantenimento in archivi digitali. Possibili problemi potrebbero altresì riguardare la lettura di tali formati in futuro, visto che essi sono in continua evoluzione. Anche i software per leggerli tuttavia sono in continuo aggiornamento, e consentono oltretutto di aggiornare i formati “obsoleti” in formati più moderni (ovviamente senza modifiche al documento medico vero e proprio): praticamente un riversamento sostitutivo.

L’archiviazione dei formati autodescrittivi come l’XML o il DICOM non presenta particolari problemi, né per la firma e l’archiviazione di tali documenti, né per la lettura di questi formati in futuro.