Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

DICOM vs FHIR: dados de imagem e dados clínicos

DICOM transporta imagens médicas, FHIR os dados clínicos à sua volta: o que cada um cobre, como ImagingStudy e DiagnosticReport se conectam, e o que armazenar onde.

DICOM e FHIR não são concorrentes: o DICOM é o padrão para imagens médicas — os pixels e os metadados técnicos de um raio-X, TC ou RM — enquanto o HL7 FHIR é o padrão para os dados clínicos associados, como a requisição, o relatório do radiologista, os achados e o paciente a que pertencem. Um fluxo de trabalho de imagem típico utiliza ambos: o scanner e o PACS comunicam em DICOM, as aplicações hospitalares e de pacientes comunicam em FHIR, e os recursos FHIR apontam para o estudo DICOM em vez de o copiar. Esta página explica onde cada padrão começa e termina, como se conectam e o que um backend FHIR como o Anpheros deve e não deve armazenar.

A resposta curta

	DICOM	HL7 FHIR R4
O que transporta	Imagens e os seus metadados (modalidade, parte do corpo, espaçamento entre fatias, dispositivo, UIDs)	Dados clínicos: pacientes, pedidos, relatórios, observações, medicamentos…
Tamanho típico	Megabytes a gigabytes por estudo	Kilobytes por recurso
Unidade de dados	Estudo → Série → Instância, identificados por UIDs globalmente únicos	Recursos (Patient, ServiceRequest, ImagingStudy, DiagnosticReport…) com referências
Transporte	Serviços de rede DIMSE (C-STORE, C-FIND, C-MOVE) e REST DICOMweb (QIDO-RS, WADO-RS, STOW-RS)	REST sobre HTTPS com JSON ou XML
Armazenado em	PACS ou arquivo neutro do fornecedor (VNA)	EHR, servidor FHIR, plataforma de dados de saúde
Lido por	Visualizadores de radiologia, modelos de IA de imagem, modalidades	Aplicações clínicas, aplicações de pacientes, análise, IA a trabalhar com texto e valores

Para que serve o DICOM

O DICOM (Digital Imaging and Communications in Medicine) define como uma imagem é codificada e como os equipamentos de imagem a trocam. Cada ficheiro de imagem contém um cabeçalho com centenas de atributos — identificadores do paciente e do estudo, modalidade (CT, MR, DX, US…), parâmetros de aquisição, espaçamento de píxeis — juntamente com os dados dos píxeis. As imagens são agrupadas como instâncias dentro de séries dentro de um estudo, cada uma com um UID como 2.25.181945…, para que o mesmo estudo possa ser encontrado novamente em qualquer arquivo.

O DICOMweb trouxe o DICOM para o HTTP: QIDO-RS para procurar estudos, WADO-RS para os recuperar, STOW-RS para os armazenar. Isto torna as imagens acessíveis a partir de visualizadores web e serviços na nuvem, mas a carga útil continua a ser DICOM.

O que o DICOM não faz bem é a história clínica: por que o estudo foi solicitado, o que o radiologista concluiu, a que problema se relaciona e como se enquadra com os resultados de laboratório e medicamentos. Essa é a tarefa do FHIR.

O que o FHIR faz em torno de imagens

O FHIR R4 tem recursos para cada etapa de um fluxo de trabalho de imagem:

ServiceRequest — a ordem: "raio-X de tórax, duas vistas, suspeita de pneumonia".
ImagingStudy — um resumo de um estudo DICOM (UIDs, modalidade, número de séries e instâncias, local do corpo) e um endpoint que indica onde as imagens podem ser recuperadas, por exemplo, um endereço DICOMweb WADO-RS. Não contém pixels.
DiagnosticReport — o relatório do radiologista: código, estado, conclusão, hora de emissão e, opcionalmente, o relatório original como PDF em presentedForm; imagingStudy liga-o ao estudo.
Observation — achados ou medições individuais que precisam de ser consultáveis, como o tamanho de um nódulo.
DocumentReference — um documento como um relatório PDF ou uma imagem chave exportada como JPEG.

Um ImagingStudy que aponta para um estudo num PACS (estrutura FHIR R4 válida):

{
  "resourceType": "ImagingStudy",
  "status": "available",
  "subject": {"reference": "Patient/example"},
  "identifier": [{"system": "urn:dicom:uid", "value": "urn:oid:2.25.181945102383749012843512396725468820"}],
  "started": "2026-10-03T10:20:00-05:00",
  "modality": [{"system": "http://dicom.nema.org/resources/ontology/DCM", "code": "DX"}],
  "numberOfSeries": 1,
  "numberOfInstances": 2,
  "endpoint": [{"reference": "Endpoint/pacs-wado"}],
  "series": [{
    "uid": "2.25.30584718293846127394857102938475",
    "modality": {"system": "http://dicom.nema.org/resources/ontology/DCM", "code": "DX"},
    "bodySite": {"system": "http://snomed.info/sct", "code": "51185008", "display": "Thoracic structure"},
    "numberOfInstances": 2,
    "instance": [{"uid": "2.25.11223344556677889900112233445566",
                  "sopClass": {"system": "urn:ietf:rfc:3986", "code": "urn:oid:1.2.840.10008.5.1.4.1.1.1.1"}}]
  }]
}

O relatório sobre o mesmo estudo, como um DiagnosticReport (passa o validador FHIR R4):

{
  "resourceType": "DiagnosticReport",
  "status": "final",
  "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/v2-0074", "code": "RAD", "display": "Radiology"}]}],
  "code": {"coding": [{"system": "http://loinc.org", "code": "36643-5", "display": "XR Chest 2 Views"}], "text": "Chest X-ray, 2 views"},
  "subject": {"reference": "Patient/example"},
  "effectiveDateTime": "2026-10-03T10:20:00-05:00",
  "issued": "2026-10-03T15:05:00-05:00",
  "performer": [{"display": "Springfield Imaging Center"}],
  "conclusion": "No acute cardiopulmonary abnormality.",
  "presentedForm": [{"contentType": "application/pdf", "url": "https://imaging.springfield-hospital.test/reports/RPT-8812.pdf", "title": "Radiology report"}]
}

Como os dois se conectam

 modality (X-ray, CT, MR) ──DICOM──► PACS / VNA ◄──DICOMweb (WADO-RS)── image viewer, AI image model
                                         ▲
                     ImagingStudy.endpoint│ (where the images are)
                                         │
 order (ServiceRequest) ──► study ──► report (DiagnosticReport) ──► patient record (FHIR)
                                                                       │
                                     patient app, clinic system, AI assistant (text and values)

A regra que mantém os sistemas simples: as imagens ficam no arquivo de imagem; o registo clínico guarda o relatório, as descobertas importantes e um ponteiro para as imagens. Copiar estudos DICOM para uma base de dados clínica multiplica o risco de armazenamento e privacidade sem tornar o registo mais útil para a maioria dos seus leitores.

Outros padrões preenchem as lacunas entre hospitais: perfis IHE como o XDS-I para partilhar documentos de imagem entre organizações, e FHIRcast para manter um visualizador de radiologia e uma aplicação de relatório sobre o mesmo paciente e estudo.

Imagem, interoperabilidade e IA

A IA em imagens médicas (detecção, segmentação, triagem) opera sobre dados de pixels DICOM, geralmente dentro do departamento de imagem ou numa plataforma especializada. A IA que auxilia um paciente ou um médico a raciocinar sobre o registo completo — "o que mostrou a última radiografia do tórax e como se relaciona com a tosse e os antibióticos?" — opera sobre o relatório, os achados e o restante dos dados clínicos, que é o que o FHIR transporta. Ambos os tipos de IA necessitam da mesma coisa da infraestrutura: dados com códigos, tempos e uma origem registada.

Onde o Anpheros se encaixa

O Anpheros armazena o registo de cada paciente como HL7 FHIR R4. Para imagiologia, isto significa:

Armazenado: o relatório de radiologia como um DiagnosticReport, o relatório original ou uma imagem chave como um DocumentReference (até 25 MiB por documento), achados como Observations, e a ordem como um ServiceRequest. Cada escrita carrega proveniência, e o paciente decide que aplicações podem lê-la.
Não armazenado: estudos DICOM. O Anpheros não é um PACS, não tem interface DICOMweb e não suporta o recurso ImagingStudy hoje em dia, pelo que não consegue indexar ou servir imagens. Não lê nem interpreta imagens.

Na aplicação Anpheros Daily, um paciente pode fotografar ou carregar um relatório de imagiologia e mantê-lo nos seus documentos ao lado do resto do seu registo. Para um programador a construir uma aplicação ou uma integração de clínica, a divisão prática é: manter as imagens no seu sistema de imagiologia, escrever o relatório e os achados no registo FHIR do paciente. Como integrar sistemas de clínica com um backend FHIR mostra como escrever uma consulta e os seus documentos numa única transação, e o Exemplo de DiagnosticReport mostra a estrutura de um relatório.

Perguntas frequentes

Qual é a diferença entre DICOM e FHIR?

O DICOM codifica e troca imagens médicas e os seus metadados técnicos; o FHIR troca dados clínicos como pedidos, relatórios, observações e medicamentos. Na prática, os recursos FHIR descrevem e referenciam estudos de imagem, enquanto as próprias imagens permanecem em DICOM.

O FHIR pode armazenar imagens médicas?

O FHIR pode transportar pequenas imagens como anexos (uma imagem chave num DocumentReference ou Media), mas não foi concebido para estudos de diagnóstico completos. O recurso ImagingStudy descreve um estudo DICOM e aponta para onde pode ser recuperado; os pixels permanecem num PACS ou arquivo.

O que é DICOMweb?

A parte RESTful do padrão DICOM: QIDO-RS para pesquisar, WADO-RS para recuperar e STOW-RS para armazenar estudos sobre HTTP. Um ImagingStudy FHIR pode apontar para um endpoint DICOMweb.

Qual recurso FHIR contém um relatório de radiologia?

DiagnosticReport, com uma categoria de radiologia, um código LOINC para o exame, uma conclusão e, se necessário, o relatório original em PDF em presentedForm. As medições que devem ser pesquisáveis tornam-se Observações separadas.

O Anpheros suporta DICOM?

Não. O Anpheros armazena o lado clínico da imagem — relatórios, achados, documentos e pedidos — no registo FHIR R4 do paciente. Não armazena, serve ou interpreta imagens DICOM e não suporta ImagingStudy atualmente.

Relacionado

Interoperabilidade de dados de saúde: os padrões em torno do FHIR
Plataforma FHIR: os 26 tipos de recursos que a Anpheros armazena
FHIR vs. uma base de dados médica personalizada
API de resultados laboratoriais: o mesmo padrão para relatórios laboratoriais
Como integrar sistemas clínicos com um backend FHIR

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card