La consulta de ultrasonido funciona pero la recuperación falla: rastree la conexión C-MOVE independiente

¿Por qué la consulta puede tener éxito mientras que cada recuperación falla?

Pocos síntomas de red confunden más a los equipos de servicio que un sistema de ultrasonido que puede buscar en el sistema de archivo y comunicación de imágenes (PACS) del hospital sin errores, pero falla cada vez que un ecografista intenta recuperar un estudio previo. La consola lista los estudios del paciente, el operador selecciona uno y presiona Retrieve, y tras una pausa el sistema informa una falla genérica de transferencia o de recuperación. La formulación exacta varía según el fabricante y la versión del software.

La suposición intuitiva es que la conectividad de red es simétrica: si el escáner puede realizar búsquedas en el archivo, la vía de comunicación funciona, por lo que una falla de recuperación debe significar una falla interna del escáner, una opción de software dañada o una placa de entrada/salida (I/O) de red defectuosa. Para la recuperación mediante C-MOVE en DICOM (Digital Imaging and Communications in Medicine), esa suposición es errónea. La consulta y la recuperación utilizan operaciones distintas y, en el caso de C-MOVE, diferentes asociaciones de red abiertas en direcciones opuestas. ^{1 5}

Cuando un sistema de ultrasonido ejecuta una consulta, actúa como usuario de clase de servicio (SCU, Service Class User) de la Query/Retrieve Service Class y utiliza la operación C-FIND. ⁹ El escáner abre una conexión TCP hacia la dirección IP configurada y el puerto de escucha del archivo. El puerto 104 es el puerto conocido de DICOM, pero los puertos se configuran según el sitio; en la familia Philips citada a continuación, el puerto de escucha está predeterminado en 104 y cambia a 2762 cuando Secure DICOM está habilitado. ³ El escáner solicita una asociación utilizando su propio AE Title (calling) y el AE Title (called) del archivo, envía la solicitud C-FIND con claves de búsqueda tales como ID de paciente, nombre o fecha del estudio, y recibe las coincidencias a través de esa misma asociación.

Cuando el ecografista presiona Retrieve, el escáner no descarga archivos a través de esa asociación. Envía una solicitud C-MOVE que pide al archivo entregar las instancias seleccionadas a un Move Destination AE Title designado. DICOM PS3.4, sección C.4.2, establece que las suboperaciones C-STORE “deberán realizarse siempre a través de una asociación diferente de la asociación que lleva a cabo la operación C-MOVE”, actuando el Query/Retrieve SCP como Storage SCU. ¹

La razón se encuentra en la misma sección: la entidad de aplicación que recibe las instancias almacenadas “puede o no ser quien originó la operación C-MOVE”. C-MOVE está diseñado de modo que un solicitante pueda enviar un estudio a un tercer sistema, como una estación de trabajo de revisión. Por esta razón, el archivo, y no el solicitante, abre la conexión de entrega, incluso cuando el escáner solicita que las imágenes se devuelvan a sí mismo. ¹

Por lo tanto, una consulta exitosa solo demuestra que el escáner puede alcanzar el puerto de escucha del archivo. No demuestra que la ruta inversa, desde el archivo hacia el puerto de escucha del destino, esté configurada, permitida por los firewalls o aceptada por el receptor DICOM del escáner. Antes de sospechar del hardware, separe las fallas de almacenamiento del lado del escáner de las fallas en la dirección de recuperación rastreando cada asociación por separado.

¿Cuáles son los tres extremos y las dos asociaciones en una recuperación de ultrasonido?

Para diagnosticar con precisión una falla de C-MOVE, un ingeniero debe reconocer que una recuperación DICOM involucra tres extremos lógicos distintos y dos asociaciones de red independientes, incluso cuando el sistema de ultrasonido solicita que las imágenes se le entreguen a sí mismo. DICOM PS3.4, sección C.4.2, define estos roles con precisión técnica: ¹

• SCU solicitante (consola de ultrasonido): El sistema que inicia la asociación 1 con el archivo, emite solicitudes de consulta C-FIND y emite el comando de recuperación C-MOVE. Identifica qué estudios, series o instancias transferir y designa el Move Destination AE Title.
• Query/Retrieve SCP (archivo PACS o VNA): acepta la asociación 1, busca las coincidencias de la consulta, recibe el C-MOVE, busca el AE Title de Move Destination en su propia configuración y actúa como Storage SCU para enviar las instancias.
• Move Destination (Storage SCP): el nodo designado en la solicitud C-MOVE para recibir las imágenes. A menudo es el mismo ecógrafo que realizó la solicitud, pero el estándar permite cualquier nodo de almacenamiento, como una estación de trabajo de revisión. En la familia Philips citada aquí, el ecógrafo designa su propio AE Title como destino. ^{1 3 5}

Debido a que el Move Destination puede ser un nodo de terceros, el protocolo C-MOVE fue diseñado deliberadamente para que el archivo inicie la conexión de entrega. Esto genera dos asociaciones de red distintas con direcciones de conexión opuestas:

Asociación 1 (asociación de solicitud directa): Iniciada por el SCU de ultrasonido hacia el SCP Q/R del PACS. Esta asociación gestiona la negociación A-ASSOCIATE, el intercambio de consultas C-FIND, la solicitud C-MOVE, las respuestas periódicas de estado pendiente de C-MOVE y la respuesta final de finalización de C-MOVE. Si esta asociación falla, el equipo de ultrasonido no puede buscar pacientes ni enviar el comando de recuperación inicial.

Asociación 2 (asociación de almacenamiento inversa): abierta por el archivo, actuando como Storage SCU, hacia el Move Destination, actuando como Storage SCP, después de que el archivo recibe la solicitud C-MOVE. Transporta una solicitud C-STORE por instancia, ya sea imagen, cine o informe estructurado. Si esta asociación no se puede abrir, está bloqueada por un firewall o es rechazada por el receptor, las suboperaciones fallan mientras que la asociación 1 sigue funcionando. ^{1 2 6}

El Anexo F de PS3.2 ilustra la misma división en un ejemplo informativo de declaración de conformidad para un servidor ficticio de consulta y recuperación. Allí, la entidad de aplicación QUERY-RETRIEVE-SCP “nunca iniciará asociaciones”; ante un C-MOVE, ordena a una entidad de aplicación STORAGE-SCU independiente “iniciar una asociación con el AE DICOM de destino”. Su Tabla F.4.2-8 muestra que un tiempo de espera agotado, una interrupción o una pérdida de socket en esa asociación de entrega se notifica y se envía un estado adecuado en la respuesta C-MOVE. Los productos reales implementan esto de manera diferente, pero la dirección de la segunda conexión es la misma. ²

¿Qué le indica realmente la respuesta final de C-MOVE?

La mayoría de las consolas solo muestran una breve ventana emergente cuando falla una recuperación. Encontrará evidencia más útil en la respuesta C-MOVE devuelta a través de la asociación 1, habitualmente visible en el registro DICOM del archivo y, en ocasiones, en el registro de servicio del ecógrafo. La tabla C.4-2 de PS3.4 enumera los estados de C-MOVE bajo Failure (rechazado, error o incapaz de procesar), Cancel, Warning, Success y Pending. ¹

PS3.4 también define atributos de recuento de suboperaciones. Las respuestas Pending deben incluirlos. Las respuestas finales pueden incluir algunos de ellos, por lo que la ausencia de un recuento no constituye en sí misma un error:

• Número de suboperaciones restantes (0000,1020): instancias que aún quedan por enviar. Obligatorio en respuestas Pending, opcional en Cancel y no incluido en respuestas Warning, Failure o Success.
• Número de suboperaciones completadas (0000,1021): suboperaciones C-STORE que se completaron con éxito. Obligatorio en respuestas Pending, opcional en respuestas finales.
• Número de suboperaciones fallidas (0000,1022): suboperaciones C-STORE que fallaron. Obligatorio en respuestas Pending, opcional en respuestas finales.
• Número de suboperaciones con advertencia (0000,1023): suboperaciones que finalizaron con un estado de advertencia.
• Lista de UID de instancias SOP fallidas (0008,0058): en respuestas Cancel, Failure o Warning, los identificadores de las instancias cuyo C-STORE falló. Está ausente cuando ninguna suboperación ha fallado. ¹

Lea el estado y los recuentos conjuntamente. Un fallo con cero completadas y todas las instancias fallidas significa que no se entregó nada. Por lo general, esto apunta a la propia asociación, pero un archivo puede generar el mismo patrón cuando el destino rechaza todos los tipos de objetos. Tener tanto las completadas como las fallidas por encima de cero significa que la ruta inversa funciona al menos para algunas instancias, y que el problema reside en objetos determinados, codificaciones o recursos del destino. Los recuentos delimitan la búsqueda; el registro del archivo muestra el motivo. ^{1 5}

La lista de UID de instancias SOP fallidas (0008,0058) suele ser el atributo más útil después del estado. Para una transferencia parcial, compare los UID fallidos con el registro de cada objeto en el archivo. Si cada elemento fallido es un clip de cine multifotograma mientras que las imágenes de un solo fotograma llegaron, una incompatibilidad de sintaxis de transferencia o de contexto de presentación es un firme candidato. Confírmelo en el registro de asociación del archivo antes de modificar nada.

¿Qué identifica Rechazado: destino de movimiento desconocido (A801)?

El estado A801 (Rechazado: destino de movimiento desconocido) es uno de los códigos más específicos que puede recibir, y una lección neutral de capacitación sobre PACS describe un destino desconocido como la causa más común de movimientos fallidos. Significa que el archivo no pudo resolver el AE Title designado como destino. ^{1 4 5}

La solicitud C-MOVE contiene el destino únicamente como un AE Title en Move Destination (0000,0600), sin dirección IP ni puerto. ¹ El archivo debe traducir ese AE Title a una dirección y un puerto a partir de su propia configuración. Medical Connections, un proveedor de herramientas DICOM, señala que, por oneroso que esto parezca, “DICOM no permite ninguna alternativa”. ⁶

Si el archivo no encuentra ninguna entrada coincidente, no tiene una dirección a la que conectarse y rechaza la solicitud con A801. No se intenta ninguna suboperación. PS3.4 enumera únicamente un comentario de error como campo relacionado para este estado, por lo que no espere recuentos significativos de suboperaciones. ^{1 4}

Las causas clínicas comunes del estado A801 incluyen:

• Ecógrafo nuevo o reinstalado: el ecógrafo se configuró para enviar estudios al PACS, pero nadie agregó su AE Title, dirección IP y puerto como destino de recuperación en el archivo.
• Discrepancia en la cadena exacta: un AE Title tiene como máximo 16 caracteres, y PS3.5 considera no significativos los espacios iniciales y finales. ¹² Los caracteres internos siguen siendo relevantes. Compare las cadenas carácter por carácter, incluidas las mayúsculas y minúsculas, los guiones bajos frente a los guiones y la letra O frente al cero, en lugar de asumir que cualquiera de los dos sistemas las normalizará.
• Diferentes AE Titles para envío y recepción: algunos sistemas permiten que la consola utilice un AE Title para el almacenamiento y designe otro como su destino de recuperación. Si en el archivo solo está registrado el título de envío, el título de destino es desconocido.
• Destino incorrecto ingresado en el ecógrafo: la consola especifica un destino que difiere del registro que creó el administrador del PACS. En ese caso, la corrección corresponde al lado del ecógrafo, bajo control de cambios.

Un A801 no da motivos para reemplazar el hardware de red ni para cambiar los puertos del conmutador. La solución consiste en hacer que el AE Title de destino que envía el ecógrafo coincida con un registro de nodo en el archivo que contenga la dirección IP actual y el puerto de escucha del ecógrafo. El registro del archivo corresponde al administrador del PACS; la configuración de destino en el propio ecógrafo corresponde a quien realice el servicio técnico del ecógrafo.

¿Qué significa cuando el destino rechaza la asociación del archivo?

Si el archivo resuelve el destino, intenta abrir la asociación 2 hacia esa dirección IP y puerto. La forma en que notifica un fallo en este punto depende de la implementación. El sistema de gestión de datos Canon HCBA-01, por ejemplo, documenta A702 cuando “las suboperaciones C-STORE no pueden realizarse debido al fallo de una Solicitud de Asociación o de una Solicitud C-STORE”. Otros archivos pueden utilizar un estado diferente, por lo que coteje el código con la propia declaración de conformidad de ese archivo. ⁴

Un fallo en esta etapa se divide en dos escenarios de ingeniería distintos: bloqueo del transporte de red y rechazo de la asociación a nivel de aplicación.

1. Bloqueo del transporte de red (rechazo de conexión TCP): El servidor PACS intenta enviar un paquete TCP SYN a la dirección IP del ecógrafo en su puerto de escucha configurado, pero recibe un paquete TCP RST (conexión rechazada) o ninguna respuesta en absoluto (tiempo de espera agotado de SYN). Esto ocurre cuando:

• El servicio de escucha DICOM del ecógrafo está detenido o deshabilitado en el software.
• Un firewall de host en la consola, donde la plataforma disponga de uno, bloquea las conexiones entrantes en el puerto de escucha.
• Los firewalls de la red departamental o las listas de control de acceso (ACL) de redes de área local virtuales (VLAN) permiten el tráfico saliente desde las modalidades médicas hacia el PACS, pero bloquean el tráfico entrante iniciado desde la sala de servidores de regreso hacia los carros de ultrasonido clínicos. ⁵

2. Rechazo de la asociación a nivel de aplicación (A-ASSOCIATE-RJ): la conexión TCP se establece con éxito, pero el destino rechaza la asociación DICOM. Philips documenta esto como el mecanismo en el que la consulta funciona pero la recuperación falla para la familia EPIQ Elite, Elite Advanced, E7, E5, CVx, CVxi y Affiniti 70/50/30 Release 6.0.x (000737000000163 Rev A, sección 4.1.2.1): ³

“Debe utilizarse un segundo dispositivo ‘DICOM Storage Server’ en el sistema de ultrasonido para agregar el AE Title emisor del servidor para la asociación C-Store iniciada por la solicitud C-Move enviada al servidor Query Retrieve. Sin este segundo dispositivo, la consulta tendrá éxito, pero la recuperación fallará porque el sistema de ultrasonido rechazará cualquier solicitud de asociación procedente de un AE Title ‘desconocido’.”— Declaración de conformidad DICOM de Philips EPIQ/Affiniti Release 6.0.x, 000737000000163 Rev A, sección 4.1.2.1 (ortografía tal como en la fuente)

La sección de configuración del mismo documento añade dos detalles que resultan importantes durante el servicio técnico. En primer lugar, el archivo “por lo general utilizará un AE Title diferente” para el C-STORE respecto al que consulta el ecógrafo, por lo que el ecógrafo necesita una entrada adicional de Storage Device con ese AE Title emisor y la dirección IP o el nombre de host del archivo. En segundo lugar, debido a que el archivo no realiza envíos desde un puerto fijo, Philips indica que se puede ingresar un puerto provisional tal como 9999, y se espera que la verificación automática falle tras guardar dicha entrada; “Eso no es un error”. Para transferencias no solicitadas, el documento exige del mismo modo que el AE Title y la dirección IP del emisor se configuren con antelación. ³

En esa familia, el ecógrafo acepta hasta cinco asociaciones de almacenamiento simultáneas (tabla 4.4), un valor que la tabla de configuración indica como no configurable. Si un archivo abre más asociaciones de entrega paralelas hacia un destino de las que el destino acepta, las asociaciones adicionales pueden ser rechazadas, por lo que compare el ajuste de concurrencia por destino del archivo con el límite documentado del destino. No asuma que ese límite se aplica a otros modelos o versiones. ³

En la misma familia, Query/Retrieve es una opción: la nota al pie del resumen indica que “Requiere la opción ‘Ultrasound Query Retrieve’ o ‘Multi-Modality Query Retrieve’”. Confirme que la opción esté presente en el sistema exacto antes de solucionar problemas en la red, en particular después de una recarga de software o en un sistema usado cuyas opciones puedan diferir de su pedido original. ³

Decodificación del rechazo de asociación: telemetría de PDU y códigos de diagnóstico

Cuando se rechaza la asociación 2, una captura o el registro del archivo muestra cómo. La sección 9.3.4 de DICOM PS3.8 define la PDU A-ASSOCIATE-RJ, que contiene los campos de un byte Result, Source y Reason/Diag. ¹¹

Comprender estos códigos de diagnóstico evita reemplazos innecesarios de hardware al distinguir los rechazos por políticas de seguridad de las fallas de transporte de red:

• Result: 1 es rejected-permanent; 2 es rejected-transient. ¹¹
• Source: 1 es el usuario del servicio DICOM UL (la aplicación receptora); 2 es el proveedor del servicio UL (función relacionada con ACSE); 3 es el proveedor del servicio UL (función relacionada con la presentación).
• Reason/Diag.: con Source 1, 1 no-reason-given, 2 application-context-name-not-supported, 3 calling-AE-title-not-recognized y 7 called-AE-title-not-recognized. Con Source 3, 1 temporary-congestion y 2 local-limit-exceeded. ¹¹

Un rechazo con Source 1 y Reason 3 (calling-AE-title-not-recognized) es una prueba contundente de que la ruta TCP funciona y de que la aplicación de destino rechazó el calling AE Title del archivo. Que un ecógrafo determinado envíe ese código de motivo exacto, o uno menos específico, depende de su implementación; por lo tanto, lea el código en la captura o en el registro. En cualquier caso, reemplazar tarjetas de red o cables no lo solucionará.

Otras plataformas de ultrasonido: lea la declaración de conformidad de esa versión

Los detalles de Philips anteriores son específicos de una familia de versiones documentada. Otros fabricantes y versiones configuran query/retrieve, los emisores aceptados y los puertos de escucha a su propia manera, y esta guía no generaliza los menús ni los mensajes de error de un sistema a otro. Para cualquier otro ecógrafo, obtenga la declaración de conformidad DICOM del modelo y versión de software exactos y busque estos puntos:

• Estado de la opción: si Query/Retrieve es estándar o una opción con licencia.
• Identidad de destino: qué AE Title designa el ecógrafo como Move Destination y si puede diferir del AE Title que utiliza al almacenar.
• Emisores aceptados: si los remitentes de almacenamiento deben registrarse previamente por AE Title, dirección IP o ambos.
• Puerto de escucha y seguridad: el puerto predeterminado y configurable, y si un modo TLS (DICOM seguro) lo modifica.
• Límites de asociación: cuántas asociaciones de almacenamiento simultáneas acepta el ecógrafo.
• Objetos aceptados: las clases SOP y sintaxis de transferencia que el ecógrafo acepta como Storage SCP.

Si la declaración de conformidad no responde a algún punto, regístrelo como desconocido y consulte al canal de servicio del fabricante. No llene ese vacío con suposiciones de otra marca.

¿Cuándo es incorrecta la solicitud en sí (errores A900 y de nivel)?

No todas las fallas de C-MOVE son causadas por problemas de conectividad o enrutamiento. Cuando el archivo devuelve el estado A900, la falla radica en la propia estructura de la solicitud C-MOVE. La sección C.4.2, tabla C.4-2 de DICOM PS3.4 define el estado A900 como “Error: Data Set does not match SOP Class”. La declaración de conformidad de Canon HCBA-01 (tabla 4.2-30) lo etiqueta como “Identifier does not match SOP Class”. ^{1 4}

Una solicitud C-MOVE incluye un conjunto de datos identificador que especifica el modelo de información de consulta y las instancias de destino. El estado A900 ocurre cuando este identificador infringe las reglas normativas de la clase de servicio Query/Retrieve:

• Ausencia de QueryRetrieveLevel (0008,0052): El identificador de la solicitud debe indicar el nivel jerárquico de recuperación: PATIENT, STUDY, SERIES o IMAGE. Si este atributo se omite o contiene una cadena no admitida, el archivo rechaza el comando. ¹
• Ausencia de claves únicas requeridas: en el modelo Study Root, una recuperación a nivel de STUDY necesita Study Instance UID (0020,000D); una recuperación a nivel de SERIES también necesita Series Instance UID (0020,000E), y una recuperación a nivel de IMAGE también necesita SOP Instance UID (0008,0018). ¹
• Discrepancia en el modelo de información: el identificador no se ajusta al modelo de información negociado para el C-MOVE, por ejemplo, claves creadas para Study Root enviadas bajo un contexto de Patient Root.
• Ambigüedad del Patient ID: PS3.4 señala que el emisor de Patient ID es implícito en una solicitud C-MOVE, con “ninguna disposición para enviar el Issuer of Patient ID”, y que “se debe utilizar una recuperación a nivel de STUDY en lugar de una recuperación a nivel de PATIENT” cuando el Patient ID pueda ser ambiguo. Para problemas de identidad en múltiples sitios, consulte cuando el mismo Patient ID existe bajo dos emisores. ¹

No confunda Modality Worklist con Query/Retrieve. Worklist utiliza C-FIND contra una fuente de programación para obtener las órdenes del día; Query/Retrieve busca estudios completados en un archivo de imágenes. Un escáner puede recibir su lista de trabajo correctamente y aun así fallar en cada recuperación, porque los dos servicios a menudo se ejecutan en diferentes hosts con diferentes AE Titles. Mantenga el estado de la lista de trabajo separado del query/retrieve del archivo durante la investigación.

¿Por qué llegaron algunas imágenes y otras fallaron (advertencia B000 y recuentos)?

Un estado de advertencia de B000 (Sub-operations Complete – One or more Failures) significa que algunas suboperaciones tuvieron éxito y otras fallaron. En la práctica, el ecografista abre el estudio recuperado y encuentra presentes las imágenes de fotograma único, pero faltan algunos bucles de cine, volúmenes o informes. ¹

B000 es una buena evidencia de que ambas asociaciones se pueden establecer: el archivo llegó al destino y al menos algunas solicitudes C-STORE tuvieron éxito. La falla radica en instancias o clases SOP particulares, o en los recursos del destino.

Las causas principales de las fallas de recuperación parcial incluyen:

• Discrepancia en la sintaxis de transferencia: el archivo contiene un clip en una codificación que el destino no acepta (por ejemplo, MPEG-4 AVC/H.264 o JPEG-LS), y no puede convertirlo o no lo convierte. Los archivos difieren: la declaración de Canon HCBA-01, por ejemplo, describe una lista configurable de sintaxis de transferencia por AE Title de destino e intentos de transcodificación cuando el destino no admite la sintaxis almacenada. ⁴
• Objetos que no son imágenes rechazados: los estudios pueden incluir Structured Reports, Encapsulated PDF o estados de presentación. Un receptor que solo acepta clases SOP de imágenes de ultrasonido rechaza el resto. La aceptación no es lo mismo que la visualización: la declaración de la versión 6.0.x de Philips indica que el sistema acepta y puede importar objetos SR con un estudio, pero no visualiza los SR importados. ³ Para verificar los objetos de informe, coteje las instancias que realmente llegaron con la adquisición original.
• Espacio de almacenamiento de destino: si la consola se queda sin espacio local durante una recuperación extensa, su receptor puede rechazar instancias posteriores. Antes de liberar espacio, verifique las instancias conservadas antes de confiar en las copias locales o eliminarlas.

Para B000, comience con la Failed SOP Instance UID List (0008,0058). Cotejar esos UID con los registros del archivo muestra qué clases SOP y sintaxis de transferencia fallaron, de modo que la corrección pueda orientarse de manera específica.

Flujo de trabajo de diagnóstico paso a paso para ingenieros clínicos

Para evitar cambios descoordinados entre ingeniería clínica, PACS y TI, siga la misma secuencia cada vez que falle una recuperación. Cada paso indica quién lo realiza normalmente:

1. Paso 1 — Registrar el estado y los recuentos: obtenga el estado final de C-MOVE (por ejemplo, A801, A702, A900 o B000) y cualquier recuento informado desde el registro DICOM del archivo (administrador de PACS) o el registro de servicio del ecógrafo donde se muestren. Compare el patrón con la Tabla 2.
2. Paso 2 — Registrar la identidad DICOM del ecógrafo: su AE Title emisor, el AE Title que designa como Move Destination, su puerto de escucha y su dirección IP actual (servicio técnico del ecógrafo).
3. Paso 3 — Verificar el registro de destino del archivo: junto con el administrador de PACS, confirme que exista una entrada de nodo para ese AE Title de destino con la dirección IP y el puerto actuales del ecógrafo, comparando las cadenas de forma exacta.
4. Paso 4 — Probar la accesibilidad desde el lado del archivo: el equipo de red o de PACS prueba si el archivo puede alcanzar el puerto de escucha del ecógrafo, utilizando sus herramientas aprobadas. Tenga en cuenta que el ping ICMP puede estar bloqueado por directiva incluso cuando el puerto DICOM esté abierto, por lo que un ping fallido por sí solo demuestra poco.
5. Paso 5 — Verificar los emisores aceptados en el ecógrafo: en sistemas que registran previamente emisores de almacenamiento, como la familia documentada de Philips, confirme que se hayan ingresado el AE Title emisor y la dirección IP del archivo (servicio técnico del ecógrafo).
6. Paso 6 — Confirmar la opción: verifique que la opción de Query/Retrieve requerida por el fabricante, si corresponde, esté presente en el sistema (servicio técnico del ecógrafo).
7. Paso 7 — Cotejar objetos y codificaciones: en transferencias parciales, verifique si los objetos fallidos comparten una clase SOP o una sintaxis de transferencia que el destino no acepte (administrador de PACS y servicio técnico del ecógrafo).

Topologías de red complejas: NAT, VLAN y carros inalámbricos con DHCP

En las redes corporativas hospitalarias modernas, los sistemas de ultrasonido operan cada vez más en infraestructuras dinámicas o segmentadas, lo que introduce complejidades de enrutamiento que no afectan a las modalidades fijas de diagnóstico por imágenes como la TC o la RM:

1. Traducción de direcciones de red (NAT): si el ecógrafo se encuentra detrás de NAT, por ejemplo en una red inalámbrica segmentada, el archivo ve la dirección de la puerta de enlace, mientras que su registro de nodo para el AE Title de destino puede apuntar a una dirección a la que no puede acceder directamente. Las conexiones entrantes no solicitadas a esa dirección se descartan a menos que la red esté diseñada para admitirlas. La base de conocimientos de Medical Connections describe los enrutadores, NAT y firewalls de software como bloqueadores frecuentes de la conexión inversa de C-MOVE; sus soluciones alternativas orientadas a equipos de escritorio de deshabilitar los firewalls o abrir puertos en el enrutador no son apropiadas en una red hospitalaria. ⁶

2. Cambio de direcciones IP: los ecógrafos portátiles que se trasladan entre departamentos pueden recibir nuevas direcciones mediante DHCP. Si el registro de nodo del archivo contiene una dirección fija para el AE Title del ecógrafo, cualquier cambio envía la asociación 2 a la dirección anterior y se agota el tiempo de espera. Los ecógrafos que necesitan recuperación generalmente requieren una dirección estable, como una asignación estática o una reserva DHCP, determinada por el equipo de redes.

3. Inspección con estado y enrutamiento asimétrico: Los firewalls empresariales suelen implementar inspección con estado que permite automáticamente los paquetes de retorno entrantes para las conexiones iniciadas desde dentro de una zona protegida. Mientras que la Asociación 1 (ultrasonido a PACS) se reconoce como un flujo activo con estado, la Asociación 2 es una conexión TCP completamente nueva iniciada por el servidor PACS en la dirección opuesta. A menos que el administrador del firewall cree una política bidireccional explícita o una regla entrante que permita el tráfico desde el servidor PACS hacia el puerto de escucha de ultrasonido, el firewall descartará la Asociación 2 como un sondeo entrante no autorizado.

Negociación de contextos de presentación y discrepancias de sintaxis

Cuando la Asociación 2 establece un socket TCP, el archivo PACS (que actúa como Storage SCU) propone una lista de contextos de presentación al carro de ultrasonido (que actúa como Storage SCP). Cada contexto propuesto empareja una sintaxis abstracta (el UID de la clase SOP) con una o más sintaxis de transferencia (el formato de codificación y el códec de compresión). El equipo de ultrasonido evalúa cada propuesta y devuelve un código de aceptación o rechazo en su respuesta A-ASSOCIATE-AC.

Los sistemas de ultrasonido manejan una combinación única de bucles de cine de alta velocidad de fotogramas, mapeos de flujo de color multizona y mediciones estructuradas complejas. La siguiente tabla detalla las colisiones de contextos de presentación más comunes encontradas durante las suboperaciones C-STORE:

Diagnósticos a nivel de paquetes y captura no intrusiva de tráfico

No instale herramientas de captura de paquetes, escáneres de puertos u otro software en la consola de ultrasonido. Es un dispositivo médico bajo el control de software del fabricante y el control de cambios de la institución, y el software no aprobado puede afectar su configuración validada y su seguridad.

Cuando se justifique una captura, el equipo de redes puede obtenerla desde la infraestructura, por ejemplo mediante un puerto espejo de switch (SPAN) o un TAP de red pasivo, y analizarla en una estación de trabajo autorizada independiente. Las capturas de tráfico DICOM no cifrado contienen datos de pacientes, por lo que deben autorizarse, minimizarse, almacenarse y eliminarse conforme a la política de privacidad y seguridad de la institución. Si se utiliza DICOM seguro (TLS), la captura muestra la conexión TCP, pero no los mensajes DICOM en su interior; utilice en su lugar los registros del archivo y del escáner.

En Wireshark, un filtro de visualización como dicom || tcp.port == <listening port>, utilizando los puertos configurados en la institución, aísla el tráfico relevante. Luego verifique ambas asociaciones en orden:

• Verificación de la asociación 1: Localice el protocolo de enlace de tres vías TCP (SYN, SYN-ACK, ACK) originado desde el puerto efímero de la consola de ultrasonido hacia el puerto de escucha del PACS. Inmediatamente después del protocolo de enlace, verifique la PDU A-ASSOCIATE-RQ (tipo 01H) que contiene los contextos de presentación propuestos para Study Root Query/Retrieve Information Model - FIND y MOVE. Confirme que el servidor PACS devuelva una PDU A-ASSOCIATE-AC (tipo 02H) que acepte ambos contextos.
• Envío de la solicitud C-MOVE: Rastree la PDU P-DATA-TF que contiene el comando C-MOVE-RQ. Verifique el Message ID, el QueryRetrieveLevel (p. ej., STUDY), la clave de coincidencia StudyInstanceUID y el atributo Move Destination AE Title (0000,0600). Confirme que la cadena de destino coincida exactamente con el AE Title de escucha esperado del ultrasonido.
• Inicio y protocolo de enlace de la asociación 2: Observe la llegada de un paquete TCP SYN nuevo e independiente proveniente de la dirección IP del servidor PACS y dirigido a la IP estática y al puerto de escucha del carro de ultrasonido. Este es el punto de inflexión diagnóstico crítico. El comportamiento de este paquete identifica la causa raíz de inmediato.

Concurrencia, gestión de colas y tiempos de espera de sockets

En los departamentos de diagnóstico por imágenes de alto volumen, las fallas de recuperación a menudo se manifiestan de forma intermitente en condiciones de alta carga de trabajo. Un ecógrafo sobre carro que recupera sin dificultad un estudio tiroideo de cinco imágenes puede fallar sistemáticamente al intentar importar un examen ecocardiográfico complejo de 600 fotogramas o un estudio vascular periférico exhaustivo. Estas fallas dependientes del volumen se deben a los límites en las colas de red y a las configuraciones de tiempo de espera de sockets.

1. Regulación del archivo y tiempos de espera del cliente: los archivos a menudo limitan las transferencias salientes simultáneas. Si varios usuarios solicitan estudios grandes al mismo tiempo, las suboperaciones pueden quedar en cola. Si el ecógrafo solicitante aplica su propio tiempo de espera a la recuperación general, puede desistir y reportar una falla mientras el archivo todavía está enviando. Compare la cronología del registro del archivo con la hora en que el ecógrafo reportó el error.

2. Escrituras lentas en el destino: un destino que no puede escribir los datos tan rápido como llegan ralentiza la transferencia. Si un estancamiento supera el tiempo de espera de red o de mensaje del archivo, el archivo aborta la asociación 2. El ejemplo informativo de PS3.2 describe exactamente esto: un A-ABORT por tiempo de espera a nivel de mensaje o de bajo nivel, con un estado de falla apropiado devuelto en la respuesta C-MOVE. ²

3. Reintentos repetidos: cada vez que se presiona Retrieve se envía una nueva solicitud C-MOVE, lo que puede poner en cola transferencias duplicadas y sepultar la primera falla en los registros. Capture el estado de la primera falla y luego reintente una vez de forma controlada después de haber solucionado la causa.

Validación posterior a la recuperación: indexación en la base de datos local y prevención de la división de estudios

Un estado final de 0000 (Success) significa que cada suboperación C-STORE fue entregada y confirmada. Esto no garantiza que el estudio se encuentre donde el ecografista espera hallarlo en el ecógrafo.

Los sistemas de ultrasonido difieren en la forma en que archivan y listan los estudios recibidos, y la declaración de conformidad o el manual del operador de la versión exacta son la referencia definitiva. Los objetos recibidos suelen agruparse por sus atributos de identificación, tales como Patient ID (0010,0020), Study Instance UID (0020,000D) y Accession Number (0008,0050), por lo que las diferencias en esos valores modifican el lugar donde aparece el estudio.

Si las imágenes recuperadas no aparecen en la pantalla de la consola a pesar de una confirmación con estado 0000, los ingenieros deben investigar tres anomalías comunes de ingesta en la base de datos:

• Examen abierto: es posible que algunos sistemas no actualicen su lista de estudios mientras un examen está en curso. Consulte la pantalla de revisión o de estudios recibidos descrita en el manual del operador.
• Archivado en un registro de paciente diferente: si el estudio archivado tiene un Patient ID o un número de acceso diferente al de la orden de hoy, el ecógrafo puede listarlo en una entrada de paciente separada. Busque por Study Instance UID o por fecha antes de concluir que la recuperación falló.
• Falla de almacenamiento local o de indexación: si el almacenamiento local está casi lleno o el proceso de importación falló, el registro de servicio del ecógrafo suele mostrarlo. Libere espacio únicamente mediante el procedimiento aprobado por el fabricante y la política de retención de la institución.

¿A quién corresponde cada corrección: servicio técnico del ecógrafo, administrador del PACS o equipo de red?

Los equipos de servicio de ingeniería clínica desempeñan una función de triaje crucial en el ciclo de vida de la gestión de tecnología sanitaria. Cuando el personal de ecografía clínica reporta fallas de recuperación (retrieve), los técnicos biomédicos suelen ser los primeros en responder en las áreas hospitalarias. En lugar de escalar de inmediato el caso a mesas de ayuda de TI externas o tramitar una autorización de devolución por avería del equipo, los ingenieros clínicos deben establecer una línea base formal de conectividad DICOM durante la puesta en marcha inicial del equipo. Esta línea base debe documentar la dirección IP estática verificada, la máscara de subred, la puerta de enlace predeterminada, la dirección MAC física, el AE Title de Storage SCP local, el puerto de escucha y la compilación de software del carro de ultrasonido, junto con la fecha y el número de ticket de cambio de cualquier modificación de red. Mantener este registro de línea base de conectividad dentro del Sistema Computarizado de Gestión del Mantenimiento (CMMS) del hospital garantiza que las futuras reasignaciones de IP, reconfiguraciones de puertos de switch o actualizaciones de software puedan cotejarse al instante con un estado operativo comprobado, lo que reduce drásticamente el tiempo de diagnóstico y evita llamadas de servicio innecesarias.

Dado que una recuperación DICOM cruza límites institucionales —abarcando el firmware del dispositivo médico, los switches de red hospitalarios, los firewalls y las bases de datos del PACS corporativo—, la resolución de problemas suele derivar en señalamientos entre departamentos. Los ingenieros clínicos culpan al departamento de TI del hospital por bloquear puertos, TI culpa al proveedor del PACS por errores de software y los administradores del PACS culpan al carro de ultrasonido por hardware defectuoso.

Para eliminar los tiempos de inactividad innecesarios, los equipos técnicos del hospital deben establecer límites claros de responsabilidad basados en evidencia objetiva de los protocolos. Cada capa de la cadena de recuperación corresponde a una disciplina profesional específica:

¿Qué debe registrarse antes de que alguien modifique una configuración?

Registre cada cambio: qué se modificó, quién lo hizo, con qué orden de trabajo y el resultado de las pruebas previas y posteriores. Si una recuperación posterior falla, ese registro muestra si la causa es un cambio reciente en la infraestructura o una nueva falla del equipo. Cuando el fabricante proporcione una función admitida de exportación de configuración, realice una antes de cambiar los ajustes del escáner y guárdela conforme a la política de la institución para que el cambio pueda revertirse.

Cuando un equipo de ultrasonido falla al recuperar estudios, el personal de servicio debe resistir el impulso de modificar parámetros de configuración al azar, alternar ajustes del firewall u ordenar placas de E/S de red de repuesto. La resolución de problemas no coordinada mediante ensayo y error genera graves riesgos de seguridad y, con frecuencia, introduce fallas secundarias que complican la recuperación.

Los errores de enrutamiento también representan un riesgo para la privacidad. Si alguien intenta solucionar un A801 adivinando los AE Title de destino o dirigiendo el Move Destination a otro nodo conocido sin confirmar qué es, el archivo enviará los estudios de los pacientes a ese dispositivo. En muchas jurisdicciones, esto puede constituir un incidente de privacidad de notificación obligatoria; el responsable de privacidad de la institución decide cómo debe gestionarse.

Antes de modificar cualquier archivo de configuración, abrir un ticket de soporte o solicitar componentes de repuesto, los ingenieros clínicos deben recopilar un paquete de evidencia estructurado y depurado para la recepción del servicio:

Herramientas de simulación controlada: verificación sintética sin arriesgar datos de pacientes

Cuando una recuperación de ultrasonido falla de forma intermitente o cuando los equipos de redes debaten si un puerto de firewall está realmente abierto, los ingenieros clínicos necesitan un método objetivo y repetible para aislar el extremo que falla sin enviar repetidamente exámenes de pacientes reales a través de subredes clínicas. En entornos hospitalarios regulados, provocar reiteradamente transferencias fallidas de estudios clínicos reales genera ruido de auditoría y aumenta el riesgo de divulgación accidental de información de salud protegida.

Para establecer la certeza técnica, los equipos de ingeniería clínica pueden implementar paquetes estandarizados de verificación DICOM (como las utilidades del kit de herramientas DCMTK o las herramientas de prueba DVTk) que se ejecuten en una estación de trabajo de prueba dedicada y autorizada por TI dentro de la misma subred clínica:

• Prueba de la ruta inversa con un receptor de prueba: ejecute un receptor de almacenamiento DICOM temporal en la estación de trabajo de prueba autorizada, en un puerto acordado con el equipo de redes, y solicite al administrador del PACS que registre su AE Title como destino. Si un C-MOVE de un estudio de prueba designado llega al receptor, el archivo puede alcanzar ese segmento de red y la atención pasa a la propia configuración del ecógrafo.
• Verificación del receptor de almacenamiento del ecógrafo desde la red: Por el contrario, un ingeniero puede enviar un estudio de prueba de ultrasonido sintético y desidentificado desde la computadora portátil de prueba directamente a la IP y al puerto de escucha del carro de ultrasonido mediante C-STORE. Si el ecógrafo acepta la asociación e incorpora la imagen de prueba, se demuestra que el servicio local Storage SCP del carro, el firewall del sistema operativo local y la base de datos interna están completamente operativos. Si el carro rechaza la asociación con A-ASSOCIATE-RJ, se confirma de inmediato que la causa raíz es la configuración de Calling AE Title aceptados del ecógrafo.
• Límite de seguridad y cumplimiento normativo: Las utilidades de prueba nunca deben conectarse a VLAN clínicas sin la autorización formal del área de seguridad de la información del hospital. Además, las imágenes de prueba deben consistir exclusivamente en adquisiciones con fantomas o en objetos DICOM generados sintéticamente que no contengan ningún dato demográfico de pacientes ni información de salud protegida.

Pruebas de aceptación posteriores al servicio y aprobación clínica

Después de cualquier reemplazo de placa, recarga de software, cambio de red o cambio de configuración, vuelva a probar las funciones DICOM antes de devolver el ecógrafo al uso clínico. Las verificaciones de servicio a menudo se limitan a enviar una sola imagen al PACS, lo que deja la recuperación sin probar hasta que un ecografista necesite un estudio previo.

Utilice el procedimiento de paciente de prueba designado por la institución, de modo que no se cree ni se altere ningún registro de paciente real, y verifique cada función configurada:

• 1. Verificación (C-ECHO): Realice una prueba de ping/echo desde la consola de ultrasonido hacia todos los nodos DICOM configurados (archivo PACS, servidor de lista de trabajo, servidor de compromiso de almacenamiento e impresoras DICOM). Confirme el acuse de recibo satisfactorio.
• 2. Lista de trabajo de modalidad (C-FIND): Consulte las órdenes de pacientes programadas para hoy. Seleccione un paciente programado, cargue los datos demográficos del paciente en la pantalla de adquisición y confirme que los números de acceso, las descripciones del estudio y los nombres de los médicos que realizan el estudio se asignen correctamente.
• 3. Adquisición y almacenamiento (C-STORE): Adquiera un bucle Doppler color multifotograma e imágenes 2D estáticas utilizando un fantoma de simulación tisular. Envíe el examen completado al PACS. Confirme que todas las instancias se transfieran sin errores y que el archivo confirme el almacenamiento.
• 4. Consulta y recuperación (C-FIND, C-MOVE): consulte el estudio de prueba recién almacenado, recupérelo de vuelta en el ecógrafo y confirme que las imágenes y los bucles de cine se abran, y que no se registre ningún estado de advertencia como B000. Verifique los informes de medición únicamente donde esté documentado que el sistema los importa y los muestra.

Apruebe el evento de servicio únicamente cuando cada función configurada supere las pruebas, de modo que los ecografistas puedan confiar en los estudios previos durante los exámenes.

Preguntas frecuentes

¿Un C-ECHO o una consulta exitosos demuestran que la recuperación también debería funcionar?

No. Una verificación DICOM (C-ECHO) o consulta (C-FIND) prueba únicamente la ruta de red directa iniciada por el equipo de ultrasonido hacia el puerto de escucha del archivo PACS (Asociación 1). Una recuperación C-MOVE requiere que el archivo PACS inicie una conexión de red inversa e independiente de regreso al puerto de escucha del equipo de ultrasonido (Asociación 2). Debido a que los firewalls, las tablas de enrutamiento de red y las políticas locales de seguridad del equipo tratan con frecuencia las conexiones entrantes de forma diferente a las conexiones salientes, el éxito en C-ECHO o C-FIND no ofrece ninguna garantía de que la Asociación 2 tenga éxito. ^{1 5}

¿El destino del traslado es siempre la máquina que envió la solicitud?

No necesariamente. En DICOM PS3.4, sección C.4.2, el atributo Move Destination especifica el Application Entity Title del sistema que recibirá las suboperaciones C-STORE. Si bien los ecografistas clínicos suelen recuperar estudios en el carro que están operando, el protocolo C-MOVE permite explícitamente que el solicitante designe cualquier nodo de almacenamiento DICOM de terceros como destino—como una estación de trabajo dedicada, un servidor de visualización 3D o una estación de revisión fuera de línea. El archivo siempre resuelve el AE Title de Move Destination de forma independiente, sin importar qué cliente haya iniciado la solicitud. ¹

El traslado reporta éxito, pero no apareció ningún estudio — ¿qué se debe verificar primero?

Si la respuesta de C-MOVE indica el estado 0000 (Success) y el Number of Completed Sub-operations coincide con la cantidad esperada de imágenes, la transferencia de red se completó con éxito. Si las imágenes no aparecen en la pantalla del equipo de ultrasonido, verifique dos factores inmediatos: primero, compruebe el índice de la base de datos interna de pacientes del equipo de ultrasonido—algunos sistemas almacenan los estudios recuperados en un archivo local o directorio de pacientes que debe actualizarse manualmente o abrirse desde una pestaña de “Estudios importados”. Segundo, verifique si el AE Title de Move Destination en la solicitud se configuró inadvertidamente para una máquina física diferente (como otro equipo o estación de trabajo de revisión), en cuyo caso las imágenes se entregaron correctamente a ese otro dispositivo. ^{1 6}

¿Podemos simplemente abrir el firewall o redirigir un puerto para que la recuperación funcione?

No. En entornos hospitalarios clínicos, los equipos de ultrasonido son dispositivos médicos móviles que procesan información de salud protegida (PHI). Abrir reglas de firewall indiscriminadas, deshabilitar el software de seguridad del host o configurar una redirección de puertos no administrada viola los estándares de ciberseguridad sanitaria y las políticas de seguridad institucional. Los cambios de red deben coordinarse formalmente con los equipos de TI y de seguridad de redes del hospital, restringiendo el tráfico a IP de origen específicas (el servidor PACS), IP de destino (el carro de ultrasonido) y puertos de escucha DICOM designados, sin exponer las subredes clínicas a tráfico no autorizado.

¿C-GET o DICOMweb evitarían este problema de conexión inversa?

En principio, sí. Con C-GET (PS3.4, sección C.4.3), las suboperaciones C-STORE se ejecutan en la misma asociación que la solicitud, y el receptor es siempre el solicitante. La recuperación mediante DICOMweb también es iniciada por el cliente a través de HTTP. Ninguno de los dos requiere que el archivo abra una conexión de regreso al equipo de ultrasonido. ¹⁰ Pero ambos extremos deben admitir la alternativa. La base de conocimientos de Medical Connections, redactada hace algunos años, observó que muy pocos servidores DICOM comerciales admitían C-GET. ⁶ Verifique ambas declaraciones de conformidad. Cambiar de protocolo es una cuestión de planificación para el propietario del PACS, no una solución para una falla de C-MOVE hoy.

¿Una recuperación fallida significa que la placa de red del equipo de ultrasonido está dañada?

Poco probable, si el ecógrafo puede consultar, verificar o enviar estudios al PACS a través de la misma interfaz. El hardware de red transporta paquetes sin importar si contienen una consulta C-FIND o una imagen C-STORE. Si la interfaz estuviera fallando, el tráfico saliente normalmente también se vería afectado. Con el DICOM saliente funcionando, es mucho más probable que una falla exclusiva de recuperación se deba a un problema de AE Title, de llamante aceptado, de enrutamiento o de firewall. Las caídas intermitentes del enlace o una interfaz inactiva son síntomas diferentes, cubiertos en la guía de la placa de E/S de red vinculada arriba.

¿Qué sucede si los estudios de pacientes se enviaron al destino equivocado?

Trátelo como un posible incidente de privacidad. Detenga las pruebas, registre la hora, el Study Instance UID y el AE Title de destino utilizado, y notifique al administrador del PACS y al responsable de privacidad de la institución. Ellos deciden cómo se comprueba el dispositivo receptor y cómo se eliminan las copias mal dirigidas.

¿Dónde encaja Rongtao —y dónde no—?

Rongtao Medical es una empresa independiente de repuestos y reparación de ultrasonido con sede en Guangzhou, China, que presta servicios a distribuidores, organizaciones de servicio y equipos de ingeniería hospitalaria. Ser claros sobre dónde podemos ayudar ahorra tiempo a todos.

Dónde encaja Rongtao:

• Aislamiento de fallas de hardware: cuando el problema realmente es de hardware, por ejemplo, ausencia de enlace Ethernet, pérdida intermitente del enlace o una placa de E/S o placa principal defectuosa, Rongtao ofrece diagnóstico y reparación a nivel de placa. Cada placa reparada funciona durante 48 horas dentro de un sistema de ultrasonido real antes de su liberación. ⁷
• Placas y repuestos de reemplazo: reparación de placas y repuestos para sistemas OEM compatibles. El inventario cambia, por lo que debe confirmar un número de parte específico a través del catálogo en vivo o una cotización. ⁸
• Reparación de sondas: diagnóstico de fallas y reparación de sondas lineales, convexas, phased-array, endocavitarias, TEE y volumétricas, con una garantía típica de 90 días confirmada por artículo y servicio. ⁸
• Orientación para la admisión del servicio: ayuda para determinar si un síntoma apunta al hardware o a la configuración en otra parte, de modo que pueda preparar la evidencia de servicio del lado del ecógrafo antes de solicitar repuestos.

Dónde no encaja Rongtao:

• Administración de redes y firewalls hospitalarios: Rongtao no configura switches de red departamentales del hospital, no administra firewalls empresariales, no modifica listas de control de acceso de VLAN ni gestiona dominios de Active Directory del hospital.
• Administración de nodos de archivo PACS: No gestionamos, licenciamos ni configuramos archivos PACS hospitalarios, archivos neutros al proveedor (VNA, Vendor Neutral Archives) ni sistemas de información radiológica. Las modificaciones en las tablas de destino del PACS y las asignaciones de AE Title en el servidor siguen siendo responsabilidad exclusiva de la administración del PACS del hospital.
• Representación autorizada de OEM: Rongtao Medical es un proveedor de servicios independiente y no es un agente, distribuidor ni representante autorizado de GE HealthCare, Philips, Siemens Healthineers, Canon Medical Systems, Mindray o Samsung Medison.

Al solicitar soporte técnico de hardware o repuestos para fallas persistentes de comunicación, por favor envíe la evidencia DICOM anonimizada y los datos del modelo a nuestro equipo técnico: marca OEM, familia exacta del modelo, versión de software, números de parte del hardware y un resumen anonimizado de los síntomas de error. Nunca envíe información de salud del paciente, imágenes de pacientes ni identificadores clínicos a través de los canales de cotización técnica.