Estándares

CDA y C-CDA explicados: el estándar de documentos clínicos de HL7 entre HL7 v2 y FHIR

HL7 CDA es un estándar XML para documentos clínicos que un humano puede leer y una computadora puede procesar. Qué contiene un documento CDA (encabezado, secciones, narrativa, entradas codificadas), los tres niveles, qué añade el US Consolidated CDA, dónde sigue siendo obligatorio el CDA en 2026 y cómo se relaciona con FHIR.

por Publicado 7 min de lectura

Respuesta corta: la Clinical Document Architecture (CDA) es el estándar de HL7 para documentos clínicos: resúmenes de alta, cartas de derivación, notas de consulta, resúmenes de pacientes. Un documento CDA es un archivo XML con una cabecera (quién, cuándo, sobre quién) y un cuerpo de secciones, cada una con narrativa legible por humanos y, opcionalmente, entradas codificadas legibles por máquina. C-CDA (Consolidated CDA) es la guía de implementación de EE. UU. que fija las plantillas para los tipos de documentos más comunes; el CCD (Continuity of Care Document) es su miembro más conocido. La versión 2 de CDA data de 2005 y todavía se exige en varios programas nacionales y transfronterizos.

Cómo se ve un documento

Un documento CDA es un archivo XML con una raíz ClinicalDocument que contiene una cabecera (el tipo de documento como código LOINC, OIDs de templateId, un id, fecha de efectividad, código de confidencialidad, paciente, autor y custodio) y un cuerpo de secciones, cada una con un código LOINC, un elemento de texto legible obligatorio y entradas codificadas opcionales para que el software las lea.

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

Tres cosas a tener en cuenta. El tipo de documento y cada sección se identifican mediante un código LOINC (34133-9, 48765-2). Las plantillas se identifican mediante OID (2.16.840.1…), no URLs. El elemento <text> es obligatorio y es lo que ve un clínico; la <entry> es opcional y es lo que lee el software.

Los tres niveles

CDA define tres niveles de estructura. El Nivel 1 es una cabecera válida con un cuerpo no estructurado, como un PDF incrustado. El Nivel 2 añade un cuerpo estructurado con secciones y narrativa codificadas, pero sin entradas codificadas. El Nivel 3 añade entradas codificadas siguiendo plantillas, de modo que el software pueda importar alergias, medicamentos y problemas. La mayoría de los documentos reales se sitúan entre los niveles 2 y 3.

  • Nivel 1: una cabecera válida más un cuerpo no estructurado, por ejemplo, un PDF incrustado. Legalmente un documento CDA; los ordenadores pueden archivarlo pero no leerlo.
  • Nivel 2: cuerpo estructurado con secciones codificadas y narrativa, sin entradas codificadas. El software sabe que hay una sección de alergias; no puede enumerar las alergias.
  • Nivel 3: secciones con entradas codificadas siguiendo plantillas. El software puede importar las alergias, medicamentos y problemas al registro receptor.

La mayoría de los CDA del mundo real se sitúan entre los niveles 2 y 3: algunas secciones codificadas, otras solo narrativas.

Seis principios que aún lo configuran

Los seis principios detrás de CDA son la persistencia (un documento vive sin cambios durante años), la custodia (un custodio es responsable de él), el potencial de autenticación (puede ser firmado), el contexto (la cabecera se aplica a todo el documento), la integridad (una sección pierde su significado fuera de su documento) y la legibilidad humana (la narrativa se muestra sin software especial). Los documentos FHIR adoptan los mismos seis principios.

CDA fue diseñado en torno a la persistencia (un documento vive sin cambios durante años), la administración (un custodio es responsable de él), la posibilidad de autenticación (puede ser firmado), el contexto (la cabecera se aplica a todo el documento), la integridad (una sección fuera de su documento pierde su significado) y la legibilidad humana (la narrativa debe renderizarse sin software especial). Los documentos FHIR (un Bundle de tipo document con una Composition) adoptan los mismos principios; el modelo de datos subyacente es diferente, como explica CDA vs FHIR.

C-CDA: la consolidación de EE. UU.

C-CDA (Consolidated CDA) es la guía de implementación de EE. UU. que, desde 2011, fusionó varias guías CDA superpuestas en una, con alrededor de una docena de plantillas de documentos como el Continuity of Care Document, Discharge Summary y Referral Note, y una biblioteca compartida de plantillas de secciones y entradas. C-CDA R2.1 es requerido por la certificación de ONC para transiciones de atención y resúmenes de pacientes.

Antes de 2011, los implementadores de EE. UU. utilizaron varias guías CDA superpuestas. Consolidated CDA las fusionó en una sola, con alrededor de una docena de plantillas de documentos (Continuity of Care Document, Discharge Summary, Progress Note, Referral Note, Care Plan, Operative Note, Diagnostic Imaging Report y otras) y una biblioteca compartida de plantillas de secciones y entradas. C-CDA R2.1 es requerido por la certificación de EHR de EE. UU. (ONC) para transiciones de atención y resúmenes de pacientes, y sigue siéndolo junto con FHIR US Core para APIs.

Dónde vive CDA en 2026

En 2026, CDA vive en el intercambio de proveedor a proveedor de EE. UU. como C-CDA a través de Direct messaging e intercambios de información de salud, en el Resumen de Paciente y la Prescripción Electrónica transfronteriza de Europa MyHealth@EU, en programas nacionales como el eArztbrief y ePA de Alemania, ELGA de Austria, FSE de Italia, los Países Bajos y Suiza, y en todas partes como una cabecera que envuelve documentos escaneados o en PDF.

  • Estados Unidos: C-CDA para el intercambio de documentos entre proveedores, en mensajería Direct e intercambios de información de salud.
  • Europa, transfronterizo: MyHealth@EU intercambia el Resumen del Paciente y la Prescripción Electrónica como documentos CDA (las plantillas eHDSI), con formatos basados en FHIR que llegan bajo el EHDS. Consulte Prescripción Electrónica a través de las fronteras de la UE.
  • Programas nacionales: la carta médica electrónica de Alemania (eArztbrief) y partes de la ePA, los documentos ELGA de Austria, la FSE de Italia, los Países Bajos y Suiza utilizan CDA para documentos, a menudo a través de registros IHE XDS.
  • En todas partes: documentos escaneados y PDF envueltos en una cabecera CDA, para que un registro de documentos pueda indexarlos.

Lo que realmente recibe un receptor

Un receptor de un documento CDA siempre recibe una narrativa legible, pero los datos codificados solo puede importarlos cuando el remitente utilizó las plantillas de Nivel 3 de manera consistente. Los sistemas receptores suelen mostrar la narrativa y ofrecen conciliar problemas, medicamentos y alergias de las entradas uno por uno, porque dos documentos de Nivel 3 de diferentes proveedores rara vez codifican el mismo hecho de forma idéntica.

Un documento CDA es fiable para leer y desigual para importar. La narrativa siempre está ahí; las entradas codificadas dependen del nivel y la disciplina de plantillas del remitente. Los sistemas receptores suelen mostrar la narrativa al clínico y ofrecen "conciliar" problemas, medicamentos y alergias de las entradas en el registro local, una por una. Ese paso de conciliación existe porque dos documentos de Nivel 3 de diferentes proveedores rara vez codifican el mismo hecho de la misma manera.

En Anpheros, un documento CDA de un hospital se almacena tal cual, como un DocumentReference con el XML adjunto, y su contenido codificado, donde está presente, se mapea a recursos FHIR (Condition, AllergyIntolerance, MedicationStatement) con procedencia apuntando de vuelta al documento. Consulte DocumentReference vs DiagnosticReport vs Binary.

Páginas relacionadas

Fuentes

Preguntas frecuentes

¿Es CDA lo mismo que HL7 v3?

CDA está construido sobre el Modelo de Información de Referencia HL7 v3 y utiliza tipos de datos v3, por eso su XML tiene el aspecto que tiene. El resto de la mensajería HL7 v3 tuvo poca adopción; CDA es la parte de v3 que tuvo éxito.

¿Qué es un CCD?

El Continuity of Care Document es el tipo de documento C-CDA para un resumen de paciente: problemas, medicamentos, alergias, inmunizaciones, resultados, procedimientos, signos vitales, plan de atención. Es el equivalente en EE. UU. del International Patient Summary.

¿Está FHIR reemplazando a CDA?

Para nuevas APIs y aplicaciones, sí; para el intercambio de documentos entre instituciones, lentamente. Las regulaciones en EE. UU. y Europa todavía exigen CDA para documentos específicos, y los documentos FHIR se están introduciendo junto con ellos en lugar de reemplazarlos.

¿Se puede convertir un documento CDA a FHIR?

Sí, con límites. La guía de implementación HL7 C-CDA on FHIR mapea tipos de documentos y secciones; las entradas codificadas se mapean a recursos FHIR donde las plantillas coinciden. Las secciones solo narrativas se convierten en secciones de Composition con texto y sin datos estructurados.

Anpheros Platform

Pruébalo gratis en el sandbox

Tu primera llamada FHIR en 5 minutos. Una API HL7 FHIR R4 con el consentimiento del paciente integrado: pruébala en el sandbox y luego conecta tu propia app o sistema de clínica.

Gratis · 30 pacientes sintéticos · sin tarjeta

Esta guía es informativa y no sustituye la consulta médica. Para decisiones sobre tu salud, habla con tu médico. En una emergencia, llama al número de emergencias local (112 en Europa).
Escrito por
El equipo de Anpheros

Anpheros crea un historial médico que el paciente controla y puede compartir con cualquier clínica, en una plataforma HL7 FHIR R4, con sede en la UE. Estas guías te ayudan a entender y organizar tu salud; no reemplazan a tu médico.

Sobre Anpheros →