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

> O DICOM transporta imagens médicas, o FHIR os dados clínicos associados: o que cada um abrange, como ImagingStudy e DiagnosticReport se conectam e o que armazenar onde.

Source: https://developers.anpheros.com/pt/guides/dicom-vs-fhir

**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):

```json
{
  "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](https://developers.anpheros.com/tools/fhir-validator)):

```json
{
  "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 `Observation`s, 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](https://developers.anpheros.com/pt/guides/integrate-clinic-systems-fhir) mostra como escrever uma consulta e os seus documentos numa única transação, e o [Exemplo de DiagnosticReport](https://developers.anpheros.com/tools/fhir-examples/diagnostic-report) 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](https://developers.anpheros.com/pt/guides/interoperability): os padrões em torno do FHIR
- [Plataforma FHIR](https://developers.anpheros.com/pt/guides/fhir): os 26 tipos de recursos que a Anpheros armazena
- [FHIR vs. uma base de dados médica personalizada](https://developers.anpheros.com/pt/guides/fhir-vs-custom-database)
- [API de resultados laboratoriais](https://developers.anpheros.com/pt/guides/lab-results-api): o mesmo padrão para relatórios laboratoriais
- [Como integrar sistemas clínicos com um backend FHIR](https://developers.anpheros.com/pt/guides/integrate-clinic-systems-fhir)