# DICOM vs FHIR: datos de imagen y datos clínicos

> DICOM transporta imágenes médicas, FHIR los datos clínicos que las rodean: qué cubre cada uno, cómo se conectan ImagingStudy y DiagnosticReport, y qué almacenar dónde.

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

**DICOM y FHIR no son competidores: DICOM es el estándar para imágenes médicas — los píxeles y los metadatos técnicos de una radiografía, TAC o resonancia magnética — mientras que HL7 FHIR es el estándar para los datos clínicos que las rodean, como la orden, el informe del radiólogo, los hallazgos y el paciente al que pertenecen.** Un flujo de trabajo de imagen típico utiliza ambos: el escáner y el PACS hablan DICOM, el hospital y las aplicaciones para pacientes hablan FHIR, y los recursos FHIR apuntan al estudio DICOM en lugar de copiarlo. Esta página explica dónde empieza y termina cada estándar, cómo se conectan y qué debe y no debe almacenar un backend FHIR como Anpheros.

## La respuesta corta

| | DICOM | HL7 FHIR R4 |
|---|---|---|
| Qué transporta | Imágenes y sus metadatos (modalidad, parte del cuerpo, espaciado de corte, dispositivo, UIDs) | Datos clínicos: pacientes, órdenes, informes, observaciones, medicamentos… |
| Tamaño típico | Megabytes a gigabytes por estudio | Kilobytes por recurso |
| Unidad de datos | Estudio → Serie → Instancia, identificada por UIDs globalmente únicos | Recursos (Patient, ServiceRequest, ImagingStudy, DiagnosticReport…) con referencias |
| Transporte | Servicios de red DIMSE (C-STORE, C-FIND, C-MOVE) y REST DICOMweb (QIDO-RS, WADO-RS, STOW-RS) | REST sobre HTTPS con JSON o XML |
| Almacenado en | PACS o archivo neutral de proveedor (VNA) | EHR, servidor FHIR, plataforma de datos de salud |
| Leído por | Visores de radiología, modelos de IA de imágenes, modalidades | Aplicaciones clínicas, aplicaciones para pacientes, análisis, IA que trabaja con texto y valores |

## Para qué sirve DICOM

DICOM (Digital Imaging and Communications in Medicine) define cómo se codifica una imagen y cómo los equipos de imagenología la intercambian. Cada archivo de imagen contiene una cabecera con cientos de atributos —identificadores del paciente y del estudio, modalidad (`CT`, `MR`, `DX`, `US`…), parámetros de adquisición, espaciado de píxeles— junto a los datos de píxeles. Las imágenes se agrupan como instancias dentro de series dentro de un estudio, cada una con un UID como `2.25.181945…`, para que el mismo estudio pueda ser encontrado nuevamente en cualquier archivo.

DICOMweb llevó DICOM a HTTP: `QIDO-RS` para buscar estudios, `WADO-RS` para recuperarlos, `STOW-RS` para almacenarlos. Esto hace que las imágenes sean accesibles desde visores web y servicios en la nube, pero la carga útil sigue siendo DICOM.

Lo que DICOM no hace bien es la historia clínica: por qué se solicitó el estudio, qué concluyó el radiólogo, a qué problema se relaciona y cómo encaja con los resultados de laboratorio y la medicación. Ese es el trabajo de FHIR.

## Lo que FHIR hace en torno a la imagenología

FHIR R4 tiene recursos para cada paso de un flujo de trabajo de imagenología:

- **ServiceRequest** — la orden: "radiografía de tórax, dos vistas, sospecha de neumonía".
- **ImagingStudy** — un resumen de un estudio DICOM (UIDs, modalidad, número de series e instancias, sitio del cuerpo) y un `endpoint` que indica dónde se pueden recuperar las imágenes, por ejemplo, una dirección DICOMweb WADO-RS. No contiene píxeles.
- **DiagnosticReport** — el informe del radiólogo: código, estado, conclusión, la hora de emisión y, opcionalmente, el informe original como PDF en `presentedForm`; `imagingStudy` lo vincula al estudio.
- **Observation** — hallazgos o mediciones individuales que necesitan ser consultables, como el tamaño de un nódulo.
- **DocumentReference** — un documento como un informe PDF o una imagen clave exportada como JPEG.

Un ImagingStudy que apunta a un estudio en un PACS (estructura 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"}}]
  }]
}
```

El informe sobre el mismo estudio, como un DiagnosticReport (pasa el 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"}]
}
```

## Cómo se conectan los dos

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

La regla que mantiene los sistemas simples: **las imágenes permanecen en el archivo de imágenes; el registro clínico guarda el informe, los hallazgos importantes y un puntero a las imágenes.** Copiar estudios DICOM en una base de datos clínica multiplica el riesgo de almacenamiento y privacidad sin hacer que el registro sea más útil para la mayoría de sus lectores.

Otros estándares llenan los vacíos entre hospitales: perfiles IHE como XDS-I para compartir documentos de imágenes entre organizaciones, y FHIRcast para mantener un visor de radiología y una aplicación de informes en el mismo paciente y estudio.

## Imágenes, interoperabilidad e IA

La IA sobre imágenes médicas (detección, segmentación, triaje) opera sobre datos de píxeles DICOM, usualmente dentro del departamento de imágenes o una plataforma especializada. La IA que ayuda a un paciente o a un médico a razonar sobre el registro completo —"¿qué mostró la última radiografía de tórax y cómo se relaciona con la tos y los antibióticos?"— opera sobre el informe, los hallazgos y el resto de los datos clínicos, que es lo que transporta FHIR. Ambos tipos de IA necesitan lo mismo de la infraestructura: datos con códigos, tiempos y un origen registrado.

## Dónde encaja Anpheros

Anpheros almacena el registro de cada paciente como HL7 FHIR R4. Para imágenes, esto significa:

- **Almacenado:** el informe de radiología como un `DiagnosticReport`, el informe original o una imagen clave como un `DocumentReference` (hasta 25 MiB por documento), hallazgos como `Observation`s y la orden como un `ServiceRequest`. Cada escritura lleva procedencia, y el paciente decide qué aplicaciones pueden leerla.
- **No almacenado:** estudios DICOM. Anpheros no es un PACS, no tiene interfaz DICOMweb y no soporta el recurso `ImagingStudy` hoy en día, por lo que no puede indexar ni servir imágenes. No lee ni interpreta imágenes.

En la aplicación Anpheros Daily, un paciente puede fotografiar o cargar un informe de imagen y guardarlo en sus documentos junto con el resto de su registro. Para un desarrollador que crea una aplicación o una integración clínica, la división práctica es: mantenga las imágenes en su sistema de imágenes, escriba el informe y los hallazgos en el registro FHIR del paciente. [Cómo integrar sistemas clínicos con un backend FHIR](https://developers.anpheros.com/es/guides/integrate-clinic-systems-fhir) muestra cómo escribir una visita y sus documentos en una sola transacción, y el [ejemplo de DiagnosticReport](https://developers.anpheros.com/tools/fhir-examples/diagnostic-report) muestra la estructura de un informe.

## Preguntas frecuentes

### ¿Cuál es la diferencia entre DICOM y FHIR?
DICOM codifica e intercambia imágenes médicas y sus metadatos técnicos; FHIR intercambia datos clínicos como órdenes, informes, observaciones y medicamentos. En la práctica, los recursos FHIR describen y referencian estudios de imagen, mientras que las imágenes en sí permanecen en DICOM.

### ¿Puede FHIR almacenar imágenes médicas?
FHIR puede transportar imágenes pequeñas como adjuntos (una imagen clave en un DocumentReference o Media), pero no está diseñado para estudios diagnósticos completos. El recurso ImagingStudy describe un estudio DICOM y apunta a dónde se puede recuperar; los píxeles permanecen en un PACS o archivo.

### ¿Qué es DICOMweb?
La parte RESTful del estándar DICOM: QIDO-RS para buscar, WADO-RS para recuperar y STOW-RS para almacenar estudios a través de HTTP. Un ImagingStudy de FHIR puede apuntar a un endpoint de DICOMweb.

### ¿Qué recurso FHIR contiene un informe de radiología?
DiagnosticReport, con una categoría de radiología, un código LOINC para el examen, una conclusión y, si es necesario, el informe original como un PDF en `presentedForm`. Las mediciones que deben ser buscables se convierten en Observaciones separadas.

### ¿Anpheros soporta DICOM?
No. Anpheros almacena el lado clínico de las imágenes — informes, hallazgos, documentos y órdenes — en el registro FHIR R4 del paciente. No almacena, sirve ni interpreta imágenes DICOM y no soporta ImagingStudy actualmente.

## Relacionado

- [Interoperabilidad de datos de salud](https://developers.anpheros.com/es/guides/interoperability): los estándares en torno a FHIR
- [Plataforma FHIR](https://developers.anpheros.com/es/guides/fhir): los 26 tipos de recursos que Anpheros almacena
- [FHIR frente a una base de datos médica personalizada](https://developers.anpheros.com/es/guides/fhir-vs-custom-database)
- [API de resultados de laboratorio](https://developers.anpheros.com/es/guides/lab-results-api): el mismo patrón para informes de laboratorio
- [Cómo integrar sistemas de clínicas con un backend FHIR](https://developers.anpheros.com/es/guides/integrate-clinic-systems-fhir)