CDA și C-CDA explicate: documente clinice HL7

Răspuns scurt: Clinical Document Architecture (CDA) este standardul HL7 pentru documentele clinice: rezumate de externare, scrisori de trimitere, note de consultație, rezumate ale pacienților. Un document CDA este un fișier XML cu un antet (cine, când, despre cine) și un corp de secțiuni, fiecare cu narativă lizibilă de către om și, opțional, intrări codificate, citibile de către mașină. C-CDA (Consolidated CDA) este ghidul de implementare din SUA care fixează șabloanele pentru cele mai comune tipuri de documente; CCD (Continuity of Care Document) este cel mai cunoscut membru al său. CDA Release 2 datează din 2005 și este încă obligatoriu în mai multe programe naționale și transfrontaliere.

Cum arată un document

Un document CDA este un fișier XML cu o rădăcină ClinicalDocument, care conține un antet (tipul documentului ca un cod LOINC, OID-uri templateId, un id, data efectivă, codul de confidențialitate, pacientul, autorul și custodele) și un corp de secțiuni, fiecare cu un cod LOINC, un element obligatoriu de text lizibil pentru oameni și intrări codificate opționale pentru ca software-ul să le citească.

<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>

Trei lucruri de remarcat. Tipul documentului și fiecare secțiune sunt identificate printr-un cod LOINC (34133-9, 48765-2). Șabloanele sunt identificate prin OID-uri (2.16.840.1…), nu prin URL-uri. Elementul <text> este obligatoriu și este ceea ce vede un clinician; <entry> este opțional și este ceea ce citește software-ul.

Cele trei niveluri

CDA definește trei niveluri de structură. Nivelul 1 este un antet valid cu un corp nestructurat, cum ar fi un PDF încorporat. Nivelul 2 adaugă un corp structurat cu secțiuni codificate și narațiune, dar fără intrări codificate. Nivelul 3 adaugă intrări codificate urmând șabloane, astfel încât software-ul să poată importa alergii, medicamente și probleme. Majoritatea documentelor reale se situează între nivelurile 2 și 3.

Nivelul 1: un antet valid plus un corp nestructurat, de exemplu un PDF încorporat. Legal un document CDA; computerele îl pot arhiva, dar nu îl pot citi.
Nivelul 2: corp structurat cu secțiuni codificate și narativă, fără intrări codificate. Software-ul știe că există o secțiune de alergii; nu poate lista alergiile.
Nivelul 3: secțiuni cu intrări codificate urmând șabloane. Software-ul poate importa alergiile, medicamentele și problemele în registrul de primire.

Majoritatea CDA-urilor din lumea reală se situează între nivelurile 2 și 3: unele secțiuni codificate, altele doar narative.

Șase principii care îl modelează în continuare

Cele șase principii din spatele CDA sunt persistența (un document rămâne neschimbat ani de zile), administrarea (un custode este responsabil pentru acesta), potențialul de autentificare (poate fi semnat), contextul (antetul se aplică întregului document), integritatea (o secțiune își pierde sensul în afara documentului său) și lizibilitatea umană (narațiunea se redă fără software special). Documentele FHIR adoptă aceleași șase principii.

CDA a fost conceput în jurul persistenței (un document trăiește neschimbat ani de zile), administrării (un custode este responsabil pentru el), potențialului de autentificare (poate fi semnat), contextului (antetul se aplică întregului document), întregimii (o secțiune în afara documentului său își pierde sensul) și lizibilității umane (narativa trebuie să fie redată fără software special). Documentele FHIR (un Bundle de tip document cu o Compoziție) adoptă aceleași principii; modelul de date de bază este diferit, așa cum explică CDA vs FHIR.

C-CDA: consolidarea din SUA

C-CDA (Consolidated CDA) este ghidul de implementare din SUA care, începând cu 2011, a fuzionat mai multe ghiduri CDA suprapuse într-unul singur, cu aproximativ o duzină de șabloane de documente, cum ar fi Documentul de continuitate a îngrijirii (Continuity of Care Document), Rezumatul externării (Discharge Summary) și Nota de trimitere (Referral Note), și o bibliotecă comună de șabloane de secțiuni și intrări. C-CDA R2.1 este necesar pentru certificarea ONC pentru tranzițiile de îngrijire și rezumatele pacienților.

Înainte de 2011, implementatorii din SUA au folosit mai multe ghiduri CDA suprapuse. Consolidated CDA le-a unit într-unul singur, cu aproximativ o duzină de șabloane de documente (Continuity of Care Document, Discharge Summary, Progress Note, Referral Note, Care Plan, Operative Note, Diagnostic Imaging Report și altele) și o bibliotecă partajată de șabloane de secțiuni și intrări. C-CDA R2.1 este necesar de certificarea EHR din SUA (ONC) pentru tranzițiile de îngrijire și rezumatele pacienților, și rămâne așa alături de FHIR US Core pentru API-uri.

Unde se află CDA în 2026

În 2026, CDA există în schimbul între furnizorii din SUA ca C-CDA prin mesagerie Direct și schimburi de informații despre sănătate, în Rezumatul pacientului și Prescripția electronică transfrontalieră din Europa (MyHealth@EU), în programe naționale precum eArztbrief și ePA din Germania, ELGA din Austria, FSE din Italia, Țările de Jos și Elveția, și peste tot ca un antet înfășurat în jurul documentelor scanate sau PDF.

Statele Unite: C-CDA pentru schimbul de documente între furnizori, în mesageria Direct și schimburile de informații despre sănătate.
Europa, transfrontalier: MyHealth@EU schimbă Rezumatul Pacientului și ePrescripția ca documente CDA (șabloanele eHDSI), cu formate bazate pe FHIR care apar sub EHDS. Vezi ePrescripția peste granițele UE.
Programe naționale: Scrisoarea electronică a medicului din Germania (eArztbrief) și părți din ePA, documentele ELGA din Austria, FSE din Italia, Olanda și Elveția folosesc CDA pentru documente, adesea prin registre IHE XDS.
Peste tot: documente scanate și PDF-uri încapsulate într-un antet CDA, astfel încât un registru de documente să le poată indexa.

Ce primește de fapt un receptor

Un receptor al unui document CDA primește întotdeauna o narațiune lizibilă, dar date codificate pe care le poate importa doar atunci când expeditorul a utilizat șabloanele de Nivel 3 în mod consecvent. Sistemele receptoare afișează de obicei narațiunea și oferă reconcilierea problemelor, medicamentelor și alergiilor din intrări, una câte una, deoarece două documente de Nivel 3 de la diferiți furnizori rareori codifică același fapt în mod identic.

Un document CDA este fiabil pentru citire și inegal pentru import. Narativa este întotdeauna prezentă; intrările codificate depind de nivelul și disciplina șablonului expeditorului. Sistemele de primire afișează de obicei narativa clinicianului și oferă posibilitatea de a "reconcilia" problemele, medicamentele și alergiile din intrări în registrul local, una câte una. Acest pas de reconciliere există deoarece două documente de Nivel 3 de la diferiți furnizori codifică rar același fapt în același mod.

În Anpheros, un document CDA de la un spital este stocat așa cum este, ca un DocumentReference cu XML-ul atașat, iar conținutul său codificat, acolo unde este prezent, este mapat în resurse FHIR (Condition, AllergyIntolerance, MedicationStatement) cu proveniență indicând înapoi la document. Vezi DocumentReference vs DiagnosticReport vs Binary.

Pagini conexe

Surse

Întrebări frecvente

Este CDA același lucru cu HL7 v3?

CDA este construit pe Modelul de Informații de Referință HL7 v3 și utilizează tipuri de date v3, motiv pentru care XML-ul său arată așa cum arată. Restul mesajelor HL7 v3 a avut o adopție redusă; CDA este partea din v3 care a avut succes.

Ce este un CCD?

Continuity of Care Document este tipul de document C-CDA pentru un rezumat al pacientului: probleme, medicamente, alergii, imunizări, rezultate, proceduri, semne vitale, plan de îngrijire. Este echivalentul din SUA al Rezumatului Internațional al Pacientului.

Este CDA înlocuit de FHIR?

Pentru API-uri și aplicații noi, da; pentru schimbul de documente între instituții, lent. Reglementările din SUA și Europa încă necesită CDA pentru documente specifice, iar documentele FHIR sunt introduse alături, nu în locul lor.

Poate fi un document CDA convertit în FHIR?

Da, cu limite. Ghidul de implementare HL7 C-CDA pe FHIR mapează tipurile de documente și secțiunile; intrările codificate se mapează în resurse FHIR acolo unde șabloanele se potrivesc. Secțiunile doar narative devin secțiuni de Compoziție cu text și fără date structurate.

Anpheros Platform

Încearcă gratuit în sandbox

Primul apel FHIR în 5 minute. Un API HL7 FHIR R4 cu consimțământul pacientului integrat: încearcă-l în sandbox, apoi conectează-ți propria aplicație sau sistemul clinicii.

Creează un sandbox gratuit Citește ghidurile pentru dezvoltatori →

Gratuit · 30 de pacienți sintetici · fără card

Acest ghid este informativ și nu înlocuiește consultul medical. Pentru decizii despre sănătatea ta, vorbește cu medicul tău. În caz de urgență, sună la numărul de urgență local (112 în Europa).

Scris de

Echipa Anpheros

Anpheros construiește un dosar medical pe care pacientul îl controlează și îl poate da oricărei clinici, pe o platformă HL7 FHIR R4, cu sediul în UE. Ghidurile te ajută să-ți înțelegi și să-ți organizezi sănătatea; nu înlocuiesc medicul.

Despre Anpheros →