Nueva publicación
Pregunta
Yone Moreno · Mar 30

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？

#Code Snippet #Caché

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 ?

¿ 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
0
0 63
Debate (3)2
Inicie sesión o regístrese para continuar
Alberto Fuentes · Mar 31

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
Yone Moreno · Mar 31

Es de agradecer tu respuesta Alberto

Son un apoyo tus explicaciones, ejemplos y enlaces

Los revisamos y te responderíamos

0 0
Yone Moreno · Abr 1

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

0 0