Risposta breve: la Clinical Document Architecture (CDA) è lo standard HL7 per i documenti clinici: riassunti di dimissione, lettere di riferimento, note di consultazione, riassunti del paziente. Un documento CDA è un singolo file XML con un header (chi, quando, su chi) e un body di sezioni, ognuna con narrativa leggibile dall'uomo e, opzionalmente, entry codificate leggibili dalla macchina. C-CDA (Consolidated CDA) è la guida di implementazione statunitense che definisce i template per i tipi di documento più comuni; il CCD (Continuity of Care Document) è il suo membro più noto. La Release 2 di CDA risale al 2005 ed è ancora obbligatoria in diversi programmi nazionali e transfrontalieri.
Come si presenta un documento
Un documento CDA è un file XML con una radice ClinicalDocument che contiene un'intestazione (il tipo di documento come codice LOINC, OID di templateId, un id, data di efficacia, codice di riservatezza, paziente, autore e custode) e un corpo di sezioni, ognuna con un codice LOINC, un elemento di testo obbligatorio leggibile dall'uomo e voci codificate opzionali per l'elaborazione da parte del software.
<ClinicalDocument xmlns="urn:hl7-org:v3">
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
<templateId root="2.16.840.1.113883.10.20.22.1.2" extension="2015-08-01"/>
<id root="2.16.840.1.113883.19.5" extension="DOC-2026-0314"/>
<code code="34133-9" codeSystem="2.16.840.1.113883.6.1" displayName="Summarization of Episode Note"/>
<effectiveTime value="20260314101500+0100"/>
<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
<recordTarget><patientRole>…</patientRole></recordTarget>
<author>…</author>
<custodian>…</custodian>
<component><structuredBody>
<component><section>
<templateId root="2.16.840.1.113883.10.20.22.2.6.1" extension="2015-08-01"/>
<code code="48765-2" codeSystem="2.16.840.1.113883.6.1" displayName="Allergies and adverse reactions"/>
<title>Allergies</title>
<text><table><tr><td>Penicillin</td><td>Rash</td></tr></table></text>
<entry>…coded Allergy Concern Act…</entry>
</section></component>
</structuredBody></component>
</ClinicalDocument>
Tre cose da notare. Il tipo di documento e ogni sezione sono identificati da un codice LOINC (34133-9, 48765-2). I template sono identificati da OID (2.16.840.1…), non da URL. L'elemento <text> è obbligatorio ed è ciò che vede un clinico; l'
I tre livelli
CDA definisce tre livelli di struttura. Il Livello 1 è un'intestazione valida con un corpo non strutturato, come un PDF incorporato. Il Livello 2 aggiunge un corpo strutturato con sezioni e narrazione codificate ma senza voci codificate. Il Livello 3 aggiunge voci codificate seguendo i template, in modo che il software possa importare allergie, farmaci e problemi. La maggior parte dei documenti reali si colloca tra il Livello 2 e il Livello 3.
- Livello 1: un header valido più un corpo non strutturato, ad esempio un PDF incorporato. Legalmente un documento CDA; i computer possono archiviarlo ma non leggerlo.
- Livello 2: corpo strutturato con sezioni codificate e narrativa, senza entry codificate. Il software sa che esiste una sezione allergie; non può elencare le allergie.
- Livello 3: sezioni con entry codificate secondo i template. Il software può importare le allergie, i farmaci e i problemi nel record di ricezione.
La maggior parte dei CDA nel mondo reale si colloca tra il livello 2 e il livello 3: alcune sezioni codificate, altre solo narrative.
Sei principi che lo modellano ancora
I sei principi alla base di CDA sono: persistenza (un documento rimane invariato per anni), custodia (un custode ne è responsabile), potenziale di autenticazione (può essere firmato), contesto (l'intestazione si applica all'intero documento), interezza (una sezione perde significato al di fuori del suo documento) e leggibilità umana (la narrazione viene visualizzata senza software speciali). I documenti FHIR adottano gli stessi sei principi.
CDA è stato progettato attorno a persistenza (un documento vive invariato per anni), gestione (un custode ne è responsabile), potenziale di autenticazione (può essere firmato), contesto (l'header si applica all'intero documento), completezza (una sezione fuori dal suo documento perde significato) e leggibilità umana (la narrativa deve essere visualizzata senza software speciali). I documenti FHIR (un Bundle di tipo document con una Composition) adottano gli stessi principi; il modello dati sottostante è diverso, come spiega CDA vs FHIR.
C-CDA: il consolidamento statunitense
C-CDA (Consolidated CDA) è la guida di implementazione statunitense che, dal 2011, ha unito diverse guide CDA sovrapposte in un'unica, con circa una dozzina di template di documenti come il Continuity of Care Document, il Discharge Summary e il Referral Note, e una libreria condivisa di template di sezioni e voci. C-CDA R2.1 è richiesto dalla certificazione ONC per le transizioni di cura e i riassunti del paziente.
Prima del 2011, gli implementatori statunitensi utilizzavano diverse guide CDA sovrapposte. Consolidated CDA le ha fuse in un'unica guida, con circa una dozzina di template di documenti (Continuity of Care Document, Discharge Summary, Progress Note, Referral Note, Care Plan, Operative Note, Diagnostic Imaging Report e altri) e una libreria condivisa di template di sezioni e entry. C-CDA R2.1 è richiesto dalla certificazione dei sistemi EHR statunitensi (ONC) per le transizioni di cura e i riassunti dei pazienti, e rimane tale accanto a FHIR US Core per le API.
Dove vive CDA nel 2026
Nel 2026 CDA vive nello scambio provider-to-provider statunitense come C-CDA tramite messaggistica Direct e scambi di informazioni sanitarie, nel riassunto del paziente e nella prescrizione elettronica transfrontaliera europea MyHealth@EU, in programmi nazionali come l'eArztbrief e l'ePA della Germania, l'ELGA dell'Austria, l'FSE dell'Italia, nei Paesi Bassi e in Svizzera, e ovunque come un'intestazione che racchiude documenti scansionati o PDF.
- Stati Uniti: C-CDA per lo scambio di documenti tra fornitori, in messaggistica Direct e scambi di informazioni sanitarie.
- Europa, transfrontaliero: MyHealth@EU scambia il Riassunto del Paziente e la Prescrizione Elettronica come documenti CDA (i template eHDSI), con formati basati su FHIR in arrivo sotto l'EHDS. Vedere Prescrizione elettronica oltre i confini dell'UE.
- Programmi nazionali: la lettera medica elettronica tedesca (eArztbrief) e parti dell'ePA, i documenti ELGA austriaci, l'FSE italiano, i Paesi Bassi e la Svizzera utilizzano CDA per i documenti, spesso tramite registri IHE XDS.
- Ovunque: documenti scansionati e PDF racchiusi in un header CDA, in modo che un registro documenti possa indicizzarli.
Cosa riceve effettivamente un destinatario
Un destinatario di un documento CDA riceve sempre una narrazione leggibile, ma dati codificati che può importare solo quando il mittente ha utilizzato i template di Livello 3 in modo coerente. I sistemi riceventi tipicamente visualizzano la narrazione e offrono di riconciliare problemi, farmaci e allergie dalle voci una per una, poiché due documenti di Livello 3 di fornitori diversi raramente codificano lo stesso fatto in modo identico.
Un documento CDA è affidabile per la lettura e incostante per l'importazione. La narrativa è sempre presente; le entry codificate dipendono dal livello e dalla disciplina dei template del mittente. I sistemi riceventi solitamente mostrano la narrativa al clinico e offrono di "riconciliare" problemi, farmaci e allergie dalle entry nel record locale, una per una. Questo passaggio di riconciliazione esiste perché due documenti di Livello 3 di fornitori diversi raramente codificano lo stesso fatto nello stesso modo.
In Anpheros, un documento CDA proveniente da un ospedale viene archiviato così com'è, come DocumentReference con l'XML allegato, e il suo contenuto codificato, dove presente, viene mappato in risorse FHIR (Condition, AllergyIntolerance, MedicationStatement) con la provenienza che punta al documento. Vedere DocumentReference vs DiagnosticReport vs Binary.
Pagine correlate
- CDA vs FHIR
- HL7 vs FHIR: v2, CDA e FHIR
- FHIR Bundle spiegato
- DocumentReference vs DiagnosticReport vs Binary
- Il Riassunto Internazionale del Paziente
- Standard di interoperabilità sanitaria: la mappa
- TEFCA e QHIN spiegati
Fonti
- HL7 CDA Release 2 product brief
- HL7 C-CDA R2.1 product brief
- Navigazione online HL7 C-CDA (template)
- Certificazione ONC: requisiti C-CDA
- MyHealth@EU (Commissione Europea)
Domande frequenti
CDA è la stessa cosa di HL7 v3?
CDA è costruito sul Reference Information Model di HL7 v3 e utilizza i tipi di dati v3, motivo per cui il suo XML ha l'aspetto che ha. Il resto della messaggistica HL7 v3 ha visto poca adozione; CDA è la parte di v3 che ha avuto successo.
Cos'è un CCD?
Il Continuity of Care Document è il tipo di documento C-CDA per un riassunto del paziente: problemi, farmaci, allergie, immunizzazioni, risultati, procedure, segni vitali, piano di cura. È l'equivalente statunitense dell'International Patient Summary.
CDA viene sostituito da FHIR?
Per le nuove API e app, sì; per lo scambio di documenti tra istituzioni, lentamente. Le normative negli Stati Uniti e in Europa richiedono ancora CDA per documenti specifici, e i documenti FHIR vengono introdotti in parallelo piuttosto che in sostituzione.
Un documento CDA può essere convertito in FHIR?
Sì, con dei limiti. La guida di implementazione HL7 C-CDA su FHIR mappa i tipi di documenti e le sezioni; le entry codificate vengono mappate in risorse FHIR dove i template corrispondono. Le sezioni solo narrative diventano sezioni di Composition con testo e nessun dato strutturato.
Provalo gratis nella sandbox
La tua prima chiamata FHIR in 5 minuti. Un'API HL7 FHIR R4 con il consenso del paziente integrato: provala nella sandbox, poi collega la tua app o il sistema della tua clinica.
Gratis · 30 pazienti sintetici · senza carta
Anpheros sviluppa una cartella clinica che il paziente controlla e può condividere con qualsiasi studio medico, su una piattaforma HL7 FHIR R4, con sede in UE. Queste guide ti aiutano a comprendere e organizzare la tua salute; non sostituiscono il tuo medico.
Chi siamo →