Resposta curta: a Clinical Document Architecture (CDA) é o padrão da HL7 para documentos clínicos: resumos de alta, cartas de referência, notas de consulta, resumos de pacientes. Um documento CDA é um ficheiro XML com um cabeçalho (quem, quando, sobre quem) e um corpo de secções, cada uma com narrativa legível por humanos e, opcionalmente, entradas codificadas legíveis por máquina. C-CDA (Consolidated CDA) é o guia de implementação dos EUA que fixa os modelos para os tipos de documentos mais comuns; o CCD (Continuity of Care Document) é o seu membro mais conhecido. A versão CDA Release 2 data de 2005 e ainda é mandatória em vários programas nacionais e transfronteiriços.
Como é um documento
Um documento CDA é um ficheiro XML com uma raiz ClinicalDocument que contém um cabeçalho (o tipo de documento como um código LOINC, OIDs de templateId, um id, data de efeito, código de confidencialidade, paciente, autor e custodiante) e um corpo de secções, cada uma com um código LOINC, um elemento de texto obrigatório legível por humanos e entradas codificadas opcionais para que o software possa ler.
<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>
Três coisas a notar. O tipo de documento e cada secção são identificados por um código LOINC (34133-9, 48765-2). Os modelos são identificados por OIDs (2.16.840.1…), não por URLs. O elemento <text> é obrigatório e é o que um clínico vê; a <entry> é opcional e é o que o software lê.
Os três níveis
O CDA define três níveis de estrutura. O Nível 1 é um cabeçalho válido com um corpo não estruturado, como um PDF incorporado. O Nível 2 adiciona um corpo estruturado com secções codificadas e narrativa, mas sem entradas codificadas. O Nível 3 adiciona entradas codificadas seguindo modelos, para que o software possa importar alergias, medicamentos e problemas. A maioria dos documentos reais situa-se entre os níveis 2 e 3.
- Nível 1: um cabeçalho válido mais um corpo não estruturado, por exemplo, um PDF incorporado. Legalmente um documento CDA; os computadores podem arquivá-lo, mas não lê-lo.
- Nível 2: corpo estruturado com secções codificadas e narrativa, sem entradas codificadas. O software sabe que existe uma secção de alergias; não consegue listar as alergias.
- Nível 3: secções com entradas codificadas a seguir a modelos. O software pode importar as alergias, medicamentos e problemas para o registo de receção.
A maioria dos CDA do mundo real situa-se entre os níveis 2 e 3: algumas secções codificadas, outras apenas narrativas.
Seis princípios que ainda o moldam
Os seis princípios por trás do CDA são persistência (um documento vive inalterado durante anos), custódia (um custodiante é responsável por ele), potencial de autenticação (pode ser assinado), contexto (o cabeçalho aplica-se a todo o documento), integridade (uma secção perde o significado fora do seu documento) e legibilidade humana (a narrativa é apresentada sem software especial). Os documentos FHIR adotam os mesmos seis princípios.
O CDA foi concebido em torno da persistência (um documento vive inalterado durante anos), gestão (um custodiante é responsável por ele), potencial de autenticação (pode ser assinado), contexto (o cabeçalho aplica-se a todo o documento), integridade (uma secção fora do seu documento perde o significado) e legibilidade humana (a narrativa deve ser apresentada sem software especial). Os documentos FHIR (um Bundle do tipo document com uma Composition) adotam os mesmos princípios; o modelo de dados subjacente é diferente, como explica CDA vs FHIR.
C-CDA: a consolidação dos EUA
O C-CDA (Consolidated CDA) é o guia de implementação dos EUA que, a partir de 2011, fundiu vários guias CDA sobrepostos num só, com cerca de uma dúzia de modelos de documentos, como o Continuity of Care Document, Discharge Summary e Referral Note, e uma biblioteca partilhada de modelos de secções e entradas. O C-CDA R2.1 é exigido pela certificação ONC para transições de cuidados e resumos de pacientes.
Antes de 2011, os implementadores dos EUA usavam vários guias CDA sobrepostos. O Consolidated CDA fundiu-os num só, com cerca de uma dúzia de modelos de documentos (Continuity of Care Document, Discharge Summary, Progress Note, Referral Note, Care Plan, Operative Note, Diagnostic Imaging Report e outros) e uma biblioteca partilhada de modelos de secções e entradas. O C-CDA R2.1 é exigido pela certificação de EHR dos EUA (ONC) para transições de cuidados e resumos de pacientes, e continua a sê-lo juntamente com o FHIR US Core para APIs.
Onde o CDA vive em 2026
Em 2026, o CDA vive na troca entre prestadores de serviços nos EUA como C-CDA através de mensagens Direct e trocas de informação de saúde, no Resumo do Paciente e Prescrição Eletrónica transfronteiriços da Europa MyHealth@EU, em programas nacionais como o eArztbrief e ePA da Alemanha, o ELGA da Áustria, o FSE da Itália, os Países Baixos e a Suíça, e em todo o lado como um cabeçalho envolto em documentos digitalizados ou PDF.
- Estados Unidos: C-CDA para troca de documentos entre prestadores, em mensagens Direct e trocas de informação de saúde.
- Europa, transfronteiriço: MyHealth@EU troca o Resumo do Paciente e a Prescrição Eletrónica como documentos CDA (os modelos eHDSI), com formatos baseados em FHIR a chegar sob o EHDS. Ver Prescrição Eletrónica entre fronteiras da UE.
- Programas nacionais: A carta eletrónica do médico na Alemanha (eArztbrief) e partes da ePA, os documentos ELGA da Áustria, a FSE da Itália, os Países Baixos e a Suíça usam CDA para documentos, muitas vezes através de registos IHE XDS.
- Em todo o lado: documentos digitalizados e em PDF encapsulados num cabeçalho CDA, para que um registo de documentos os possa indexar.
O que um recetor recebe realmente
Um recetor de um documento CDA recebe sempre uma narrativa legível, mas dados codificados só pode importar quando o remetente utilizou consistentemente modelos de Nível 3. Os sistemas recetores exibem tipicamente a narrativa e oferecem-se para reconciliar problemas, medicamentos e alergias das entradas uma a uma, porque dois documentos de Nível 3 de fornecedores diferentes raramente codificam o mesmo facto de forma idêntica.
Um documento CDA é fiável para leitura e irregular para importação. A narrativa está sempre presente; as entradas codificadas dependem do nível e da disciplina de modelo do remetente. Os sistemas recetores geralmente mostram a narrativa ao clínico e oferecem-se para "reconciliar" problemas, medicamentos e alergias das entradas no registo local, um a um. Esse passo de reconciliação existe porque dois documentos de Nível 3 de fornecedores diferentes raramente codificam o mesmo facto da mesma maneira.
Na Anpheros, um documento CDA de um hospital é armazenado como está, como um DocumentReference com o XML anexado, e o seu conteúdo codificado, onde presente, é mapeado para recursos FHIR (Condition, AllergyIntolerance, MedicationStatement) com proveniência a apontar de volta para o documento. Ver DocumentReference vs DiagnosticReport vs Binary.
Páginas relacionadas
- CDA vs FHIR
- HL7 vs FHIR: v2, CDA e FHIR
- FHIR Bundle explicado
- DocumentReference vs DiagnosticReport vs Binary
- O Resumo Internacional do Paciente
- Padrões de interoperabilidade de saúde: o mapa
- TEFCA e QHINs explicados
Fontes
- HL7 CDA Release 2 product brief
- HL7 C-CDA R2.1 product brief
- HL7 C-CDA online navigation (templates)
- ONC Certification: C-CDA requirements
- MyHealth@EU (European Commission)
Perguntas frequentes
O CDA é o mesmo que HL7 v3?
O CDA é construído sobre o HL7 v3 Reference Information Model e usa tipos de dados v3, razão pela qual o seu XML tem o aspeto que tem. O resto da mensagem HL7 v3 teve pouca adoção; o CDA é a parte do v3 que teve sucesso.
O que é um CCD?
O Continuity of Care Document é o tipo de documento C-CDA para um resumo do paciente: problemas, medicamentos, alergias, imunizações, resultados, procedimentos, sinais vitais, plano de cuidados. É o equivalente nos EUA do International Patient Summary.
O CDA está a ser substituído pelo FHIR?
Para novas APIs e aplicações, sim; para troca de documentos entre instituições, lentamente. Os regulamentos nos EUA e na Europa ainda exigem CDA para documentos específicos, e os documentos FHIR estão a ser introduzidos em paralelo em vez de substituição.
Um documento CDA pode ser convertido para FHIR?
Sim, com limites. O guia de implementação HL7 C-CDA on FHIR mapeia tipos de documentos e secções; as entradas codificadas mapeiam para recursos FHIR onde os modelos correspondem. As secções apenas narrativas tornam-se secções de Composition com texto e sem dados estruturados.
Experimente grátis no sandbox
Sua primeira chamada FHIR em 5 minutos. Uma API HL7 FHIR R4 com o consentimento do paciente integrado: experimente na sandbox e depois conecte a sua própria app ou sistema clínico.
Grátis · 30 pacientes sintéticos · sem cartão
A Anpheros desenvolve um registo médico que o doente controla e pode partilhar com qualquer clínica, numa plataforma HL7 FHIR R4, sediada na UE. Estes guias ajudam-no a compreender e organizar a sua saúde; não substituem o seu médico.
Sobre a Anpheros →