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?
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
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...
Es de agradecer tu respuesta Alberto
Son un apoyo tus explicaciones, ejemplos y enlaces
Los revisamos y te responderíamos
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