Pregunta
· 21 sep, 2022

Proceso MOVE Dicom se "atasca"

Buenos días,

💭🧱🧑‍💻 Hemos estado indagando y construyendo gracias al enorme apoyo, soporte, y asistencia ofrecida por el siguiente ejemplo:

https://es.community.intersystems.com/post/ejemplo-de-integraci%C3%B3n-d...

Y del código de Github de los circuitos de ejemplo para el FIND y el MOVE:

https://github.com/intersystems-ib/iris-dicom-sample

 

Sería de agradecer si ustedes nos leen y responden a las siguiente cuestiones:

Desarrollando el MOVE, nos hemos encontrado con que en los primeros envíos sí se realiza y obtenemos respuesta:

MOVE

STORE

 

Sin embargo, ocurre algo único cuando se ejecutan varias veces el MOVE. El proceso genera una Excepción:

  ERROR <Ens>ErrBPTerminated: Finalizando BP DICOM Move Process # debido a un error: ERROR <Ens>ErrException: <READ>zAcceptPDU+4^EnsLib.DICOM.Adapter.TCP.1 -- - registrado como '-' número - @''
> ERROR <Ens>ErrException: <READ>zAcceptPDU+4^EnsLib.DICOM.Adapter.TCP.1 -- - registrado como '-' número - @''

 

¿De qué manera se podría entender y comprender la Excepción? Para depurarla posteriormente

 

En concreto para dar más información actualmente estamos simulando ser ORIGEN mediante:

./movescu -b VNAPRE -c ESBPRE@AA.BBB.C.DDD:2021 -m StudyInstanceUID="1.2.156.14702.1.1000.16.0.20200311113603875" --dest ESBPRE

Y además simulamos un DESTINO empleando para ello:

./dcmqrscp --ae-config ./shared/ae.properties -b VNAPRE:11118 --dicomdir ./shared/DICOMDIR

 

Siendo el circuito del MOVE:

Estamos empleando el código original de la clase DICOM.BP.MoveProcess publicado en el ejemplo:

https://raw.githubusercontent.com/intersystems-ib/iris-dicom-sample/mast...

 

Además hemos tratado de emplear distintos puertos para DESTINO: 11114, 11116 11118 etc

Y ocurre de igual forma:

  ERROR <Ens>ErrBPTerminated: Finalizando BP DICOM Move Process # debido a un error: ERROR <Ens>ErrException: <READ>zAcceptPDU+4^EnsLib.DICOM.Adapter.TCP.1 -- - registrado como '-' número - @''
> ERROR <Ens>ErrException: <READ>zAcceptPDU+4^EnsLib.DICOM.Adapter.TCP.1 -- - registrado como '-' número - @''

 

🎓🔎🐞🩹🧑‍💻 ¿De qué manera se podría entender y comprender la Excepción? Para depurarla posteriormente 🔍

Muchas gracias de antemano por su tiempo

Un saludo

Product version: HealthShare 2020.1
Comentarios (3)2
Inicie sesión o regístrese para continuar

Hola Yone,

Podrían ser errores de red, o de timeouts durante la transferencia.

Echa un vistazo a Tasks for DICOM Productions, en particular a Configuring a DICOM Duplex Business Host. Tienes varios configuraciones que quizá te ayuden como TraceVerbosity, ARTIM, TXTIM para mostrar más o menos información y modificar ciertos timeouts.

También te puede servir lo que te dice el otro lado de la comunicación (lo que parece que es el simulador).

De todas formas, ten en cuenta que parece que estás trabajando con un simulador y a veces pueden tener ciertas limitaciones.

Hola Alberto,

Gracias por indicarme los recursos y sobre todo agradezco que me especificaras en concreto qué propiedades aportan en este caso.

He configurado:

Seguimiento del nivel de detalle = 2

ARTIM = 20

TXTIM = 20

Y ahora sí se recibe la respuesta del Establecer conexión desde el Simulador ( Destino ) hacia la Operacion TCP Dicom ( Receptora )

Lo que sí es cierto, resulta que ocurre la excepción de forma similar, casi igual en el paso [6]; justo antes de recibir la Notificación de Conexión establecida por parte del SIMULADOR dcm4che hacia la Operacion del ESB:

  ERROR <Ens>ErrBPTerminated: Finalizando BP DICOM Move Process # debido a un error: ERROR <Ens>ErrException: <READ>zAcceptPDU+4^EnsLib.DICOM.Adapter.TCP.1 -- - registrado como '-' número - @''
> ERROR <Ens>ErrException: <READ>zAcceptPDU+4^EnsLib.DICOM.Adapter.TCP.1 -- - registrado como '-' número - @''

Lo más acuciante e intrigante es el hecho de que el Simulador dcm4che que replica ser un Sistema ORIGEN (envía al servicio) se queda a la escucha, tras haber enviado el C-MOVE-RQ:

Y el simulador que actúa como DESTINO se queda en el estado de Asociación Establecida, sin embargo no le llega efecitamente el C-MOVE-RQ, lo cual es muy llamativo :

¿ De qué forma nos recomiendan depurar ?

Muchas gracias de antemano por su tiempo, por leerme y responder. Un saludo

Hola de nuevo, Yone:

Puedes probar a subir los timeous por ejemplo a 60s.

Además, puedes activar las trazas detalladas de interoperabilidad. Quizá te ponga así más información. Mira en:
https://docs.intersystems.com/irisforhealth20221/csp/docbook/Doc.View.cl...

set ^Ens.Debug("TraceCat","queue")=1

En otro caso, quizá habría que ya verlo a nivel de red (e.g. captura con WireShark y demás), o si lo quieres ver muy en detalle abrir un caso WRC.