![\"Estaci\u00f3n](\"https:\/\/rtmedical.com.br\/wp-content\/uploads\/2026\/02\/dicom-network-medical-imaging.jpeg\")
En Este Art\u00edculo<\/h2>\n\n- 1. Application Entities y Configuraci\u00f3n de Red<\/a><\/li>\n
- 2. Servicios y Datos: El Modelo SCU\/SCP<\/a><\/li>\n
- 3. DIMSE: El Lenguaje de la Red DICOM<\/a><\/li>\n
- 4. C-Echo: El Ping DICOM<\/a><\/li>\n
- 5. Errores Comunes de Configuraci\u00f3n<\/a><\/li>\n
- 6. Limitaciones y Cu\u00e1ndo No Usar<\/a><\/li>\n<\/ul>\n<\/div>\n
Application Entities: Identificando Dispositivos en la Red DICOM<\/h2>\n
Cada dispositivo en una red TCP\/IP tiene su propia direcci\u00f3n IP \u2014 eso ya lo sabes. Pero en el universo DICOM, existe una capa adicional de identificaci\u00f3n: la Application Entity (AE)<\/strong>. Una AE corresponde a cualquier aplicaci\u00f3n DICOM ejecut\u00e1ndose en un dispositivo de red, ya sea un servidor de archivo (PACS), una estaci\u00f3n de visualizaci\u00f3n, una impresora DICOM o una modalidad de adquisici\u00f3n como un tom\u00f3grafo.<\/p>\nAdem\u00e1s de la direcci\u00f3n IP est\u00e1ndar, cada AE recibe un nombre exclusivo llamado Application Entity Title (AET)<\/strong>. El AET puede tener hasta 16 caracteres y, en la pr\u00e1ctica, se recomienda usar nombres intuitivos como PACSSERVER<\/code>, CTWORKSTATION1<\/code> o ARCHIVE<\/code> \u2014 preferiblemente en may\u00fasculas, sin espacios ni caracteres especiales.<\/p>\n\nConsejo Pr\u00e1ctico:<\/strong> Cuando el software PACS se instale en tu sitio, exige que los AETs sean asignados de forma clara y consistente. Algunos fabricantes son famosos por usar t\u00edtulos confusos \u2014 no lo aceptes.\n<\/div>\nAE = Aplicaci\u00f3n, No Computadora<\/h3>\n
Un detalle fundamental que muchos ignoran: los AE titles identifican aplicaciones<\/em>, no m\u00e1quinas. Nada impide que una sola computadora ejecute varias aplicaciones DICOM simult\u00e1neamente \u2014 servidor, estaci\u00f3n de trabajo, servidor de impresi\u00f3n. En la pr\u00e1ctica, esto es bastante com\u00fan. Cada aplicaci\u00f3n recibe un AET diferente, y los otros dispositivos de la red pueden comunicarse con una aplicaci\u00f3n espec\u00edfica, no con toda la m\u00e1quina.<\/p>\nPara configurar tu dispositivo en la red DICOM, tres par\u00e1metros son esenciales:<\/p>\n
\n- AET (AE Title)<\/strong> \u2014 alfanum\u00e9rico, hasta 16 caracteres. Piensa en nombres como
CTWORKSTATION1<\/code> o PACS_SERVER<\/code>.<\/li>\n- Direcci\u00f3n IP de la AE<\/strong> \u2014 debe ser reservada y fija para esa aplicaci\u00f3n.<\/li>\n
- N\u00famero de puerto<\/strong> \u2014 el puerto predeterminado DICOM es el 104, pero cualquier puerto disponible funciona, siempre que sea consistente en toda la red.<\/li>\n<\/ol>\n
![\"Interfaz](\"data:image\/svg+xml;base64,PHN2ZyB3aWR0aD0iMSIgaGVpZ2h0PSIxIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjwvc3ZnPg==\")
Interfaz de Modality Worklist con campos de AE Title, datos del paciente y programaci\u00f3n de procedimientos<\/figcaption><\/figure>\nEl puerto juega un papel crucial cuando existen varias aplicaciones DICOM en la misma computadora. Mientras los AETs diferentes identifican cada aplicaci\u00f3n, los puertos diferentes las separan en la capa de red. Una misma AE puede incluso tener dos puertos: uno para env\u00edo y otro para recepci\u00f3n \u2014 funcionalidad que la mayor\u00eda del software DICOM moderno soporta.<\/p>\n
\nNota T\u00e9cnica:<\/strong> Aunque el est\u00e1ndar DICOM no lo exige, muchos fabricantes implementan verificaci\u00f3n mutua de AE. Es decir, si la AE X quiere conectarse a la AE Y, no basta con que X conozca a Y \u2014 Y tambi\u00e9n debe tener registrada a X. Configura siempre sim\u00e9tricamente: al agregar la configuraci\u00f3n de X en Y, agrega tambi\u00e9n la de Y en X.\n<\/div>\nServicios y Datos: El Modelo SCU\/SCP<\/h2>\n
El modelo de comunicaci\u00f3n adoptado por DICOM es elegante en su simplicidad conceptual: las Application Entities se prestan servicios<\/em> entre s\u00ed. Una AE puede solicitar un servicio a otra, y esa otra proporciona el servicio solicitado.<\/p>\nEn la terminolog\u00eda DICOM, la AE que solicita un servicio es el Service Class User (SCU)<\/strong>, y la que lo proporciona es el Service Class Provider (SCP)<\/strong>. Por ejemplo, cuando un tom\u00f3grafo env\u00eda im\u00e1genes a un archivo digital, el tom\u00f3grafo act\u00faa como SCU y el archivo como SCP del servicio de almacenamiento.<\/p>\n
Application Entities: Identificando Dispositivos en la Red DICOM<\/h2>\n
Cada dispositivo en una red TCP\/IP tiene su propia direcci\u00f3n IP \u2014 eso ya lo sabes. Pero en el universo DICOM, existe una capa adicional de identificaci\u00f3n: la Application Entity (AE)<\/strong>. Una AE corresponde a cualquier aplicaci\u00f3n DICOM ejecut\u00e1ndose en un dispositivo de red, ya sea un servidor de archivo (PACS), una estaci\u00f3n de visualizaci\u00f3n, una impresora DICOM o una modalidad de adquisici\u00f3n como un tom\u00f3grafo.<\/p>\n Adem\u00e1s de la direcci\u00f3n IP est\u00e1ndar, cada AE recibe un nombre exclusivo llamado Application Entity Title (AET)<\/strong>. El AET puede tener hasta 16 caracteres y, en la pr\u00e1ctica, se recomienda usar nombres intuitivos como Un detalle fundamental que muchos ignoran: los AE titles identifican aplicaciones<\/em>, no m\u00e1quinas. Nada impide que una sola computadora ejecute varias aplicaciones DICOM simult\u00e1neamente \u2014 servidor, estaci\u00f3n de trabajo, servidor de impresi\u00f3n. En la pr\u00e1ctica, esto es bastante com\u00fan. Cada aplicaci\u00f3n recibe un AET diferente, y los otros dispositivos de la red pueden comunicarse con una aplicaci\u00f3n espec\u00edfica, no con toda la m\u00e1quina.<\/p>\n Para configurar tu dispositivo en la red DICOM, tres par\u00e1metros son esenciales:<\/p>\n El puerto juega un papel crucial cuando existen varias aplicaciones DICOM en la misma computadora. Mientras los AETs diferentes identifican cada aplicaci\u00f3n, los puertos diferentes las separan en la capa de red. Una misma AE puede incluso tener dos puertos: uno para env\u00edo y otro para recepci\u00f3n \u2014 funcionalidad que la mayor\u00eda del software DICOM moderno soporta.<\/p>\n El modelo de comunicaci\u00f3n adoptado por DICOM es elegante en su simplicidad conceptual: las Application Entities se prestan servicios<\/em> entre s\u00ed. Una AE puede solicitar un servicio a otra, y esa otra proporciona el servicio solicitado.<\/p>\n En la terminolog\u00eda DICOM, la AE que solicita un servicio es el Service Class User (SCU)<\/strong>, y la que lo proporciona es el Service Class Provider (SCP)<\/strong>. Por ejemplo, cuando un tom\u00f3grafo env\u00eda im\u00e1genes a un archivo digital, el tom\u00f3grafo act\u00faa como SCU y el archivo como SCP del servicio de almacenamiento.<\/p>\nPACSSERVER<\/code>, CTWORKSTATION1<\/code> o ARCHIVE<\/code> \u2014 preferiblemente en may\u00fasculas, sin espacios ni caracteres especiales.<\/p>\nAE = Aplicaci\u00f3n, No Computadora<\/h3>\n
\n
CTWORKSTATION1<\/code> o PACS_SERVER<\/code>.<\/li>\n![\"Interfaz](\"https:\/\/rtmedical.com.br\/wp-content\/uploads\/2026\/02\/dicom-modality-worklist-interface.jpeg\")
Servicios y Datos: El Modelo SCU\/SCP<\/h2>\n
![\"Profesional](\"https:\/\/rtmedical.com.br\/wp-content\/uploads\/2026\/02\/dicom-radiology-workstation.jpeg\")
![\"Sistema](\"https:\/\/rtmedical.com.br\/wp-content\/uploads\/2026\/02\/dicom-pacs-hospital-system.jpeg\")