FHIR ImagingStudy frente a DICOMweb: qué contiene qué

Respuesta corta: ImagingStudy es un recurso FHIR que indica este paciente se hizo una tomografía en esta fecha, con estas series y estas UID de instancia, y las imágenes están allá. DICOMweb es el allá: la interfaz REST del archivo que contiene los píxeles. FHIR transporta la descripción y el informe; DICOM transporta las imágenes. Un ImagingStudy hace referencia a un recurso Endpoint cuyo connectionType es dicom-wado-rs, y un visor combina ambos.

Qué contiene ImagingStudy

Un recurso FHIR ImagingStudy contiene los metadatos de un estudio de imagen: el DICOM Study Instance UID como identificador, un estado, el Paciente sujeto, el encuentro, la hora de inicio y la solicitud de servicio solicitante, códigos de modalidad del vocabulario DICOM DCM, recuentos de series e instancias, el Endpoint donde residen las imágenes, y cada serie con sus instancias y UIDs. No contiene píxeles.

identifier: la UID de Estudio de DICOM, como urn:oid:1.2.840… con el sistema urn:dicom:uid;
status: registered, available, cancelled, entered-in-error, unknown;
subject: el Paciente; encounter, started, referrer, basedOn (el ServiceRequest que lo solicitó);
modality: códigos del propio vocabulario de DICOM (CT, MR, US, CR, DX…), sistema http://dicom.nema.org/resources/ontology/DCM;
numberOfSeries, numberOfInstances;
endpoint: dónde obtener las imágenes;
series[]: cada uno con su UID de Serie, modalidad, sitio corporal, instance[] con UID de Instancia SOP y UID de Clase SOP.

Lo que no contiene: datos de píxeles, ajustes de ventana, la cabecera DICOM completa, o el texto del informe. El informe es un DiagnosticReport con imagingStudy apuntando hacia atrás.

Un ejemplo válido de FHIR R4

Un ejemplo válido de FHIR R4 ImagingStudy incluye el Study Instance UID como identificador con el sistema urn:dicom:uid, estado disponible, una modalidad CT del sistema de códigos DICOM DCM, el paciente, la hora de inicio, recuentos de series e instancias, una referencia a un Endpoint de connectionType dicom-wado-rs, y entradas de series con sus UIDs, sitio del cuerpo y SOP Class UID.

{
  "resourceType": "ImagingStudy",
  "id": "ct-chest-2026-03",
  "identifier": [{"system": "urn:dicom:uid", "value": "urn:oid:1.2.840.113619.2.55.3.2831164356.781.1710415000.1"}],
  "status": "available",
  "modality": [{"system": "http://dicom.nema.org/resources/ontology/DCM", "code": "CT"}],
  "subject": {"reference": "Patient/example"},
  "started": "2026-03-14T09:12:00+01:00",
  "numberOfSeries": 2,
  "numberOfInstances": 412,
  "endpoint": [{"reference": "Endpoint/pacs-dicomweb"}],
  "series": [{
    "uid": "1.2.840.113619.2.55.3.2831164356.781.1710415000.2",
    "number": 1,
    "modality": {"system": "http://dicom.nema.org/resources/ontology/DCM", "code": "CT"},
    "bodySite": {"system": "http://snomed.info/sct", "code": "51185008", "display": "Thoracic structure"},
    "numberOfInstances": 410,
    "instance": [{
      "uid": "1.2.840.113619.2.55.3.2831164356.781.1710415000.3",
      "sopClass": {"system": "urn:ietf:rfc:3986", "code": "urn:oid:1.2.840.10008.5.1.4.1.1.2"},
      "number": 1
    }]
  }]
}

La UID de Clase SOP 1.2.840.10008.5.1.4.1.1.2 es CT Image Storage. El Endpoint se ve así:

{
  "resourceType": "Endpoint",
  "id": "pacs-dicomweb",
  "status": "active",
  "connectionType": {"system": "http://terminology.hl7.org/CodeSystem/endpoint-connection-type", "code": "dicom-wado-rs"},
  "payloadType": [{"text": "DICOM WADO-RS"}],
  "address": "https://pacs.example-hospital.org/dicomweb"
}

Un visor construye la URL de recuperación a partir de ambos: {Endpoint.address}/studies/{StudyInstanceUID}, luego llama a WADO-RS para metadatos y fotogramas.

Quién crea los recursos ImagingStudy

Los recursos ImagingStudy suelen ser creados por una fachada FHIR delante del PACS o VNA, o por un motor de integración, cuando un estudio está completo, a menudo activado por el mensaje HL7 v2 ORU o el DICOM MPPS. Algunos archivos los generan sobre la marcha a partir de una consulta QIDO-RS. El escáner en sí no crea recursos ImagingStudy.

Normalmente no el escáner. Una fachada FHIR delante del PACS o VNA, o un motor de integración, crea el ImagingStudy cuando el estudio está completo (a menudo activado por el mensaje HL7 v2 ORU o el DICOM MPPS) y mantiene numberOfInstances sincronizado. Algunos archivos generan ImagingStudy sobre la marcha a partir de una consulta QIDO-RS. Si su proyecto los escribe manualmente, las UID deben coincidir exactamente con el archivo, carácter por carácter, o el visor mostrará un estudio vacío.

Errores que rompen los visores

Los errores que rompen los visores al leer un FHIR ImagingStudy son: poner el Study UID en id en lugar de identifier, usar un código de modalidad no DICOM, apuntar un Endpoint con el connectionType incorrecto a un servidor DICOMweb, dejar los recuentos de series e instancias desactualizados después de que las imágenes cambian, y esperar datos de píxeles en un FHIR Binary en lugar de un archivo DICOM.

Poner la UID de Estudio en id en lugar de identifier; los ids de FHIR son asignados por el servidor y no pueden ser OIDs.
Una modalidad de SNOMED o una lista local en lugar del sistema de códigos DICOM DCM.
Un Endpoint con connectionType hl7-fhir-rest apuntando a un servidor DICOMweb, o viceversa.
Contar series e instancias una vez y nunca actualizar cuando se añaden o eliminan imágenes.
Esperar los datos de píxeles en FHIR Binary. La especificación FHIR en sí misma dice que las imágenes pertenecen a DICOM, no a Binary.

En un registro Anpheros

Anpheros Platform no aloja datos de ImagingStudy ni DICOM. Los hallazgos de radiología llegan como DiagnosticReport o DocumentReference (el informe, con sus códigos y texto); donde el hospital expone un enlace a un visor, el DocumentReference puede llevarlo como una URL de adjunto. Las imágenes permanecen en el archivo del hospital bajo sus reglas de acceso.

Páginas relacionadas

Fuentes

Preguntas frecuentes

¿Puede un servidor FHIR almacenar las imágenes en sí?

Técnicamente, un Binary puede contener cualquier byte, pero la especificación FHIR desaconseja su uso para imágenes y ningún visor funciona de esa manera. Las imágenes permanecen en un archivo DICOM; FHIR apunta a él.

¿Qué cambió en FHIR R5 para ImagingStudy?

R5 mantiene la misma estructura, ordena la nomenclatura (por ejemplo, procedure reemplaza a procedureReference y procedureCode) y alinea el manejo del sitio corporal. R4 sigue siendo la versión que utilizan la mayoría de los archivos y perfiles nacionales.

¿Cómo se vincula el informe a las imágenes?

DiagnosticReport.imagingStudy hace referencia al ImagingStudy; DiagnosticReport.media puede contener imágenes clave como recursos Media. El ImagingStudy hace referencia al Endpoint para el estudio completo.

¿Necesito ImagingStudy si ya tengo DICOMweb?

Solo si otros consumidores de FHIR necesitan saber que el estudio existe, por ejemplo, una aplicación para pacientes, un plan de atención o una exportación de investigación. Un visor de radiología por sí solo puede funcionar con QIDO-RS y WADO-RS.

Anpheros Daily

Pruébalo en Anpheros Daily

Guarda tus informes de escáner y pruebas en un solo lugar en Anpheros Daily, listos para mostrar en tu próxima visita.

Cómo funciona en la app →

iPhone y Mac Android Ábrelo en tu navegador →

Esta guía es informativa y no sustituye la consulta médica. Para decisiones sobre tu salud, habla con tu médico. En una emergencia, llama al número de emergencias local (112 en Europa).

Escrito por

El equipo de Anpheros

Anpheros crea un historial médico que el paciente controla y puede compartir con cualquier clínica, en una plataforma HL7 FHIR R4, con sede en la UE. Estas guías te ayudan a entender y organizar tu salud; no reemplazan a tu médico.

Sobre Anpheros →