Lo scopo dell'header è quello di permettere lo scambio dei documenti clinici all'interno e tra le varie istituzioni coinvolte nel processo clinico, facilitando la gestione documentale e la compilazione dei documenti clinici all'interno del ciclo di vita elettronico dell'archivio del paziente.La classe Clinical Document è il punto di inizio del documento CDA, e corrisponde all'elemento XML <ClinicalDocument> che è l'elemento root del CDA stesso.
La classe ClinicalDocument definisce vari attributi che corrispondono all'infrasctructureRoot del RIM (per esempio tipeId e templateId). In particolare se ClinicalDocument.templateId viene valorizzato all'interno di un istanza, questo segnala l'imposizione di un set di vincoli per la template del documento, caratterizzandola con un identificatore univoco.
L'attributo ClinicalDocument.typeId è un riferimento esplicito e tecnologicamente neutro al documento CDA, e deve essere valorizzato in questo modo:
-ClinicalDocument.typeId.Root=“2.16.840.1.113883.1.3” (rappresenta l'OID dei modelli registrati HL7)
-ClicalDocument.typeId.Extension=”POCD_HD000040” (identificatore univoco per il CDA R.2 Hierarchical Definition)
-ClinicalDocument.id: identificatore univoco per l'istanza del documento clinico
-ClinicalDocument.code: specifica il particolare tipo di documento, e preferibilmente il
valore deve essere derivato da LOINC.
-ClinicalDocument.title: rappresenta il titolo del documento. Deve essere usato nel caso in
cui al documento è associato uno specifico e unico nome oppure se deve essere visualizzato dal clinico. Nel caso in cui non venga specificato viene referenziato il valore del ClinicalDocument.code.
-ClinicalDocument.effectiveTime: raapresenta la data e l'ora in cui il documento è stato creato.
-ClinicalDocument.confidentialityCode: è un informazione contestuale dell'intero documento CDA, a meno che non venga sovrascritto da un valore annidato nel documento (in particolare nella sezione Context). Indica il livello di riservatezza del documento e può assumere tre valori:
N=normal (default): regole di riservatezza convenzionali associate alla pratica
medica, e solo gli individui autorizzati per scopi medici o di lavoro possono accedere al documento (codeSystem 2.16.840.1.113883.5.25 )
R=restricted: possono accedere al documento solo i providers che sono attualmente
concorrenti n el processo di cura(codeSystem 2.16.840.1.113883.5.25)
V=very restricted: (codeSystem 2.16.840.1.113883.5.25) accesso molto limitato
come dichiarato dalle politiche di privacy definite dallo specifico provider del servizio medico.
-ClinicalDocument.languageCode: specifica la lingua umana in cui è redatto il documento.
Il valore dell'attributo è un identificatore della lingua, definito da IETF (Internet Engineering Task Force) RFC 3096 for Identification of languages, ed. H. Alvestrand (1995). Anche la l ingua è una caratteristica contestuale dell'intero documento, a meno che il campo non venga sovrascritto nella sezione annidata Context.
-ClinicalDocument.setId: rappresenta un identificatore che è comune tra tutte le
diverse versioni e revisioni del documento.
-ClinicalDocument.versionNumber: valore intero che identifica la versione successiva del
documento.
La sezione Partecipants dell'header descrive le classi correlate al evento clinico mediante la partecipazione allo stesso. I vari ruoli possono essere occupati dalla stessa persona fisica o da persone diverse.
documento, ma che non ha la prerogativa di poter attestare questa conformità autenticando legalmente il documento. Ogni documento può avere da uno a molti autenticatori e ad ogni autenticatore è associato un authentication.time.
-Author: classe che rappresenta l'attore, umano o macchina, autore del documento. A volte il ruolo o la funzione dell'autore è indicata nel campo ClinicalDocument.code. In altri casi la specifica del campo ClinicalDocument.code è ripresa o specializzata all'interno del campo author.functionCode o nell'attributo assignedEntity.code, per questo motivo non deve esistere conflitto tra i valori attribuiti a questi campi.
-Custodian: individua l'organizzazione che ha il compito di mantenere lo stato di integrità
del documento, preservando le informazioni in esso contenute
-dataEnterer (transcriptionist): rappresenta il partecipante che ha trasformato una nota
dettata in un testo.
-informant (source of information): rappresenta le entità che apportano rilevanti
informazioni inerenti al caso clinico
-informationRecipient: rappresenta il recipiente che andrà a ricevere una copia del documento. Questo partecipante è l'entità a cui è destinato il documento nel momento in cui viene redatto il documento stesso, e non rappresenta l'insieme delle persone che avranno poi la possibilità di accedere allo stesso. Questa lista non può essere contenuta all'interno del documento CDA ed esula dagli scopi di CDA.
-legalAuthenticator: rappresenta il partecipante che ha legalmente autenticato il
documento. Un documento CDA può esistere in uno stato non autenticato, autenticato o legalmente autenticato. Entrambe le autenticazioni richiedono che il documento venga firmato manualmente o digitalmente.
-participant: è utilizzato per rappresentare altri partecipanti non esplicitamente menzionati
nelle altre classi, e che sono comunque coinvolti negli atti documentati.
-recordTarget: rappresenta la cartella clinica a cui appartiene il documento. In genere un
documento appartiene ad un'unica cartella, in caso contrario è necessario definire più recordTarget partecipants.
-guardian: è una persona o un'organizzazione che svolge il ruolo di tutore nei confronti del
paziente. Questo partecipante prende le decisioni cliniche che riguardano il paziente nel caso in cui quest'ultimo non ne sia in grado. Se non è esplicitamente definito il paziente prende da solo le proprie decisioni mediche.
-responsibleParty: rappresenta un soggetto che ha una responsabilità legale primaria per gli
stessa attraverso il potere di delega e l'obbligo di rivedere le decisioni insieme ai partecipanti attivi. Si tratta di un soggetto diverso dal legalAuthenticator, in quanto quest'ultimo può o meno essere anche il responsibleParty, ma l'autenticatore svolge un ruolo sulla cartella clinica, trasformando il documento CDA nel suo stato completo.
La sezione relationship dell'header descrive le classi correlate con la root ClinicalDocument atttraverso il legame ActRelationship.
-ParentDocument: rappresenta il documento sorgente da cui si ottiene il CDA attuale,
attraverso un revisione, aggiunta o trasformazione. ParentDocument.text è modellato come un ED data type e non può essere utilizzato incorporare direttamente il relativo documento.
-RelatedDocument.typeCode: descrive che tipo di aggiornament è il documento corrente rispetto al parentDocument. Questo campo può assumere tre valori:
-APND(append): il documento corrente è un supplemento di
ParentDocument. Questo supplemento è un nuovo documento nel quale è presente il riferimento al parentDocument, e può estendere o modifcare le osservazioni fatte nel documento precedente. Entrambi i documenti rimango a far parte della cartella clinica del paziente ed entrambi rimangono leggibili. -RPLC(replace): il documento corrente sostituisce il Parentdocument. Il documento corrente è una nuova versione del documento precedente, il quale viene considerato sostituito ma rimane comunque disponibile per risalire allo storico dell'evento clinico interessato e per eventuali errori commessi nella stesura del nuovo documento.
-XFRM(transform): il documento corrente è una trasformazione del ParentDocument. Il documento corrente è ottenuto da una trasformazione del
ParentDocument in formato CDA a partire da un formato diverso. La
trasformazione deve garantire che il significato delle informazioni contenute nel documento originale non venga alterato.
-Event: è la classe che rappresenta l'atto clinico principale che viene documentato. In certi
casi può contenere il valore che è racchiuso anche nel ClinicalDocument.code oppure una sua specializzazione. In nessun caso comunque è possibile avere un conflitto tra i valori contenuti nei due campi.
-Order: rappresenta la classe degli ordini per indagini successive o specialistiche, contenute
all'interno del documento, che verranno poi trasformati in event nelle versioni successive del documento stesso.
e consenso al trattamento dei dati da parte di terzi). I consensi associati al documento CDA sono fondamentali per definire la completezza del documento stesso, il quale necessità del Consent.statusCode=”Completed” per essere approvato.
-CurrentEncounter: è una classe opzionale, che rappresenta le informazioni correlate
all'incontro medico durante il quale avviene l'atto clinico documentato. I documenti clinici non sono generati necessariamente nel momento in cui avviene l'incontro, ma nel momento in cui il clinico ha la necessita di aggiornare la valutazione sull'evento clinico.