¿Cómo Funciona la Comunicación en la Red DICOM?
Si trabajas con sistemas de imagen médica, probablemente te has preguntado por qué dos equipos DICOM simplemente “no se comunican” entre sí, incluso estando en la misma red. La respuesta casi siempre está en la configuración de los protocolos de comunicación DICOM — un tema que muchos profesionales de salud y TI subestiman hasta enfrentar problemas reales de integración.
La comunicación DICOM va mucho más allá de un simple formato de archivo de imagen. En realidad, el estándar define un lenguaje completo de servicios de red que orquesta todo el flujo de trabajo clínico digital. Para una visión integral del ecosistema DICOM, consulta nuestra guía completa sobre DICOM en la práctica clínica.
En Este Artículo
Application Entities: Identificando Dispositivos en la Red DICOM
Cada dispositivo en una red TCP/IP tiene su propia dirección IP — eso ya lo sabes. Pero en el universo DICOM, existe una capa adicional de identificación: la Application Entity (AE). Una AE corresponde a cualquier aplicación DICOM ejecutándose en un dispositivo de red, ya sea un servidor de archivo (PACS), una estación de visualización, una impresora DICOM o una modalidad de adquisición como un tomógrafo.
Además de la dirección IP estándar, cada AE recibe un nombre exclusivo llamado Application Entity Title (AET). El AET puede tener hasta 16 caracteres y, en la práctica, se recomienda usar nombres intuitivos como PACSSERVER, CTWORKSTATION1 o ARCHIVE — preferiblemente en mayúsculas, sin espacios ni caracteres especiales.
AE = Aplicación, No Computadora
Un detalle fundamental que muchos ignoran: los AE titles identifican aplicaciones, no máquinas. Nada impide que una sola computadora ejecute varias aplicaciones DICOM simultáneamente — servidor, estación de trabajo, servidor de impresión. En la práctica, esto es bastante común. Cada aplicación recibe un AET diferente, y los otros dispositivos de la red pueden comunicarse con una aplicación específica, no con toda la máquina.
Para configurar tu dispositivo en la red DICOM, tres parámetros son esenciales:
- AET (AE Title) — alfanumérico, hasta 16 caracteres. Piensa en nombres como
CTWORKSTATION1oPACS_SERVER. - Dirección IP de la AE — debe ser reservada y fija para esa aplicación.
- Número de puerto — el puerto predeterminado DICOM es el 104, pero cualquier puerto disponible funciona, siempre que sea consistente en toda la red.
El puerto juega un papel crucial cuando existen varias aplicaciones DICOM en la misma computadora. Mientras los AETs diferentes identifican cada aplicación, los puertos diferentes las separan en la capa de red. Una misma AE puede incluso tener dos puertos: uno para envío y otro para recepción — funcionalidad que la mayoría del software DICOM moderno soporta.
Servicios y Datos: El Modelo SCU/SCP
El modelo de comunicación adoptado por DICOM es elegante en su simplicidad conceptual: las Application Entities se prestan servicios entre sí. Una AE puede solicitar un servicio a otra, y esa otra proporciona el servicio solicitado.
En la terminología DICOM, la AE que solicita un servicio es el Service Class User (SCU), y la que lo proporciona es el Service Class Provider (SCP). Por ejemplo, cuando un tomógrafo envía imágenes a un archivo digital, el tomógrafo actúa como SCU y el archivo como SCP del servicio de almacenamiento.
Los DICOM Service Classes asocian uno o más Information Objects (IODs) con uno o más comandos. Si esto suena abstracto, piensa en la impresión de imágenes: el Print Management Service Class combina el comando de impresión con los IODs de imagen (CT, RM, etc.). Cualquier impresora DICOM puede actuar como SCP de este servicio, y cualquier dispositivo que envíe imágenes para imprimir actúa como SCU.
Este modelo es la base de toda la comunicación DICOM. Si ya leíste sobre la estructura de objetos y datos DICOM, verás cómo servicios y datos se complementan naturalmente.
DIMSE: El Lenguaje de Servicios de la Red DICOM
¿Cómo solicitan servicios las AEs entre sí? De la misma forma que los humanos: enviando mensajes. En DICOM, estos mensajes de servicio se llaman DICOM Message Service Elements (DIMSE). El protocolo DIMSE establece las reglas para el intercambio de servicios — la columna vertebral de la comunicación DICOM en red.
Cada servicio DIMSE generalmente tiene dos componentes: un mensaje de request (solicitud) y uno de response (respuesta). Los requests los envían las AEs SCU — por ejemplo, un tomógrafo intentando almacenar una imagen en el archivo — y los responses los proporcionan las AEs SCP.
Command Objects vs. Data Objects
DICOM necesita distinguir atributos de servicio de atributos de datos. Para ello, reserva el grupo 0000 para todas las tags de servicio, llamando a estos objetos DICOM Command Objects. Los datos propiamente dichos (imágenes, información del paciente) van en los grupos 0008 en adelante, como Data Objects.
Cuando un servicio necesita transferir datos junto con el comando, el atributo Data Set Type (0000, 0800) lo indica. Si su valor es 0101 (NULL en DICOM), no hay datos adjuntos. Cualquier otro valor significa que un Data Object sigue inmediatamente después del Command Object. Los servicios DICOM funcionan como “lanzaderas” que transportan datos entre Application Entities.
Los servicios DIMSE que manejan datos compuestos se llaman DIMSE-C (como C-Store para almacenar imágenes), y los que manejan datos normalizados son DIMSE-N. El prefijo “C” o “N” identifica el tipo de datos que el servicio manipula.
C-Echo: El “Ping DICOM” que Te Salva el Día
El C-Echo es, con diferencia, el servicio DIMSE más simple — y probablemente el que más usarás en la práctica. Verifica si dos AEs DICOM están correctamente conectadas. Es el famoso “DICOM ping”.
Atención: no basta con que dos dispositivos estén físicamente conectados por cable de red. Tampoco basta con poder hacer un ping TCP/IP entre ellos. Un ping exitoso solo prueba que los dispositivos están en la misma red TCP/IP — no garantiza absolutamente nada sobre la conectividad DICOM. La única forma de confirmar que dos AEs están correctamente configuradas es hacer un C-Echo de una a la otra.
Cómo Funciona el C-Echo
El flujo es directo: la AE solicitante envía un C-Echo-Rq (request). Si la AE receptora responde con un C-Echo-Rsp (response) válido, las dos están correctamente conectadas a nivel DICOM. El C-Echo es puramente un Command Object — no transporta ningún dato (el Data Set Type es 0101, o NULL).
Campos importantes en el mensaje C-Echo:
- Affected Service Class UID:
1.2.840.10008.1.1— identificador único del servicio C-Echo - Command Field:
0030para Rq,8030para Rsp (el dígito 8 diferencia respuestas de solicitudes) - Message ID: número único de 2 bytes que identifica cada mensaje durante su breve vida
- Status:
0000en C-Echo-Rsp indica éxito
El C-Echo se considera fallido solo si no regresa ninguna respuesta dentro del intervalo de timeout (generalmente pocos segundos). Para otros servicios DIMSE más complejos, valores distintos de cero en el campo Status indican warnings o errores.
Errores Comunes en la Configuración DICOM de Red
En mi experiencia trabajando con integraciones DICOM, estos son los errores que más veo en campo:
- Configuración asimétrica de AE: Agregar la configuración del escáner en el archivo, pero olvidar agregar la del archivo en el escáner. Resultado: nada funciona, y lleva otro día programar soporte.
- Conflicto de puertos: Usar el mismo puerto para dos aplicaciones DICOM diferentes en la misma computadora, o insistir en el puerto 104 cuando ya está ocupado. Buena práctica: usar puertos altos (10000+) cuando no se quiera el predeterminado.
- AET con caracteres especiales: Usar espacios, acentos o puntuación en los AE Titles. Aunque técnicamente posible con algunos softwares, es receta para problemas de interoperabilidad.
Limitaciones y Cuándo No Usar DIMSE Tradicional
Aunque DIMSE ha sido la base de la comunicación DICOM durante décadas, no es solución para todo:
- Rendimiento a gran escala: El protocolo DIMSE tradicional puede ser lento para transferencia masiva de datos. Protocolos como DICOMweb (WADO-RS, STOW-RS) son alternativas más modernas basadas en HTTP/REST.
- Redes no locales: DIMSE fue diseñado para LANs. Para comunicación por internet o entre sitios distantes, considera DICOMweb o soluciones con VPN.
- Integración con sistemas no-DICOM: Cuando la interoperabilidad involucra HL7 FHIR u otros estándares, DIMSE solo no resuelve. Necesitas capas de integración adicionales.
Si quieres entender cómo estos protocolos se integran con comandos y objetos DICOM más complejos, consulta el análisis detallado sobre comandos y objetos DICOM.
Próximos Pasos
Dominar la comunicación DICOM es esencial para cualquier profesional que trabaje con sistemas de imagen médica. Con los conceptos de AE, SCU/SCP y DIMSE que exploramos aquí, tienes la base necesaria para diagnosticar problemas de conectividad, configurar nuevos dispositivos y entender lo que realmente sucede cuando tus equipos “conversan” en la red.
Si estás planificando una nueva integración o enfrentando problemas de comunicación entre dispositivos, comienza siempre por el C-Echo — es el diagnóstico más rápido y confiable que existe en el mundo DICOM.
