Hola Alberto,

Gracias por tu respuesta y tiempo, Alberto

Hemos escrito al inicio del método:

set ^zdebug($i(^zdebug))="["_$zdt($zts,3,,2)_"] "_"before" 

y al final del método:

set ^zdebug($i(^zdebug))="["_$zdt($zts,3,,2)_"] "_"after. tSC="_tSC 

En PREproducción observamos:

zw ^zdebug
^zdebug=2
^zdebug(1)="[2022-06-03 08:52:17.11] before"
^zdebug(2)="[2022-06-03 08:52:17.11] after. tSC=1"

En INTegración ocurre similar:

zw ^zdebug
^zdebug=2
^zdebug(1)="[2022-06-03 08:53:43.77] before"
^zdebug(2)="[2022-06-03 08:53:43.78] after. tSC=1"

¿De qué forma nos recomiendas, Alberto, continuar?

Gracias Alberto por tu asistencia y tiempo

Un saludo

Es de agradecer, Alberto, tu respuesta, y sobre todo las explicaciones y enlaces

A continuación te detallamos la situación, Alberto, para que ustedes nos indiquen, ordenen, recomienden, sugieran vías o formas de continuar:

A continuación, se muestran las trazas del WireShark

Primero observamos la traza Simulada desde Línea de Comandos mediante:

./findscu -b VNAPRE -c ESBPRE@10.136.4.142:19586 -m PatientID="102030" -M StudyRoot

Segundo se muestra la traza Real desde Sistema Origen hacia Sistema Destino:

La principal diferencia radica en la petición, la cual está en 1 único paquete en la Simulada, el cual está titulado como:

1072 … P-DATA, C-FIND-RQ ID=1, C-FIND-RQ-DATA

Sin embargo, en la real, la petición consta de 2 paquetes:

1904 … P-DATA, C-FIND-RQ ID=1

1906 … P-DATA, C-FIND-RQ-DATA

Ahondando en el detalle, comparamos la primera de las peticiones titulada como: “P-DATA, C-FIND-RQ ID=1”

En la Simulada se observa lo siguiente:

Donde cabe destacar estos 2 contenidos del conjunto de comandos (Command, Last Fragment):

…

    (0000,0700)          2 Priority                                      0

    (0000,0800)          2 Command Data Set Type                         0

Los cuales en la Real son distintos:

…

    (0000,0700)          2 Priority                                      2

    (0000,0800)          2 Command Data Set Type                         1

Además, también es importante recalcar que en la segunda petición reseñada como “P-DATA, C-FIND-RQ-DATA” existen diferencias:

En la Real es más completa:

PDV, C-FIND-RQ-DATA

    PDV Length: 130

    Context: 0x01 (Implicit VR Little Endian: Default Transfer Syntax for DICOM, Study Root Query/Retrieve Information Model - FIND)

    Flags: 0x02 (Data, Last Fragment)

    (0008,0005)          0 Specific Character Set                        <Empty>

    (0008,0020)          0 Study Date                                    <Empty>

    (0008,0030)          0 Study Time                                    <Empty>

    (0008,0050)          0 Accession Number                              <Empty>

    (0008,0052)          6 Query/Retrieve Level                          STUDY

    (0008,0061)          0 Modalities in Study                           <Empty>

    (0008,0090)          0 Referring Physician's Name                    <Empty>

    (0008,1010)          0 Station Name                                  <Empty>

    (0008,1030)          0 Study Description                             <Empty>

    (0010,0010)          0 Patient's Name                                <Empty>

    (0010,0020)          2 Patient ID                                    9

    (0010,0030)          0 Patient's Birth Date                          <Empty>

    (0010,0040)          0 Patient's Sex                                 <Empty>

    (0020,000d)          0 Study Instance UID                            <Empty>

    (0020,0010)          0 Study ID                                      <Empty>

Sin embargo, en la Simulada únicamente existen 2 datos:

PDV, C-FIND-RQ-DATA

    PDV Length: 30

    Context: 0x01 (Implicit VR Little Endian: Default Transfer Syntax for DICOM, Study Root Query/Retrieve Information Model - FIND)

    Flags: 0x02 (Data, Last Fragment)

    (0008,0052)          6 Query/Retrieve Level                          STUDY

    (0010,0020)          6 Patient ID                                    102030

Por otro lado, lo que nos genera mayor inquietud, nos pone en vilo, y es extraño, resulta ser las discrepacias entre los resultados de los estudios médicos obtenidos mediante servicio ‘interno’ y mediante ‘simulación por herramienta externa’ hacia el Servicio TCP de DICOM

En concreto cuando ejecutamos desde la “Salida” del “Studio” de ESBPRE lo siguiente:

do ##class(DICOM.BS.QueryService).TestFind("102030")

Se envía la petición:

Y para cada uno de los 3 estudios médicos respondidos por el Sistema Destino, obtenemos datos completos:

Mientras que cuando simulamos ser Sistema Origen, gracias a la herramienta ‘findscu’ de Línea de Comandos, ejecutamos:

./findscu -b VNAPRE -c ESBPRE@10.136.4.142:19586 -m PatientID="102030" -M StudyRoot

Generándose la petición siguiente en la traza:

Si prestamos atención a la imagen anterior, se visualiza que únicamente se remiten 2 filas en el “DataSet”, las cuales corresponden a: ‘QueryRetrieveLevel’ y ‘PatientID’

Siendo la respuesta por parte del Sistema Origen con 3 estudios médicos, donde únicamente se incluyen 3 filas en el DataSet:

Las cuales corresponden al: ‘QueryRetrieveLevel’, ‘RetrieveAETitle’ y ‘PatientID’

De esta forma observamos grandes diferencias entre la respuesta generada por el Sistema Destino, cuando enviamos desde nuestro servicio interno, frente a cuando remitimos la consulta simulando ser sistema origen por TCP de DICOM

¿ustedes cómo recomiendan continuar?

Muchas gracias, Alberto, por leer, responder, y tomar su tiempo para atendernos

Gracias a ustedes por indicarnos, ordenarnos, recomendarnos, sugerirnos, técnicas, documentación, ejemplos; mediante los cuales investigar, depurar, indagar esta cuestión

Un saludo

Es de agradecer tu respuesta Alberto

Son un apoyo tus explicaciones, ejemplos y enlaces

Los revisamos y te responderíamos