DICOMweb vs DIMSE: cómo eligen los visores modernos

Si alguna vez intentaste integrar un visor con un PACS y aparecieron las palabras C-STORE, WADO-RS, AE Title o QIDO-RS, te cruzaste con las dos familias de protocolos del ecosistema DICOM. La diferencia entre ellas no es histórica ni cosmética: define qué visores podés enchufar a qué PACS, cómo se comporta el sistema bajo carga y qué tan caro es agregar un nuevo nodo. Acá las desarmamos sin abreviaturas sin explicar.

Una sola idea para arrancar

DICOM, el estándar de imágenes médicas, define dos formas totalmente distintas de mover datos entre dos sistemas:

• DIMSE (DICOM Message Service Element) — la familia clásica, sobre TCP/IP puro, con un sub-protocolo propio. Décadas de despliegue. Es lo que sale del equipo de TC hacia el PACS.
• DICOMweb — la familia moderna, sobre HTTP/HTTPS y REST. Pensada para web, cloud, microservicios y visores nativos en browser.

Ambas mueven los mismos objetos DICOM (estudios, series, imágenes, presentation states, structured reports). Lo que cambia es el transporte. Y eso, en la práctica, cambia muchísimas cosas.

DIMSE en una página

DIMSE define un puñado de operaciones llamadas servicios. Las cuatro que cualquier radiólogo o admin de PACS se cruza:

• C-ECHO — el "ping" DICOM. Verifica que dos AEs (Application Entities) puedan hablarse.
• C-STORE — empujar un estudio. El equipo de TC le manda series al PACS con C-STORE. Es push.
• C-FIND — buscar estudios en el PACS por criterios (paciente, fecha, modalidad). Devuelve metadata, no imágenes.
• C-MOVE — pedirle al PACS que mande estudios a una tercera AE. Es la combinación clásica para que el visor cargue un estudio: el visor hace C-FIND, encuentra el estudio, hace C-MOVE para que el PACS le mande las imágenes vía C-STORE.
• C-GET — variante de C-MOVE donde el visor recibe las imágenes directamente sobre la misma conexión, sin que el PACS abra una nueva. Más simple pero menos usado en producción.

La parte que nadie te explicó: AE Titles y puertos

Cada nodo DIMSE tiene un AE Title (un identificador en mayúsculas, máximo 16 caracteres) y escucha en un puerto TCP (típicamente 104, 11112 o lo que el admin decida). Para que dos nodos se hablen, el receptor tiene que conocer al emisor de antemano: (AE Title del emisor + IP + puerto). Esto es allowlist manual. Cambiás IP, cambiás AE Title, agregás un equipo nuevo: alguien edita una configuración en el PACS.

Esa rigidez es la causa fundamental de la mayoría de los problemas de PACS en la práctica. "Por qué este equipo no manda al PACS" suele resolverse en el archivo de configuración del PACS, no en el equipo.

Performance y firewalls

DIMSE usa una conexión TCP persistente. Es muy eficiente para mover gigabytes en una LAN (un estudio de TC puede tener 2 GB). Pero atravesar firewalls, NAT, balanceadores y reverse proxies es doloroso: los firewalls modernos están afinados para HTTP, no para protocolos binarios sobre puertos arbitrarios. Por eso DIMSE prácticamente no funciona "tal cual" sobre Internet — necesita VPN o túnel.

DICOMweb en una página

DICOMweb es un conjunto de servicios REST sobre HTTPS, definidos por el mismo comité que mantiene DICOM. Las cuatro APIs principales:

• QIDO-RS (Query based on ID for DICOM Objects) — equivalente a C-FIND. Buscás con GET /studies?PatientID=... y recibís JSON con metadata.
• WADO-RS (Web Access to DICOM Objects) — equivalente a C-GET. Pedís imágenes con GET /studies/{uid}/series/{uid}/instances/{uid}. Te devuelve el archivo DICOM o, mejor todavía, JPEG/PNG renderizado en el server (WADO-URI / Rendered Resources).
• STOW-RS (STore Over the Web) — equivalente a C-STORE. Subís un estudio con POST /studies en multipart.
• UPS-RS (Unified Procedure Step) — coordinación de workflow entre RIS y modalidades. Es lo que reemplaza a la modality worklist clásica en arquitecturas modernas. Ver también la guía sobre integración PACS-RIS-HIS.

Por qué cambia el juego

DICOMweb es HTTPS estándar. Eso significa:

• Atraviesa firewalls sin esfuerzo. Mismo puerto 443 que cualquier web.
• Tokens, OAuth y JWT funcionan nativamente. No hay que inventar autenticación.
• Cache HTTP y CDNs aplicables — si un estudio fue cargado por el visor de un médico, el siguiente que lo abre lo recibe del edge.
• Visores web sin instalación — un visor JavaScript en el browser hace requests directos al PACS, sin proxies.
• Microservicios y arquitecturas cloud son naturales. Cada componente del PACS puede ser un servicio independiente.

El costo: latencia por objeto

HTTPS tiene overhead por request: TLS handshake, headers, JSON parsing. Para mover una serie de 1.500 imágenes con un GET por imagen, eso puede sumar minutos solo en overhead. Por eso DICOMweb maduro usa multipart por serie (un único GET trae todas las imágenes de la serie en streaming) y HTTP/2 o HTTP/3 para multiplexing real. Sin esto, DICOMweb sin afinar puede sentirse más lento que DIMSE en LAN.

Tabla comparativa honesta

Eje	DIMSE	DICOMweb
Transporte	TCP binario, puerto propio	HTTPS estándar
Atravesar firewalls/NAT	Doloroso (VPN o túnel)	Trivial (443)
Autenticación	AE Title + IP (allowlist)	Bearer token, OAuth, mTLS
Performance en LAN	Excelente, baja overhead	Bueno con HTTP/2 y multipart; pobre sin afinar
Performance sobre Internet	Mala sin VPN	Excelente
Visores web en browser	Imposible directo	Nativo
Cloud y microservicios	Forzado, raro	Diseñado para eso
Configuración nuevo nodo	Manual en cada extremo	Token, sin cambios en server
Soporte del ecosistema legacy	Universal (cualquier PACS)	Bueno en PACS modernos; parcial en legacy
Reverse proxy / load balancer	Complejo	Estándar (nginx, HAProxy)

Cuándo elegir cuál (en la práctica)

Usá DIMSE cuando…

• El equipo de imágenes es la fuente. Los tomógrafos, resonadores y ecógrafos hablan DIMSE nativo (C-STORE hacia el PACS). Esto no se cambia — es lo que el fabricante del equipo trae.
• Hay un PACS legacy que solo soporta DIMSE. Muchos PACS instalados antes de 2018 no tienen DICOMweb completo.
• Estás dentro de la LAN del centro y la red es buena. Para un visor diagnóstico interno con conexión gigabit, DIMSE es eficientísimo.
• Necesitás interoperabilidad universal. Cualquier sistema DICOM-compatible habla DIMSE; no todos hablan DICOMweb completo.

Usá DICOMweb cuando…

• Hay un visor web o app móvil involucrada. No hay alternativa práctica.
• Necesitás acceso remoto sin VPN. Radiólogo en su casa, médico de cabecera consultando, paciente accediendo a sus imágenes.
• Estás armando una arquitectura cloud o multi-centro. El tráfico DIMSE entre regiones cloud es un dolor; HTTPS no.
• Querés integraciones con apps externas (segundas opiniones, IA en cloud, portales de paciente).
• Te importan los tokens revocables. Echar a un proveedor que tenía DIMSE significa cambiar AE Titles e IPs en el firewall. Echar a uno con token DICOMweb: DELETE /tokens/X.

Mitos que conviene desarmar

"DICOMweb reemplaza a DIMSE." Falso. Coexisten en casi todos los PACS modernos. DIMSE va a seguir vivo mientras existan modalidades viejas, y son muchas.

"DICOMweb es más seguro porque usa HTTPS." Más fácil de asegurar, no necesariamente más seguro. Un DIMSE sobre VPN bien configurada es seguro. Un DICOMweb con tokens débiles, no.

"Si el PACS dice 'soporta DICOMweb', está todo bien." Mirá el detalle. ¿Soporta QIDO, WADO y STOW? ¿En qué versión? ¿Soporta multipart? ¿Tiene rendered resources? La diferencia entre "DICOMweb mínimo" y "DICOMweb completo" es enorme.

Cómo soportan los visores actuales

Una mirada rápida a lo que se ve en el mercado:

• OHIF Viewer — nativo DICOMweb. Ideal para frontends web. DIMSE solo vía gateway.
• Weasis — DIMSE nativo, DICOMweb cliente bueno (DCM4CHEE-friendly).
• Horos, RadiAnt, OsiriX — DIMSE de primera, DICOMweb variable o parcial.
• PACS comerciales top tier (Sectra, Philips, GE) — soportan ambos completos, pero las APIs DICOMweb a veces tienen restricciones de licencia (te cobran por habilitarlas).
• Servidores DICOM open source — DCM4CHEE, Orthanc, Dicoogle: soportan ambos.
• IMARAD — soporta ambos en el modo Servidor DICOM, y el visor cliente puede usar uno u otro según el origen.

Esto es importante a la hora de elegir: "tiene visor web" suele significar "soporta DICOMweb", pero "abre archivos DICOM" no implica que pueda integrarse con tu PACS.

Recomendaciones para elegir un visor o partner PACS

1. Pedí el DICOM conformance statement. Es un documento estandarizado que detalla qué SOP classes y qué servicios soporta. Cualquier fabricante serio lo entrega. Si dudan, mala señal.
2. Probá un C-ECHO desde tu modalidad al visor o servidor. Si falla, no avances.
3. Probá un C-MOVE de un estudio real desde tu PACS. Cronometrá. Si tarda más que el PACS actual, hay tuning pendiente.
4. Si vas a usar DICOMweb, verificá que soporte multipart y rendered. Sin estos, la experiencia va a ser pobre.
5. Pedí ejemplos de instalaciones reales. Centros de tamaño similar al tuyo, no demos.

Cómo se enfoca IMARAD

Conclusión

DICOMweb no reemplaza a DIMSE; lo complementa. Los visores y PACS modernos hablan ambos porque cada uno gana en escenarios distintos: DIMSE en LAN, DICOMweb en cloud y web. Lo que sí está cambiando es que las arquitecturas nuevas (visores web, multi-centro, IA en cloud, portales de paciente) se diseñan DICOMweb-first y agregan DIMSE como adaptador, no al revés.

Si estás eligiendo un visor o un PACS hoy, no aceptes "tiene DICOM" como respuesta. Preguntá qué servicios de cada familia soporta. La respuesta detallada predice cuánto vas a sufrir la integración en los próximos 5 años.