4 Tipologia di documenti da conservare

4 Tipologia di documenti da conservare

Lo studio della tipologia dei documenti da conservare è stato praticamente contemporaneo alla scelta dei formati software per rappresentare tali documenti, discussa nel prossimo capitolo.

L’associazione tra documento e formato software è stata spesso obbligata, soprattutto per quanto riguarda i documenti strettamente sanitari: non è ragionevole ovviamente archiviare un documento nato in un formato standard (come ad esempio DICOM7_{) in un formato diverso da quello nativo.}

I documenti che vengono prodotti dall’Istituto di Fisiologia Clinica hanno diverse finalità, come ad esempio documenti amministrativi (richieste di missione, richieste di ferie ecc.), documenti di carattere medico-aministrativo (come ad esempio le impegnative) e documenti di carattere prettamente medico (lettere di dimissione, referti ecc.).

Per poter dare una descrizione comune a diverse tipologie di documenti si è deciso di definire alcuni metadati (ovvero, come verrà spiegato in seguito, unità descrittive di ogni documento - ad esempio “provenienza”) ed attributi (cioè caratteristiche descrittive tipiche di una definita tipologia di documento - ad esempio “codice a barre” per le impegnative).

È stato deciso di creare un sistema dinamico, in grado quindi di poter descrivere diverse tipologie di documenti di volta in volta che questi nuovi documenti afferiscono all’archivio.

Quindi anche per quanto riguarda gli attributi, lo studio si è soffermato sui documenti che, si presume, pervengano in gran numero, almeno nel primo periodo, verso il sistema di archiviazione.

7 _{Il DICOM, discusso nel prossimo capitolo, è un formato software utilizzato nel campo della} diagnostica per immagini per il mantenimento e la descrizione di immagini derivate da ecografie, CT (Computed Tomography) ecc..

Come detto, in ogni caso, il sistema deve essere in grado di gestire, e descrivere, anche tipologie di documenti inizialmente non previste.

4.1 I documenti da conservare

Le possibili diverse tipologie di documenti che si presume possano giungere al sistema di conservazione, si possono dividere in due categorie principali: documenti nati cartacei e poi digitalizzati e documenti prodotti direttamente in formato elettronico.

I documenti cartacei, come i documenti di carattere amministrativo oppure le impegnative (di carattere clinico-amministrativo) prima di afferire al sistema di conservazione devono essere trasposti in formato elettronico. Si suppone quindi che i formati di questi documenti siano, per la maggior parte, i formati tipici prodotti dalle scansioni, ovvero JPEG, TIFF oppure anche PDF. Questi formati non permettono un’elaborazione sui dati o un parsing sulla struttura del documento, di conseguenza è necessario che a corredo dei file pervengano anche attributi descriventi il contenuto di tali documenti. D’altro canto, essendo questi documenti di carattere amministrativo o clinico-amministrativo, non è necessario che abbiano attributi estremamente particolareggiati; infatti su questa tipologia di documenti non andranno fatte ricerche di carattere statistico o epidemiologico.

Anche i documenti prodotti in formato elettronico non elaborabile, hanno le stesse caratteristiche dei documenti nati cartacei e poi digitalizzati, a partire dal formato che di solito è il PDF. Per permettere ricerche sull’archivio in base al contenuto di tali documenti, anche in questo caso è necessario che a corredo di essi pervengano al sistema attributi descriventi i contenuti dei documenti stessi. Il fine dell’archivio è quello di poter conservare documenti, ma se esso permette di accogliere, oltre che documenti, anche attributi descriventi relativi, allora è

possibile effettuare, tramite l’archivio, ricerche di carattere amministrativo o medico.

Per i documenti prodotti in formato digitale elaborabile (ad es. XML o DICOM), invece, non è necessario che abbiano a corredo attributi descrittivi del loro contenuto, visto che questo può essere ricavato in modo automatico o semiautomatico.

I documenti che sono stati presi in considerazione per primi come test per il sistema di conservazione, sono stati l’impegnativa e la lettera di dimissione.

Questi due documenti possiedono infatti caratteristiche speculari: le impegnative, prodotte in formato cartaceo, sono di struttura semplice, molto simile ai documenti amministrativi; le lettere di dimissione invece nascono già in formato digitale (PDF), sono complesse ed elaborate, di difficile caratterizzazione.

Inoltre la digitalizzazione delle impegnative costituisce un passo importante nel processo di dematerializzazione interno all’Istituto. La Regione Toscana richiede che siano inviati al Sistema Sanitario Regionale i dati contenuti nelle impegnative rimborsabili. La Regione altresì obbliga le Aziende Sanitarie a conservare le impegnative per cinque anni come da normativa. Se si pensa che all’Istituto di Fisiologia Clinica pervengono ogni anno decine di migliaia di impegnative, si può pensare a quanto gravosa (anche solamente in termini di spazio) possa essere la conservazione delle impegnative cartacee. Oltretutto, essendo enorme il numero di impegnative conservate, accade che queste non vengano distrutte nemmeno se eliminabili, data la difficoltà a ricercarle. Ciò causa ulteriore sovraffollamento e caos negli archivi.

Le impegnative, però, sono tra i pochi documenti cartacei e a valore legale a poter essere eliminati, non solo dopo cinque anni dalla loro emissione, ma anche se sottoposte al processo di riproduzione digitale8_{. Altri documenti medici}

prodotti in cartaceo, come le cartelle cliniche, essendo soggetti alla giurisdizione

8 _{A tale proposito esiste un precedente: la Regione Lazio ha recentemente avviato un progetto per} la digitalizzazione delle impegnative. In tale progetto le impegnative vengono sottoposte a riproduzione digitale ed immediatamente eliminate. E’ previsto che l’immagine digitale venga conservata per cinque anni in un database.

del Ministero dei Beni Culturali, non possono essere mai eliminati - almeno fino a quando i Ministeri di competenza decidono in tal senso definendo le modalità - nemmeno se trasposti in digitale. Un processo di digitalizzazione di tali documenti quindi non è conveniente poiché non potrebbe eliminare il cartaceo esistente, come invece accade per le impegnative. Per tali documenti “non eliminabili” il processo di dematerializzazione prevede che vengano sviluppate delle procedure informatiche in grado di produrre tali documenti direttamente in formato digitale; in questo modo essi non sarebbero sotto la competenza del Ministero dei Beni Culturali.

Il processo di dematerializzazione delle sole impegnative dunque è di estrema importanza non solo come banco di prova del sistema di conservazione, ma anche per la gestione degli archivi cartacei dell’Istituto.

La lettera di dimissione è stata scelta perché è, ad oggi, uno dei pochi documenti che è possibile firmare digitalmente, perché prodotta in formato elettronico. Nonostante ciò essa viene comunque stampata ed archiviata in formato cartaceo. Una conservazione digitale di questo documento, se effettuata a norma di legge, potrebbe invece consentire (per la prima volta all’interno dell’Istituto) di poter eliminare del tutto la carta in un processo che crea documenti a valore legale.

4.2 Metadati

Come è noto un metadato è un’unità di informazione che descrive un dato (un dato su di un dato). In generale i metadati danno informazioni su determinate caratteristiche degli oggetti cui tali metadati fanno riferimento.

Nel caso specifico, paragonando un documento ad un contenitore recante un contenuto, un metadato di un documento può essere descritto come un’unità di informazione relativa al contenitore; un attributo invece può essere definito come un’unità informativa del contenuto.

I metadati quindi descrivono caratteristiche comuni a tutti i documenti, qualsiasi sia la loro tipologia (ad esempio “provenienza”, “inviante” ecc.).

Non sarebbe appropriato definire caratteristiche proprie solamente di un certo documento o di una tipologia di documenti con metadati.

Nel sistema di archiviazione digitale l’insieme dei metadati che descrive i documenti archiviati deve essere costituito da un insieme di unità informative che danno una descrizione generica dei documenti qualsiasi sia la loro tipologia.

Il problema principale in questa fase di progettazione è stata la scelta dei metadati e degli attributi descrittivi dei documenti.

Uno dei requisiti del sistema di conservazione è che questo si debba interfacciare con più strutture esterne. I metadati e gli attributi descrittivi dei documenti, di conseguenza, devono fare riferimento ad un dizionario condiviso. Per questo motivo si è deciso di selezionare metadati ed attributi, dove possibile, da standard esistenti: in questo modo la sintassi e la semantica di tali metadati sono già ben note e non vi è la necessità di definirle nuovamente.

4.2.1 Alcuni standard

Per la definizione di un insieme consistente di elementi descrittivi dei documenti, come detto, l’idea è stata quella di fare riferimento ad uno standard già esistente, o almeno ad un set di metadati che fosse in qualche modo riconosciuto.

Di seguito viene fatta una rassegna dei più importanti standard che definiscono metadati per la descrizione di documenti.

Dublin Core

Un importante standard che definisce elementi utili a descrivere documenti è il Dublin Core [WWW16].

Nel 1995 la OCLC (Online Computer Libray Center), rete americana di servizi per le biblioteche, sviluppò un’iniziativa per definire un insieme base di elementi descrittivi che potessero rappresentare oggetti generici, non necessariamente di ambito bibliotecario.

L’insieme dei metadati, proposto nel 1996, è costituito da quindici elementi di base (Simple), ai quali nel tempo, si sono aggiunti altri ”sottoelementi” detti

Qualifiers.

Il set di metadati Dublin Core DCMES (Dublin Core Metadata Element Set) è costituito dai metadati:

- Title: nome dato all’elemento; - Creator: autore dell’elemento - Subject: argomento principale;

- Description: spiegazione del contenuto; - Publisher: editore;

- Contributor: co-autore dell’elemento; - Date: data;

- Type: tipologia del contenuto dell’elemento; - Format: formato dell’elemento

- Identifier: identificativo univoco; - Source: riferimento ad un’altra risorsa;

- Language: lingua con cui è espresso il contenuto dell’elemento; - Relation: relazione con un'altra risorsa;

- Coverage: localizzazione dell’elemento - Rigths: diritti associati all’elemento.

Il set di metadati promosso dal Dublin Core è estremamente generico, ovvero ogni metadato può essere interpretato in un modo differente a seconda del contesto in cui viene usato. Il Dublin Core dà delle indicazioni generali su come utilizzare in modo appropriato i metadati che definisce, ma queste indicazioni non sono vincolanti. Esempio lampante è il campo Date: il Dublin Core dà informazioni sul formato da dare alla data (yyyy-mm-gg), ma non è chiaro quale data relativa al documento è opportuno inserire nel dato campo (creazione, ultima modifica ecc.).

Vista anche la natura dei metadati, il campo in cui il Dublin Core ha senza dubbio avuto una discreta popolarità è quello bibliotecario. Recentemente si è pensato di utilizzare il set di metadati Dublin Core anche per dare descrizioni “standard” delle pagine web.

Anche se standard, il Dublin Core è sembrato essere inadatto a descrivere documenti di tipo amministrativo o addirittura medico. Sarebbe stata necessaria un’interpretazione diversa dei metadati a seconda della tipologia dei documenti, e già questo distorce la definizione di “standard”. In compenso però, il set di metadati Dublin Core propone elementi molto generici che possono sicuramente essere utili in qualsiasi contesto.

Cedars

Il progetto Cedars [WWW17] è un’iniziativa promossa da JISC (Joint System Information Commitee) e dal CURL (Consortium of University Research Libraries), cui fanno parte le università di Oxford, Cambridge e Leeds. L’obiettivo del progetto, iniziato nel 1998, era quello di diffondere un set di metadati utili per la conservazione di informazione degli archivi digitali.

L’insieme dei metadati che Cedars ha specificato appare abbastanza differente dal set proposto dal Dublin Core. La diversità più significativa sembra essere la strutturazione dell’insieme dei metadati, che il Dublin Core non esegue. Il Cedars, in qualche modo “inscatola” i metadati descrittivi in strutture più ampie, in modo da definire meglio l’ambito cui tali metadati descrivono.

L’insieme dei metadati specificati dal Cedars è il seguente:

Information Package: l’information Pakage contiene due sottoelementi:

- Preservation Description: questo elemento deve contenere l’informazione che è strettamente necessaria per la corretta conservazione dell’elemento. Elementi all’interno del Preservation Description sono:

- Reference; - Fixity;

- Context Information.

Ognuno di questi elementi contiene altri sottoelementi: ad esempio l’elemento Reference al suo interno ha gli elementi Resource Description e

Existing Metadata. L’insieme finale di elementi che descrivono il documento è molto simile al Dublin Core;

- Content Information: questo elemento deve contenere l’oggetto vero e proprio da conservare. Elementi contenuti all’interno del Content Information sono:

- Representation Information; - Primary Digital Object;

Anche questi due elementi contengono ulteriori sottoelementi, utili per contenere sia la descrizione dell’elemento da archiviare, sia l’elemento vero e proprio come allegato.

Il Cedars, come detto, “impacchetta” i metadati specificati in un strutture più ampie. In questo modo viene ottenuta una certa relazione tra i vari metadati che, quindi, acquisiscono significati più specifici.

Preservation Metadata for Digital Collection

L’istituzione National Library of Australia ha definito un insieme di elementi utili per la conservazione nel lungo periodo di documenti digitali [WWW18]. All’insieme dei metadati definito dalla National Library of Australia fanno riferimento altri studi finalizzati alla definizione di elementi utili per la conservazione di documenti di ambito bibliotecario.

I metadati più significativi previsti in questo studio sono: - Persistent Identifier: identificativo unico dell’elemento; - Date of Creation: data di creazione dell’elemento;

- File Description: formato del documento da conservare. Questo elemento contiene sottoelementi come:

- Image; - Audio; - Video; - Text; - Database; - Executable;

Ognuno di questi elementi contiene informazioni specifiche sulla tipologia: ad esempio l’attributo Image contiene informazioni sulla risoluzione dell’immagine, la compressione applicata ecc..

- Know System Requirements: requisiti necessari per la visualizzazione del file;

- Archiving Decision: informazioni riguardanti l’archiviazione;

In questo caso per ogni elemento possono venire definite informazioni utili alla corretta conservazione ed esibizione dei documenti. Il campo Know System Requirements può contenere indicazioni sui software utili per la visualizzazione del documento digitale archiviato. In Archiving Decision invece, possono essere inserite indicazioni quali la data della possibile eliminazione dell’elemento dall’archivio ecc..

HL7 CDA

Health Level Seven (HL7) è un’associazione internazionale fondata nel 1987 dall’ANSI (American National Standards Institute) che si occupa della gestione e del riconoscimento di standard per la sanità.

Il CDA (Clinical Document Architecture) [DOC17] è uno standard HL7 che specifica la struttura e la semantica di un generico documento clinico. Lo standard è stato sviluppato inizialmente per il sistema sanitario degli Stati Uniti, e nel tempo si è cominciato a diffondere anche nel resto del mondo. Lo sviluppo del CDA ormai coinvolge l'intera comunità internazionale.

Basato su XML, un documento CDA, sviluppato a partire dal RIM (Reference Information Model), consiste in una struttura complessa che al suo interno può contenere immagini, testo, video, contenuti multimediali. Tramite alcuni metadati ben definiti, il CDA è utile per la rappresentazione ed il mantenimento di documenti clinici completi.

Un documento CDA, che comincia sempre con il tag <ClinicalDocument>

è composto da due parti: l’Header ed il Body (figura 4-1).

L’Header contiene informazioni generiche relative al documento, come il suo identificativo, la data di creazione, informazioni sul paziente e sul medico cui il documento è relativo ecc.

Il Body contiene informazioni di carattere clinico che possono essere strutturate o meno. Un Body strutturato contiene le cosiddette Section. Ogni Section può contenere un singolo Narrative Block e altre entry CDA (altri tag) oppure riferimenti esterni. Il Narrative Block, marcato dal tag <text>, contiene informazioni relative alla Section. Queste informazioni non sono processabili in modo automatico, ma sono informazioni leggibili da occhio umano di integrazione al documento (ed in particolare alla Section di cui fanno parte).

Le altre entry CDA invece contengono informazioni strutturate e processabili in modo automatico.

figura 4-1: componenti principali di un documento CDA (tratto da figure 1 di [DOC17])

- id: attributo che identifica in modo univoco il documento;

- code: codice che identifica la tipologia di documento (referto, lettera di dimissione ecc.); i codici sono ripresi dallo standard LOINC;

- effectiveTime: data e ora di creazione del documento; - confidentialityCode: info su riservatezza del documento; - languageCode: lingua in cui è espresso il documento;

- partecipants: attributo che contiene informazioni sulle persone legate in qualche modo al documento. Questo attributo contiene diversi sottoelementi: - author; - encounterPartecipant; - legalAutenticator; - performer; - patientRole.

Nel campo patientRole vengono specificate informazioni relative al paziente, ad esempio pastClinicalHistory, attributo che definisce la storia clinica del paziente.

Il Body come detto è strutturato in sezioni. Una sezione contiene: - id: identificativo della sezione;

- code: tipo di sezione (argomento, ad es. allergie); - title: titolo della sezione;

- text: Narrative Block, specificato precedentemente; - author: autore della sezione;

- observation; - procedure;

Gli ultimi due campi sono utili per una elaborazione automatica di parte delle informazione contenute nel Narrative Block, come si può vedere dalla figura 4-2. Tali campi sono ben strutturati e le informazioni possono essere ricavate in automatico.

figura 4-2: esempio di una Section (tratto da figure 4 di [DOC17])

Il CDA è stato un utile esempio soprattutto nello studio dei metadati necessari per un’archiviazione efficace di documenti sanitari.

4.2.2 Metadati selezionati

Tenendo presente il fine principale di un sistema di archiviazione, che è quello di conservare, appunto, documenti “originali” per un lungo periodo di tempo, sono stati selezionati alcuni metadati utili per una ricerca dei documenti nel sistema.

Questo insieme di metadati non descrive le informazioni presenti nel documento da archiviare, ma permette di inquadrare la tipologia del documento, la sua posizione nel sistema ed altre informazioni contingenti, che possono essere utili per una corretta conservazione.

I metadati, a differenza degli attributi, descritti nel prossimo paragrafo, possono essere ricavati in modo automatico al momento della ricezione del documento nel sistema. Infatti essi possono dipendere da condizioni oggettive durante l’invio del documento, come ad esempio la data, ma possono essere anche derivati in modo esplicito dal documento (ad esempio il formato).

Alcuni dei metadati selezionati sono ripresi esattamente dal CDA ed in tal caso, come già detto, la semantica del metadato è la stessa che viene specificata dallo standard. Inoltre la sintassi con cui vanno indicati i valori di tali metadati è già ben definita dal CDA stesso.

I metadati comuni identificati sono:

Metadato Riferimento CDA Significato

identificativo documento

ClinicalDocument .id

Identificativo univoco del documento nel sistema. Assegnato al documento al momento del suo arrivo nel sistema. identificativo inviante ClinicalDocument .partecipants .author

L’utente che ha inviato il documento nel sistema.

diritti documento

ClinicalDocument .ConfidentialityCode

Diritti di visualizzazione del documento.

fascicolo ClinicalDocument. ParentCode

Identificativo che permette di correlare insieme più file che fanno parte dello stesso documento.

tipologia documento

Tipo di documento. Fornito al momento dell’invio del documento.

provenienza Struttura di provenienza del

documento (correlato all’inviante)

formato Formato del documento inviato.

Può essere ricavato in automatico dal sistema. versione

formato

Versione del formato con cui è codificato il documento. Può essere ricavato in automatico dal sistema.

data

acquisizione

Data di arrivo del documento nel sistema. Ricavato in

automatico dal sistema. data

archiviazione

Data di archiviazione del

documento nel sistema. Ricavato in automatico.

data ultimo accesso

Data ultimo accesso del documento. Ricavato in automatico

posizione documento

Posizione (path) dove è memorizzato il documento.

L’”identificativo documento” ha lo stesso significato di ClinicalDocument.id del CDA e permette di poter identificare i documenti in modo univoco nel sistema.

L’“identificativo inviante” indica l’utente che ha inviato il documento e, legato a questo, è l’attributo “provenienza” (infatti si suppone che un utente appartenga ad una qualche organizzazione, come un’azienda sanitaria ecc.).

Il metadato “diritti associati” permette di poter dare dei diritti di visualizzazione al documento, a seconda della provenienza da cui tali documenti provengono. Sono le organizzazione afferenti al sistema, cioè, secondo schemi predisposti e concordati, a dover specificare i diritti propri dei documenti. Anche questo attributo è definito nel CDA come confidentialityCode.

Il metadato “fascicolo” è un identificativo che permette di poter correlare insieme più file relativi allo stesso documento (un fascicolo appunto). Questo metadato ha lo stesso significato di ParentDocument, presente nel CDA.

I metadati “tipologia documento” e “formato documento” sono utili per poter stabilire il tipo di documento ed il formato con cui è espresso. È importante poter conservare, oltre che i documenti, anche i software utili per leggerli, quindi i metadati “formato documento” e “versione formato” sono opportuni per stabilire quali formati sono presenti nell’archivio e, conseguentemente quali software dover mantenere per la lettura di tali formati. Di conseguenza questi attributi permettono inoltre di stabilire se è necessario un riversamento sostitutivo, nel caso in cui il formato (o la versione utilizzata) sia obsoleto.

Il metadato “data acquisizione” permette di stabilire da quanto tempo il documento è arrivato al sistema (non da quando il documento è conservato). La

legge infatti non impone l’archiviazione nel sistema di conservazione di un documento immediatamente dopo che questo è arrivato al sistema, ma anzi, non fornisce alcun vincolo temporale. In generale, non dovrebbe passare comunque più del tempo del necessario per la costituzione di un volume di documenti.

La “data archiviazione” invece consente di stabilire la data esatta della conservazione “ufficiale” a norma. Conoscendo l’attributo “periodo conservazione”, proprio di ogni tipologia di documento, e che dà un’indicazione sul periodo di mantenimento di quella tipologia di documento, allora è possibile stabilire quando tale documento va eliminato. Metadati simili sono dichiarati anche nel formato DICOM, discusso nel prossimo capitolo.

La “data ultimo accesso” è utile per stabilire una politica di mantenimento “online” dei documenti (gli stati “online”, “nearline” e “offline” dei documenti sono trattati nel settimo capitolo).

Il metadato “provenienza” può essere composto da due sottoelementi: uno che indica la struttura da cui proviene il documento, l’altro che indica il reparto o l’ufficio.

Il metadato “posizione” indica la posizione cui il documento è memorizzato. La modalità di strutturazione di questo attributo è discussa nel prossimo capitolo.

4.3 Attributi

Come già detto, il sistema di archiviazione digitale ha lo scopo di archiviare e mantenere in modo legalmente valido documenti di vario genere, ma principalmente documenti di carattere amministrativo e medico sanitario. Il fine è quello di avere documentazione valida in formato elettronico anziché cartaceo, che possa essere ricercata in modo semplice e veloce e se necessario esibita. I documenti che vengono conservati sono da considerarsi degli originali.

Altre ricerche di carattere medico scientifico o statistico possono essere effettuate sul sistema nel caso in cui i documenti siano codificati in formati che consentano un parsing automatico della loro struttura (es. documenti XML).

Come detto nel capitolo precedente, i documenti che, almeno nel primo periodo afferiranno al sistema di conservazione, principalmente non avranno tali formati autodescrittivi, per cui su tali documenti sarà impossibile effettuare un parsing.

Se però, a corredo di quei documenti, venissero inviate alcune informazioni strutturate riguardanti i dati che tali documenti possiedono, allora anche in quel caso sul sistema sarebbe possibile effettuare ricerche più complicate di carattere medico scientifico o statistico.

È utile comunque specificare un’altra volta che anche in quel caso solamente i documenti originali avrebbero validità legale, non i dati inviati al loro corredo.

Per poter dare al sistema di conservazione questa ulteriore importante funzionalità, allora è necessario, per ogni tipologia di documenti, definire un set di attributi che possano descrivere al meglio ogni caratteristica di tali tipologie.

Come spiegato nel precedente paragrafo, per la scelta dei metadati è stato deciso di fare riferimento al set definito nel CDA. In questo modo i metadati che devono essere inviati al sistema di conservazione a corredo dei documenti (se questi non sono espressi in formati elaborabili automaticamente) derivano in qualche modo da modelli utilizzati in medicina e sono quindi adatti per descrivere al meglio tali documenti sanitari. Oltretutto la sintassi e la semantica di tali metadati è già ben definita.

Anche per la definizione degli attributi descriventi le varie tipologie dei documenti si è cercato di fare riferimento a metadati CDA già definiti.

Come detto nei capitoli precedenti, uno dei requisiti richiesti su sistema di conservazione era relativo alla possibilità di accogliere anche tipologie di documenti inizialmente non previste inizialmente. Ogni volta che una nuova tipologia di documento si “affaccia” al sistema di archiviazione, quindi, è necessario che vengano definiti nuovi attributi utili alla descrizione della nuova

tipologia. Il database deve progettato in modo tale da poter possedere questa elasticità, ovvero nel database devono poter essere definiti nuovi attributi non previsti inizialmente utili per descrivere nuove tipologie di documenti, senza dover stravolgere o modificare la struttura del database.

Di seguito vengono descritti gli attributi selezionati per due tipologie di documenti.

4.3.1 Impegnativa: attributi

L’impegnativa è un documento dalla struttura piuttosto semplice e ben definito (figura 4-3), per cui selezionare gli attributi che possono descrivere tale documento non è stato complicato.

figura 4-3: impegnativa

Le informazioni necessarie ad una corretta caratterizzazione di un’impegnativa sono:

Metadato Riferimento CDA Significato cognome e nome

paziente

ClinicalDocument. PazientRole

Cognome e nome del paziente cui è riferita l’impegnativa. cognome e nome medico prescrivente ClinicalDocument. partecipants. author

Cognome e nome del medico che effettua la prescrizione prescrizione Substance Administration Class La prescrizione, oggetto dell’impegnativa. data ClinicalDocument. EffectiveTime Data di emissione dell’impegnativa. numero codice a barre ClinicalDocument. Id

Codice a barre dell’impegnativa.

codice fiscale paziente

Codice fiscale del paziente.

Il “numero codice a barre” dell’impegnativa è composto da 15 caratteri che identificano in modo univoco sia l’impegnativa, sia il medico che l’ha emessa. L’attributo è identificabile con ClinicalDocument.id del CDA.

Il “cognome e nome del paziente” ed il relativo codice a barre sono necessari se si vogliono effettuare nell’archivio ricerche in base al paziente. Sostanzialmente questo attributo ha lo stesso significato dell’attributo PatientRole del CDA.

Il “cognome e nome del medico” non sarebbero necessari, visto che comunque il medico è univocamente identificato dal codice a barre, ma può essere comodo comunque averli. In questo caso il significato del metadato è assimilabile all’Author del CDA.

La “prescrizione” e la “data” sono altri due attributi che caratterizzano fortemente l’impegnativa. È possibile equiparare il significato dell’attributo descrizione alla Substance Administration Class del CDA. Questo attributo specifica, in maniera esauriente, le caratteristiche di una prescrizione indicata ad

un paziente. Questo attributo si suddivide nel CDA in: Labeled Drug, Material, Manufactured Product. L’attributo Labeled Drug contiene l’informazione Dose Quantity, che indica la quantità di farmaco da somministrare. L’attributo data è paragonabile al ClinicalDocument.effectiveTime del CDA.

Ulteriore attributo da inserire è “periodo conservazione documento” che dà un’indicazione sul periodo di mantenimento di quella tipologia di documento: l’impegnativa deve essere conservata per cinque anni.

È ipotizzabile che le impegnative ancora per anni saranno prodotte solamente in formato cartaceo. Il sistema di conservazione prevede che i documenti prodotti in cartaceo siano trasposti in formato digitale ancora prima di afferire al sistema, per cui il compito della “riproduzione digitale” deve essere affrontato a monte del sistema.

Una considerazione sulle modalità di scansione dei documenti cartacei per la loro riproduzione digitale è utile comunque farla.

Per i documenti cartacei che necessitano di una scansione il problema principale, più che il formato da far adottare al documento digitale, riguarda la qualità della scansione stessa. In particolare non esiste nessuna norma che fa riferimento alla risoluzione in dpi da adottare per la scansione. Nemmeno in letteratura esistono riferimenti a questi problemi.

La Regione Lazio, che ha costituito un sistema per la conservazione a norma di impegnative mediche, adotta una scansione di 200 dpi, senza però dare una motivazione per questo.

Il problema riguarda soprattutto i documenti che possiedono una firma autografa. Ovviamente un documento digitale perde la tridimensionalità rispetto allo stesso documento in formato cartaceo, e questo può costituire un problema per quanto riguarda una possibile perizia calligrafica. Una bassa risoluzione della scansione su una firma può rendere inutile una qualsiasi perizia sul documento digitale.

Non è chiaro però se risoluzioni più definite di 200 dpi possano aiutare eventuali perizie calligrafiche sul documento digitale9_.

Per le impegnative mediche comunque una risoluzione di 500 dpi rappresenta un limite poiché paradossalmente una risoluzione maggiore peggiora la qualità dell’immagine in uscita. Questo è causato dalla qualità della carta delle impegnative, che risulta essere molto poco spessa. Una risoluzione più alta di 500 dpi evidenzia in modo marcato anche il retro della facciata dell’impegnativa su cui è effettuata la scansione, e questo pregiudica la qualità dell’immagine ottenuta.

La Regione Lazio probabilmente effettua scansioni a 200 dpi perché questa risoluzione rappresenta un buon compromesso tra qualità dell’immagine ottenuta e dimensione del file.

4.3.2 Lettera di dimissione: attributi

Come detto, la lettera di dimissioni è un documento che già oggi viene prodotto in formato digitale (PDF).

Gli attributi che sono stati previsti per questo tipo di documento sono i seguenti:

Metadato Riferimento CDA Significato

codice documento

ClinicalDocument. id

Identificatore univoco della lettera di dimissione.

data ClinicalDocument.

effectiveTime

Data emissione documento

cognome e

nome paziente

ClinicalDocument. PatientRole

Cognome e nome del paziente cui è riferita la lettera di dimissione.

cognome e nome medico prescrivente ClinicalDocument. partecipants. Author

Cognome e nome del medico che compila la lettera di dimissione.

anamnesi ClinicalDocument. Caratteristiche riscontrate nello

9 _{Indicazioni precise su questo aspetto potrebbero essere fornite da un perito calligrafo o da un} giurista.

PastClinicalHistory studio anamnestico. esame obiettivo Observation Class

Code

Condizioni del paziente al momento del ricovero

dati bioumorali Observation Class Code

Esami bioumorali effettuati durante il ricovero.

dati strumentali Observation Class Code

Esami strumentali effettuati durante il ricovero

terapia medica Substance

Administration Class

La prescrizione, oggetto dell’impegnativa.

Il “codice documento” identifica la lettera di dimissione in modo univoco. Tale codice può essere costituito da numeri e caratteri e, come già detto ha lo stesso significato di ClinicalDocument.id.

Il “cognome e nome” del paziente e del medico facilitano un’eventuale ricerca della lettera di dimissione. Anche questi attributi sono, come per l’impegnativa, ripresi dal CDA.

L’attributo “anamnesi” sostanzialmente deve contenere le caratteristiche osservate dal medico durante lo studio di anamnesi, appunto, che viene effettuato al momento del ricovero (e che, come si osserva dalla figura 4-4, sono contenute nel paragrafo “Sintesi anamnestica” della lettera di dimissione). L’attributo di riferimento in questo caso è il Past Medical History del CDA.

L’attributo “esame obiettivo” indica le condizioni del paziente riscontrate al momento del ricovero e che sono contenute nel paragrafo “Esame obiettivo” della lettera di dimissione. Gli attributi “dati bioumorali” e “dati strumentali” riportano esami che sono stati effettuati sul paziente durante il ricovero.

A seconda del valore che questi attributi possono ottenere, è possibile che il loro significato sia paragonabile ad attributi simili strutturati in Section ed Observation Class Code nel CDA.

Il campo “terapia medica”, come per l’attributo “prescrizione” dell’impegnativa è ripreso dell’attributo Substance Administration Class del CDA.

figura 4-4: lettera di dimissione

È probabile che la lettera di dimissione tra qualche tempo passi dal formato PDF al formato XML. Infatti già oggi questo documento in parte viene prodotto in modo automatico, soprattutto per quanto riguarda la parte relativa agli “esami bioumorali” ed “esami strumentali”: tali informazioni provengono da una base di dati nella quale vengono inseriti i risultati degli esami effettuati sui pazienti.

A quel momento nell’archivio andrebbe conservata comunque una versione PDF del documento (la stessa versione consegnata al paziente, perché originale), ma in allegato, potrebbe pervenire al sistema anche la versione XML: in questo modo si potrebbero inserire tutte le informazioni in essa contenuta sul database, senza dover richiedere esplicitamente gli attributi.

4.4 Conclusioni

Il CDA propone una sorta di architettura di un generico documento clinico, stabilendo gli attributi necessari per definire nel modo migliore ed in maniera elaborabile le informazioni presenti in tale documento.

Come già detto i metadati e gli attributi sono stati ideati facendo riferimento all’insieme definito dal CDA con relativa sintassi e semantica. Quando non è stato possibile fare un esplicito riferimento, allora sono stati definiti ex-novo metadati ed attributi specifici.

È da notare che i metadati selezionati sono abbastanza generici ma, nonostante ciò, da soli permettono di descrivere, ricercare e attuare politiche di conservazione dei documenti nel sistema. Per i documenti espressi in formati non elaborabili automaticamente è necessario che, a corredo dei metadati vengano definiti attributi che descrivano il contenuto di tali documenti. In questo modo possono essere effettuate ricerche di carattere statistico o medico clinico sul sistema di conservazione.

Gli attributi definiti per l’impegnativa e per la lettera di dimissioni rappresentano il set minimo di attributi che deve pervenire al sistema per quelle determinate tipologie di documento. Nulla vieta però, di poter inviare al sistema ulteriori attributi descrittivi di tali documenti, purché siano definiti nel set CDA.