Clinical Document Architecture (CDA)

Clinical Document Architecture è uno standard che specifica la struttura e la semantica di documenti clinici per lo scambio all’interno del dominio sanitario. Un documento CDA è un oggetto informativo strutturato in grado di contenere testi, immagini, suoni ed altri contenuti multimediali. Esso è composto da differenti blocchi informativi che veicolano informazioni relative

al paziente, al medico, alla struttura sanitaria, all’autore del documento, al firmatario del documento, agli eventi clinici, alle osservazioni o alle procedure mediche a cui il documento si riferisce. Ogni documento deve essere, come prescrive lo standard stesso, “human readable” e quindi in grado di essere visualizzato in maniera algoritmica dal ricevente del documento senza la necessità di conoscerne le specificità. Da un punto di vista tecnico, la struttura dei documenti CDA, deriva in modo formale dal Reference Information Model (RIM) di HL7 versione 3 e ne utilizza, quindi, i relativi datatype.

L’utilizzo formale del RIM di HL7v3 garantisce la flessibilità necessaria anche in relazione alle future evoluzioni dello standard fornendo un modello per l’implementazione di documenti strutturati. Lo standard CDA si presta alla rappresentazione di diverse tipologie di documenti clinici fornendo peraltro un elevato grado di flessibilità nelle modalità di rappresentazione di concetti. In tale contesto è quindi necessario, anche in funzione delle specificità del paese nella gestione delle informazioni e processi sanitari, adattare lo standard in relazione ai singoli oggetti informativi che si vuole rappresentare (ad es.: prescrizione farmaceutica, prescrizione specialistica, referto, lettera di dimissione,…) fornendo per ciascuno di questi il dettaglio relativo alla modalità di rappresentazione in CDA dei concetti, delle informazioni e delle codifiche in essi contenute. Lo standard HL7-CDA Rel. 2.0 fornisce in tale ambito delle specifiche norme che tale processo di adattamento deve ad ogni modo seguire (HL7 Refinement and Localization) per garantire, durante il processo di localizzazione della specifica (definizione dei vocabolari, codifiche, estensioni), la completa conformità allo standard. Un documento CDA viene trasmesso all'interno di un messaggio HL7 definito per trasferire documenti clinici, tuttavia la specificazione del linguaggio adottato per questi messaggi è al di fuori degli scopi di CDA.

Un documento clinico contiene osservazioni e descrizioni di servizi, e deve possedere le seguenti caratteristiche:

-PERSISTENZA: il documento clinico deve continuare ad esistere inalterato per un determinato periodo definito dai regolamenti locali.

-AMMINISTRAZIONE: il documento clinico è conservato da un organizzazione specifica che ne è responsabile.

-AUTENTICAZIONE: il documento clinico è un assemblaggio di informazioni che devono essere legalmente autenticate.

-CONTESTO: il documento clinico stabilisce il contesto di default per il suo contenuto. -INTEREZZA: l'autenticazione del documento clinico si applica all'intero documento e non si applica a porzioni del documento senza il contesto completo del documento.

-LEGGIBILITA' UMANA: Il documento clinico deve essere comprensibile alla lettura umana.

Un documento CDA non specifica la creazione o la gestione dei documenti, ma solamente la marcatura per lo scambio del documento tra entità diverse garantendone l'interoperabilità.

Gli obbiettivi di un documento CDA sono:

-dare la priorità al processo di cura del paziente

-supportare lo scambio di documenti leggibili tra persone anche con diversi livelli di conoscenza tecnica

-promuovere il mantenimento nel tempo di tutte le informazioni codificate

-abilitare un vasto range di applicazioni che processano i documenti dopo lo scambio. -compatibilità con un vasto numero di applicazioni che creano documenti

-realizzare il progetto in tempi ragionevolmente veloci

-permettere un controllo dei requisiti delle informazioni contenute da parte degli enti specifici incaricati

Da questi obbiettivi segue un certo numero di principi di progettazione del linguaggio:

-l'architettura deve essere compatibile con XML e HL7 RIM -le barriere all'utilizzo dell'architettura devono essere minime

-l'architettura specifica lo gli schemi necessari per effettuare lo scambio di documenti

-l'architettura deve richiedere il minimo numero di regole e requisiti sulla struttura del documento e sui contenuti necessari per garantire lo scambio

-l'architettura deve essere scalabile per favorire markup molto dettagliati

-il documento prodotto deve poter alloggiare informazioni e requisiti necessari a vari aspetti: professionale, commerciale e normativo

-il documento, per essere leggibile da soggetti umani, deve essere compatibile con i browser XML comunemente adottati e con i comuni drivers di stampa.

6.2.1 Componenti di un documento CDA

Le componenti principali di un documento CDA sono mostrate di seguito:

<ClinicalDocument> ... CDA Header ... <StructuredBody> <section> <text>...</text> <Observation>...</Observation> <Observation> <reference> <ExternalObservation>...</ExternalObservati on> </reference> </Observation> </section> <section> <section>...</section> </section> </StructuredBody> </ClinicalDocument>

Un documento CDA è racchiuso all'interno di due elementi <Clinical Document> e contiene un header ed un body. L'header si sviluppa dall'elemento <Clinical Document> all'elemento <Structured Body> dove viene classificato e identificato il documento stesso, oltre a fornire informazioni relative all'autenticazione, al paziente, ai provider del servizio e all'incontro tra paziente e provider. Il body invece contiene la relazione dell'episodio clinico descritto nel documento. Il body può essere in forma non strutturata o strutturato mediante un linguaggio di markup, in quest'ultimo caso il body deve essere contenuto all'interno di due elementi <Structured Body> e può essere suddiviso in sezioni che sono sistemabili in modo ricorsivo. Ogniuna di queste sezioni è racchiusa tra due elementi <Section> e può contenere un singolo blocco narrativo (Section Narrative Block) ed un qualsiasi numero di accessi (Entry Acts) e di riferimenti esterni. Il narrative block è racchiuso all'interno di due elementi <text> posti all'interno del medesimo blocco section, e costituisce uno slot per le informazioni leggibili che devono essere mostrate. Sempre all'intterno di una section del body sono contenute le eventuali entries, che costituiscono invece la parte strutturata dei dati il cui contenuto è quindi machine-readable. Anche i riferimenti esterni concorrono all'interno del contesto delle CDA entries, e sono

racchiusi tra due elementi <reference>. Questi riferimenti devono puntare ad oggetti che esistono al di fuori del documento CDA, come per esempio immagini, suoni, video o altri documenti. La CDA entry che racchiude il riferimento ad un oggetto esterno può essere utilizzata per codificare una specifica porzione del riferimento esterno che è indirizzata nel narrative block.

6.2.2 Leggibilità umana e rendering dei documenti CDA

La necessità di un documento CDA di essere leggibile garantisce al destinatario di un documento CDA che possa, attraverso un approccio algoritmico, mostrare il contenuto clinico all'interno di un browser standard per il web.

Per garantire questa potenzialità ci sono delle necessità che influenzano la struttura del linguaggio CDA:

-deve esistere un modo deterministico per un recipient di un documento CDA per visualizzare il contenuto del documento stesso

-la leggibilità non comporta la necessità di trasmettere uno specifico style-sheet. Deve essere quindi possibile visualizzare tutti i documenti CDA con un unico style-sheet e con un applicativi generici per la presentazione del contenuto

-la leggibilità deve valere per il contenuto autenticato del documento, ci possono dunque essere delle informazioni addizionali espressamente dedicate al machine-processing, che non sono autenticate e quindi non è necessario visualizzarle.

-quando del contenuto strutturato viene derivato dal contenuto narrativo devono essere espressamente definiti i meccanismi tramite i quali avviene questa derivazione.

-quando la porzione narrativa è derivata dal contenuto strutturato deve essere identificato il processo che porta a questa derivazione.

Queste necessità hanno comportato lo sviluppo attuale del linguaggio CDA, per il quale il materiale che deve essere visualizzato è posizionato all'interno del campo Section.text. Il contenuto di questo campo è specificatamente aggiunto a mano dall'operatore che realizza il documento. Le osservazioni strutturate possono riferirsi al contenuto del campo Section.text.

6.2.3 CDA e HL7 Messaging Standards

Un documento CDA è oggetto di informazione definito e completo, il quale esiste anche al di fuori del contesto di messaggi tra partner di un Workflow, oppure può essere codificato all'interno di un

messaggio HL7. Di conseguenza CDA integra le specifiche della messaggistica HL7.

Dal punto di vista di HL7 V2 o V3 message un documento CDA è un oggetto multimediale che può essere scambiato come un pacchetto Multipurpose Internet Mail Extensions (MIME, RFC 2046) codificato come un tipo di dato incapsulato. Ogni strategia per lo scambio di documenti CDA deve soddisfa le seguenti specifiche:

-non esiste la necessità di cambiare i riferimenti interni al documento CDA quando viene creato il pacchetto di scambio

-non esiste la necessità di cambiare i riferimenti interni al documento CDA quando viene aperto il pacchetto di scambio

-tutte le componenti del documento CDA che sono parte integrante del documento (come per esempio un body non strutturato secondo linguaggio XML) sono incluse nel medesimo pacchetto.

-non ci sono restrizioni sulla struttura del pacchetto dei riceventi, e possono posizionare le componenti del documento CDA in cartelle a loro scelta.

In HL7 V3 i documenti CDA possono essere scambiati all'interno di ogni messaggio che permette lo scambio di documenti (per esempio HL7 V3 Medical Records Messages). L'attributo Act.text contiene il pacchetto MIME, codificato come un tipo di dato incapsulato. Dato che HL7 V3 Medical Records Messages e CDA derivano da un modello comune, molti campi all'interno del messaggio si sovrappongono in significato con i campi del documento CDA. La seguente tabella mostra le corrispondenze tra questi campi:

HL7 V3 Medical Records Component CDA Component

ClinicalDocument ClinicalDocument authenticator authenticator legalAuthenticator legalAuthenticator dataEnterer dataEnterer encounterPerformer encounterPerformer responsibleParty responsibleParty

HL7 V3 Medical Records Component CDA Component custodian custodian participant participant informationRecipient informationRecipient recordTarget recordTarget author author subject subject

relatedDocument / ParentDocument relatedDocument / ParentDocument

documentationOf / Event documentationOf / Event

inFulfillmentOf / Order inFulfillmentOf / Order

Un documento clinico può essere rivisto ed aggiornato, e può essere aggiunto ad un documento già esistente. Idealmente, un documento aggiornato dovrebbe auto-dichiararsi obsoleto, e contenere automaticamente un puntatore verso la più recente versione del documento stesso. Questo dovrebbe permettere ai provider della sanità di basare le proprie scelte medico-diagnostiche su dati completi ed aggiornati. In pratica, tuttavia, è impossibile garantire un esplicito puntatore in avanti verso la nuova versione del documento. Senza un processo che tracci la catena di custodi dei documenti clinici e delle loro copie, non esiste la possibilità di garantire che un documento clinico che viene visualizzato non sia stato successivamente revisionato e corretto con una nuova versione.

Per minimizzare dunque il rischio di visualizzare informazioni obsolete, esiste una critica interdipendenza tra documenti clinici e i sistemi di gestione dei documenti. Se un documento viene visualizzato all'esterno del contesto del sistema di gestione dei documenti, non è possibile conoscere con certezza l'attendibilità dei dati contenuti nel documento stesso. I messaggi HL7 che gestiscono l'invio di documenti CDA garantiscono una corretta visualizzazione delle informazioni cliniche.

6.2.4 Conformità del documento CDA

campi che appartengano alla lista dei vocaboli codificati all'interno del vocabolario del dominio specificato. Tuttavia la maggior parte delle caratteristiche del linguaggio CDA non possono essere validate a livello macchina, in particolare i requisiti correlati alla leggibilità umana del documento. Documenti CDA possono essere prodotti da un applicazione (che prende il nome di Document Originator), o ottenuti tramite una conversione da altri formati come un output diretto di un applicazione autorizzata. Questo Document originator è spesso responsabile sia della comunicazione con l'attore responsabile della memorizzazione persistente del documento attraverso l'utilizzo di messaggistica HL7, sia della conformità del documento con la sua specificazione.

Un document recipient è un'applicazione che riceve aggiornamenti di stato e documenti prodotti dai document originator ed è responsabile di garantire che il documento CDA sia conforme alle specifiche. Il formato CDA è uno standar progettato per lo scambio di documenti, di conseguenza non esistono dei particolari requisiti per la memorizzazione persistente. Tuttavia la gestione documentale è fondamentale anche per la specifica del linguaggio CDA. L'attore responsabile della memorizzazione permanente del documento (che può dunque avvenire anche sotto forma di un altro formato) è il custodian ed è definito all'interno dell'Header del CDA.

Le responsabilità del recipient:

-Assegnare i valori di default (dove definiti) per le istanze per le quali non è stato specificato un valore

-Analizzare i blocchi dell'header e interpretarne il significato.

-Analizare i blocchi del body e interpretare il significato in modo sufficienter tale da poterlo visualizzare (non tutte le entries devono essere interpretate).

Le responsabilità dell'originator:

-Deve garantire che la porzione del body sia strutturata in modo tale che il recipient possa interpretarne il significato