DICOM: ¿ Obtenemos respuesta "corta" al Simular ser Sistema Origen desde línea de comando hacia Servicio TCP de DICOM, con respecto a un Servicio de Studio clásico de DICOM？

Question

Pregunta

Yone Moreno · 30 mar, 2022

Buenos días,

Primero, ante todo, muchas gracias de antemano por leernos y responder

Además, agradecer cualquier apoyo, porque es un alivio, apoyo, aporte, auxilio contar con personas con más entendimiento, conocimiento y práctica.

Existe la siguiente necesidad:

Se dispone de 2 circuitos:

1º Circuito DICOM de "Studio" ( Servicio clásico )

Servicio: clase: DICOM.BS.QueryService

Proceso: clase: DICOM.BP.QueryProcess

Operacion: clase: EnsLib.DICOM.Operation.TCP

Probamos desde la "Salida" del "Studio" mediante:

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

Donde "102030" es el PatientID del usuario

Lo interesante aquí es la traza:

A nivel visual:

Lo importante, enviamos en la petición a Destino en el DICOM.Document:

Recibimos bastante contenido:

Sin embargo, mediante el otro circuito hay discrepancias:

2º Circuito DICOM de TCP( Se prueba por línea de comandos )

Servicio: clase: EnsLib.DICOM.Service.TCP

Proceso: clase: DICOM.BP.QueryProcess

Operacion: clase: EnsLib.DICOM.Operation.TCP

Para probar ejecutamos:

./findscu -b VNAPRE -c ESBPRE@10.XWZ.4.ABC:19XYZ -m PatientID="102030"

La traza visual:

Siendo lo enviado, a sistema destino, mediante DICOM.Document:

Aquí viene la cuestión:

¿ por qué sale muy poca informacion en la respuesta del Destino ?

En particular la traza a nivel de línea de comandos:

$ ./findscu -b VNAPRE -c ESBPRE@10.[IP_Destino]:19586 -m PatientID="102030"
10:30:38.820 INFO  - Initiate connection from 0.0.0.0/0.0.0.0:0 to 10.[IP_Destino]:19586
10:30:38.867 INFO  - Established connection Socket[addr=/10.[IP_Destino],port=19586,localport=52515]
10:30:38.888 DEBUG - /10.[IP_Origen]:52515->/10.[IP_Destino]:19586(1): enter state: Sta4 - Awaiting transport connection opening to complete
10:30:38.890 INFO  - VNAPRE->ESBPRE(1) << A-ASSOCIATE-RQ
10:30:38.890 DEBUG - A-ASSOCIATE-RQ[
  calledAET: ESBPRE
  callingAET: VNAPRE
  applicationContext: 1.2.840.10008.3.1.1.1 - DICOM Application Context Name
  implClassUID: 1.2.40.0.13.1.3
  implVersionName: null
  maxPDULength: 16378
  maxOpsInvoked/maxOpsPerformed: 0/0
  PresentationContext[id: 1
    as: 1.2.840.10008.5.1.4.1.2.2.1 - Study Root Query/Retrieve Information Model - FIND
    ts: 1.2.840.10008.1.2 - Implicit VR Little Endian
    ts: 1.2.840.10008.1.2.1 - Explicit VR Little Endian
    ts: 1.2.840.10008.1.2.2 - Explicit VR Big Endian (Retired)
  ]
]
10:30:38.923 DEBUG - VNAPRE->ESBPRE(1): enter state: Sta5 - Awaiting A-ASSOCIATE-AC or A-ASSOCIATE-RJ PDU
10:30:38.936 INFO  - VNAPRE->ESBPRE(1) >> A-ASSOCIATE-AC
10:30:38.937 DEBUG - A-ASSOCIATE-AC[
  calledAET: ESBPRE
  callingAET: VNAPRE
  applicationContext: 1.2.840.10008.3.1.1.1 - DICOM Application Context Name
  implClassUID: 1.2.840.114475.1
  implVersionName: ENSDICOM
  maxPDULength: 16378
  maxOpsInvoked/maxOpsPerformed: 1/1
  PresentationContext[id: 1
    result: 0 - acceptance
    ts: 1.2.840.10008.1.2 - Implicit VR Little Endian
  ]
]
10:30:38.938 DEBUG - VNAPRE->ESBPRE(1): enter state: Sta6 - Association established and ready for data transfer
10:30:38.946 INFO  - VNAPRE->ESBPRE(1) << 1:C-FIND-RQ[pcid=1, prior=0
  cuid=1.2.840.10008.5.1.4.1.2.2.1 - Study Root Query/Retrieve Information Model - FIND
  tsuid=1.2.840.10008.1.2 - Implicit VR Little Endian]
10:30:38.947 DEBUG - VNAPRE->ESBPRE(1) << 1:C-FIND-RQ Command:
(0000,0002) UI [1.2.840.10008.5.1.4.1.2.2.1] AffectedSOPClassUID
(0000,0100) US [32] CommandField
(0000,0110) US [1] MessageID
(0000,0700) US [0] Priority
(0000,0800) US [0] CommandDataSetType

10:30:39.006 DEBUG - VNAPRE->ESBPRE(1) << 1:C-FIND-RQ Dataset:
(0008,0052) CS [STUDY] QueryRetrieveLevel
(0010,0020) LO [102030] PatientID

10:30:39.170 INFO  - VNAPRE->ESBPRE(1) >> 1:C-FIND-RSP[pcid=1, status=ff00H
  cuid=1.2.840.10008.5.1.4.1.2.2.1 - Study Root Query/Retrieve Information Model - FIND
  tsuid=1.2.840.10008.1.2 - Implicit VR Little Endian]
10:30:39.171 DEBUG - VNAPRE->ESBPRE(1) >> 1:C-FIND-RSP Command:
(0000,0002) UI [1.2.840.10008.5.1.4.1.2.2.1] AffectedSOPClassUID
(0000,0100) US [32800] CommandField
(0000,0120) US [1] MessageIDBeingRespondedTo
(0000,0800) US [65278] CommandDataSetType
(0000,0900) US [65280] Status

10:30:39.173 DEBUG - VNAPRE->ESBPRE(1) >> 1:C-FIND-RSP Dataset:
(0008,0052) CS [STUDY] QueryRetrieveLevel
(0008,0054) AE [VNAPRE] RetrieveAETitle
(0010,0020) LO [102030] PatientID

10:30:39.175 INFO  - VNAPRE->ESBPRE(1) >> 1:C-FIND-RSP[pcid=1, status=ff00H
  cuid=1.2.840.10008.5.1.4.1.2.2.1 - Study Root Query/Retrieve Information Model - FIND
  tsuid=1.2.840.10008.1.2 - Implicit VR Little Endian]
10:30:39.175 DEBUG - VNAPRE->ESBPRE(1) >> 1:C-FIND-RSP Command:
(0000,0002) UI [1.2.840.10008.5.1.4.1.2.2.1] AffectedSOPClassUID
(0000,0100) US [32800] CommandField
(0000,0120) US [1] MessageIDBeingRespondedTo
(0000,0800) US [65278] CommandDataSetType
(0000,0900) US [65280] Status

10:30:39.176 DEBUG - VNAPRE->ESBPRE(1) >> 1:C-FIND-RSP Dataset:
(0008,0052) CS [STUDY] QueryRetrieveLevel
(0008,0054) AE [VNAPRE] RetrieveAETitle
(0010,0020) LO [102030] PatientID

10:30:39.176 INFO  - VNAPRE->ESBPRE(1) >> 1:C-FIND-RSP[pcid=1, status=ff00H
  cuid=1.2.840.10008.5.1.4.1.2.2.1 - Study Root Query/Retrieve Information Model - FIND
  tsuid=1.2.840.10008.1.2 - Implicit VR Little Endian]
10:30:39.176 DEBUG - VNAPRE->ESBPRE(1) >> 1:C-FIND-RSP Command:
(0000,0002) UI [1.2.840.10008.5.1.4.1.2.2.1] AffectedSOPClassUID
(0000,0100) US [32800] CommandField
(0000,0120) US [1] MessageIDBeingRespondedTo
(0000,0800) US [65278] CommandDataSetType
(0000,0900) US [65280] Status

10:30:39.177 DEBUG - VNAPRE->ESBPRE(1) >> 1:C-FIND-RSP Dataset:
(0008,0052) CS [STUDY] QueryRetrieveLevel
(0008,0054) AE [VNAPRE] RetrieveAETitle
(0010,0020) LO [102030] PatientID

Observamos que existen 3 respuestas:

10:30:39.170 INFO - VNAPRE->ESBPRE(1) >> 1:C-FIND-RSP

10:30:39.175 INFO - VNAPRE->ESBPRE(1) >> 1:C-FIND-RSP

10:30:39.176 INFO - VNAPRE->ESBPRE(1) >> 1:C-FIND-RSP

Sin embargo ¿ por qué sale muy poca informacion en la respuesta del Destino ?

En concreto, en el circuito 1º obtenemos:

SpecificCharacterSet, StudyDate, StudyDescription, PatientName, StudyInstanceUID

Mientras que en el TCP de DICOM, en el 2º circuito:

Unicamente: QueryRetrieveLevel, RetrieveAETitle, PatientID

¿Ustedes nos podrían, por favor, indicar documentación, ejemplos de código, trazas visuales, o referencias de cualquier tipo que nos aporten para depurar?

Muchas gracias de antemano por su tiempo, al leer y responder

Un saludo

Product version: Caché 2017.1

$ZV: 2017.2.1

Debate (3)2

Inicie sesión o regístrese para continuar

Alberto Fuentes · 31 mar, 2022

Hola Yone,

Imagino que habrá diferencias entre el C-FIND que se envía en el primer caso y el segundo.

En el primer caso, el que retorna más resultados, entiendo que es el caso del ejemplo. Revisa cómo se está generando exactamente ese C-FIND:

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

En principio, se está haciendo un PatientRootQuery (tAffectedSOPClassUID).

No sé si puede servirte para algo, pero en el herramienta findscu creo que hay una opción para especificar el Information Model a utilizar:

https://github.com/dcm4che/dcm4che/blob/master/dcm4che-tool/dcm4che-tool...

-M <name>                                specifies Information Model.
                                          Supported names: PatientRoot,
                                          StudyRoot, PatientStudyOnly,
                                          MWL, UPSPull, UPSWatch,
                                          UPSQuery, HangingProtocol or
                                          ColorPalette. If no Information
                                          Model is specified, StudyRoot
                                          will be used.

0 0

score 0 · Answer 1 · 2022-03-31T11:10:53-04:00

Yone Moreno · 31 mar, 2022

Es de agradecer tu respuesta Alberto

Son un apoyo tus explicaciones, ejemplos y enlaces

Los revisamos y te responderíamos

0 0

score 0 · Answer 2 · 2022-04-01T06:00:48-04:00

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

DICOM: ¿ Obtenemos respuesta "corta" al Simular ser Sistema Origen desde línea de comando hacia Servicio TCP de DICOM, con respecto a un Servicio de Studio clásico de DICOM？

Nuestras redes sociales

Recursos InterSystems