CDA vs FHIR: documentos vs recursos, explicado

Resposta curta: O CDA fornece um único documento: um ficheiro XML assinado sobre um paciente num determinado momento, com texto que um ser humano pode ler e entradas que um computador pode ler, que deve permanecer íntegro e inalterado. O FHIR fornece recursos: um Paciente, quarenta Observações, três Condições, cada um com o seu próprio URL, obtidos, pesquisados e atualizados independentemente através de uma API REST. O FHIR também pode agrupar recursos num documento (um Bundle do tipo document liderado por uma Composição), que é o equivalente direto do CDA. Escolha CDA quando um regulamento ou um parceiro o exigir; escolha FHIR para APIs, aplicações e tudo o que precise de ser consultado em vez de lido.

As duas formas

O CDA e o FHIR têm duas formas diferentes. O CDA troca documentos XML completos, construídos com tipos de dados HL7 v3, identificados por OIDs, com narrativa obrigatória, sem consultas, sem atualizações e com assinatura de documento completo. O FHIR troca recursos JSON ou XML individuais ou Bundles, identificados por URLs canónicos, com consultas REST integradas, atualizações com controlo de versão e perfis publicados em guias de implementação.

	CDA / C-CDA	FHIR
Unidade de troca	Um documento completo	Um recurso, ou um Bundle de recursos
Formato	XML, tipos de dados HL7 v3	JSON ou XML, tipos de dados FHIR
Identificação	OIDs para modelos e sistemas de códigos	URLs (canónicos) para perfis e sistemas de códigos
Parte legível por humanos	`<text>` obrigatório em cada secção	Narrativa `text.div` opcional por recurso; obrigatório em documentos
Transporte	Não definido; transportado por XDS, Direct, MLLP, email	REST sobre HTTPS definido pelo padrão; também mensagens e documentos
Consulta	Não é possível dentro de um documento; os registos indexam o cabeçalho	Integrado: `GET /Observation?patient=…&code=…`
Atualização	Nunca; um novo documento substitui o antigo	Os recursos são versionados e atualizados no local
Assinatura	Documento completo, XML-DSig	Bundle completo possível; recursos individuais raramente assinados
Perfis	Modelos (templateId) por secção e entrada	Perfis StructureDefinition por recurso, publicados em guias de implementação
Terminologia	Códigos de secção LOINC, entradas SNOMED/ICD/RxNorm	Mesmos sistemas de códigos, como CodeableConcept

O que a diferença significa na prática

Na prática, a diferença entre CDA e FHIR é que o CDA é adequado para conteúdo escrito uma vez e preservado na íntegra, como um resumo de alta assinado, enquanto o FHIR é adequado para dados que crescem e são consultados, como uma série de medições de pressão arterial. Um recetor de CDA pode exibir, mas tem de reconciliar para importar; um recetor de FHIR obtém recursos já moldados como o seu próprio registo.

Um resumo de alta é naturalmente um documento: é escrito uma vez, assinado por um médico e deve ser reproduzível anos mais tarde exatamente como foi lido. Uma série de medições de pressão arterial é naturalmente um conjunto de recursos: cresce todos os dias, é representada graficamente e filtrada, e ninguém a assina. O CDA gere bem o primeiro e mal o segundo (reencaminharia todo o documento para cada nova leitura). O FHIR gere o segundo nativamente e o primeiro através do seu mecanismo de documentos.

A outra diferença prática é o que o recetor pode fazer. Um recetor de CDA pode sempre exibir o documento; a importação das suas entradas requer reconciliação, secção a secção. Um recetor FHIR obtém recursos que já estão na forma do seu próprio registo; as questões difíceis passam para a identidade (é o mesmo paciente?) e a proveniência (quem o afirmou e quando?). Ver Correspondência de pacientes.

Documentos FHIR: o ponto de encontro

Um documento FHIR é um Bundle com type: "document" cuja primeira entrada é uma Composição. A Composição desempenha o papel do cabeçalho e da lista de secções do CDA: tipo (LOINC), data, autor, assunto, custodiante, estado e section[] com um título, um código, texto narrativo e referências aos recursos que contêm os dados.

{
  "resourceType": "Bundle",
  "type": "document",
  "identifier": {"system": "urn:ietf:rfc:3986", "value": "urn:uuid:3f2d7a3e-…"},
  "timestamp": "2026-03-14T10:15:00+01:00",
  "entry": [
    {"fullUrl": "urn:uuid:comp-1", "resource": {
      "resourceType": "Composition", "status": "final",
      "type": {"coding": [{"system": "http://loinc.org", "code": "60591-5", "display": "Patient summary Document"}]},
      "subject": {"reference": "urn:uuid:pat-1"},
      "date": "2026-03-14T10:15:00+01:00",
      "author": [{"reference": "urn:uuid:prac-1"}],
      "title": "Patient summary",
      "section": [{
        "title": "Allergies and intolerances",
        "code": {"coding": [{"system": "http://loinc.org", "code": "48765-2"}]},
        "text": {"status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p>Penicillin: rash</p></div>"},
        "entry": [{"reference": "urn:uuid:allergy-1"}]
      }]
    }},
    {"fullUrl": "urn:uuid:pat-1", "resource": {"resourceType": "Patient", "id": "pat-1"}},
    {"fullUrl": "urn:uuid:prac-1", "resource": {"resourceType": "Practitioner", "id": "prac-1"}},
    {"fullUrl": "urn:uuid:allergy-1", "resource": {"resourceType": "AllergyIntolerance", "id": "allergy-1", "patient": {"reference": "urn:uuid:pat-1"}, "code": {"coding": [{"system": "http://snomed.info/sct", "code": "764146007", "display": "Penicillin"}]}}}
  ]
}

O Resumo Internacional do Paciente é exatamente isto: um perfil de documento FHIR, com um gémeo CDA para sistemas que ainda o necessitam. Ver também Bundle FHIR explicado.

Converter entre eles

A conversão entre CDA e FHIR funciona em ambas as direções com limites. O guia de implementação HL7 C-CDA on FHIR mapeia tipos de documentos, secções e entradas para perfis de Composição e recursos; secções apenas com narrativa tornam-se texto sem dados. O FHIR para CDA funciona para recursos que se encaixam em modelos C-CDA. Em qualquer direção, o original deve ser mantido como um DocumentReference com Provenance.

CDA → FHIR: o guia de implementação HL7 C-CDA on FHIR mapeia os tipos de documentos e secções dos EUA para perfis de Composição; as entradas mapeiam para recursos (Problem Concern Act → Condition, Medication Activity → MedicationStatement, Result Observation → Observation). O mapeamento é determinístico para conteúdo de Nível 3 bem modelado e com perdas para secções apenas narrativas, que se tornam texto sem dados.
FHIR → CDA: possível para documentos cujos recursos se encaixam nos modelos C-CDA. Recursos FHIR de formato livre que nunca foram concebidos como um documento (um fluxo de Observações de wearables) não se tornam um CDA sensato.
Mantenha o original. Em qualquer direção de conversão, armazene a origem como foi recebida, como um DocumentReference, e deixe Provenance apontar dos recursos convertidos para ela. A conversão é uma vista, não uma substituição.

Quando o CDA ainda é a resposta certa

O CDA ainda é a resposta certa quando a parte recetora o exige (transições de cuidados nos EUA, resumo do paciente e prescrição eletrónica MyHealth@EU, vários registos nacionais de documentos), quando o conteúdo é legalmente um documento que deve ser assinado e preservado na íntegra, ou quando a infraestrutura do parceiro é IHE XDS, que indexa documentos em vez de recursos. Caso contrário, comece com FHIR.

Quando a parte recetora o exigir (transições de cuidados nos EUA, resumo do paciente e prescrição eletrónica MyHealth@EU hoje, vários registos de documentos nacionais); quando o conteúdo for legalmente um documento que deve ser assinado e preservado na íntegra; quando a infraestrutura do parceiro for IHE XDS, que indexa documentos e não recursos. Em todos os outros casos, comece com FHIR e produza um documento FHIR onde um documento é necessário.

Páginas relacionadas

Fontes

Perguntas frequentes

Um documento FHIR é apenas CDA em JSON?

Não. Partilha os princípios (inteiro, assinado, legível por humanos, com um cabeçalho), mas o seu conteúdo são recursos FHIR comuns, pelo que a mesma Observação pode existir num documento e ser servida pela API. No CDA, uma entrada existe apenas dentro do seu documento.

Posso assinar um documento FHIR?

Sim. Bundle.signature contém uma assinatura digital sobre o bundle, e os guias IPS e nacionais descrevem como. Na prática, muitas implementações dependem da segurança de transporte e da proveniência em vez de assinaturas.

O FHIR tem templateId?

O equivalente é meta.profile, uma lista de URLs canónicos das StructureDefinitions às quais o recurso afirma conformar-se. Os validadores verificam a conformidade da mesma forma que os schematrons CDA verificam os modelos.

Qual deve escolher um novo programa nacional?

Programas recentes (o formato de intercâmbio EHDS, as regras de acesso do paciente dos EUA, o IPS) escolhem FHIR, com documentos FHIR para resumos e cartas, e mantêm um caminho CDA apenas para parceiros legados.

Anpheros Platform

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.

Criar um sandbox grátis Ler os guias para programadores →

Grátis · 30 pacientes sintéticos · sem cartão

Este guia é meramente informativo e não substitui aconselhamento médico. Para decisões sobre a sua saúde, fale com o seu médico. Em uma emergência, ligue para o número de emergência local (112 na Europa).

Escrito por

A equipa Anpheros

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 →