Hola Alberto,

Gracias por la respuesta.

Lo estudiamos internamente, probamos concienzudamente y te respondemos en cuanto nos sea posible.

Muchas gracias de antemano.

Un saludo.

Adicionalmente hemos leído con atención:

https://docs.intersystems.com/healthconnectlatest/csp/docbook/DocBook.UI...

https://docs.intersystems.com/healthconnectlatest/csp/docbook/DocBook.UI...

https://docs.intersystems.com/healthconnectlatest/csp/docbook/DocBook.UI...

https://docs.intersystems.com/healthconnectlatest/csp/docbook/DocBook.UI...

https://docs.intersystems.com/irisforhealthlatest/csp/docbook/DocBook.UI...

https://community.intersystems.com/post/making-jwtoauth20

Sin embargo, sí seguimos con la misma cuestión:

¿Qué vía existe para "llamar", "invocar", "comunicar" desde los otros entornos ( por ejemplo INTEGRACION ) con el Servidor de Recursos de PREPRODUCCION con el fin de Validar el Token?

Es decir la pregunta de otra forma sería:

¿Qué mecanismo existe para desde un Entorno A (Integración) se comunique con un Entorno B (Preproducción) con la misión de Validar el Token desde el Entorno A empleando el Servidor de Recursos centralizados disponible en el Entorno B?

Muchísimas gracias por su atención, y gracias por sus respuestas.

Un saludo
 

Alberto, para añadir más detalles:

Puesto que los 2 son, Servicios.DICOM.VNAtoPACSImagenesMedicasv01r00 y Servicios.DICOM.MOVEImagenesMedicasv01r00 son de la clase: "EnsLib.DICOM.Service.TCP" con Adaptador: "EnsLib.DICOM.Adapter.TCP"

Se pueden unificar

Ahora bien, la cuestión a resolver es: ¿Qué es preferible 1 único Servicio donde se aúnan los FIND y MOVE/GET o 2 servicios con los FIND y MOVE/GET separados? ¿separados o juntos?

Lo que sin embargo el reto seria que necesitamos si o si que ambos servicios apunten a los 2 Procesos:

Es decir que en el Parámetro: "Nombre de configuración de destino dúplex" [Indicar los 2 procesos] por ejemplo: Procesos.DICOM.VNAtoPACSImagenesMedicasv01r00,DICOM Move Process

✍️📤Es decir: se enviarian los FIND a los 2 procesos por ejemplo:

 Procesos.DICOM.VNAtoPACSImagenesMedicasv01r00,DICOM Move Process

y los MOVE/GET también se enviarían indistintamente a los 2 procesos:

 Procesos.DICOM.VNAtoPACSImagenesMedicasv01r00,DICOM Move Process

🔎🔎

Además NO sería trivial el discriminar, y/o distinguir entre un DICOM con comando FIND de otro DICOM (MOVE/GET) puesto que previamente existe el establecer conexión, mediante "EnsLib.DICOM.Notify.Established"

También mencionar que el cribar un FIND de un MOVE/GET sería hacerlo mediante GetValueAt("CommandSet.AffectedSOPClassUID") = [Número del FIND/ Número del MOVE/GET]

Actualmente la foto del circuito es:

¿Qué es preferible 1 único Servicio donde se aúnan los FIND y MOVE/GET o 2 servicios con los FIND y MOVE/GET separados? ¿separados o juntos?

carteles vida fail desmotivaciones

Aunque quizá sea un poco subjetivo, nos gustaría conocer qué se recomienda

¿Qué es preferible 1 único Servicio donde se aúnan los FIND y MOVE/GET o 2 servicios con los FIND y MOVE/GET separados? ¿separados o juntos?
 

Muchas gracias de antemano Alberto, por leernos y respondernos.

Un saludo.
 

Buenos días Alberto:

Hemos estado trabajando con los GET.

Actualmente lo que hacemos es desde un Simulador origen dcm4che solicitar un get:

./getscu -b VNAPRE -c ESBPRE@XX.XXX.X.XXX:XXXX -m StudyInstanceUID="1.2.826.0.1.3680043.8.1055.1.20111102150758591.92402465.76095170" --store-tc "CTImageStorage:1.2.840.10008.1.2.4.91;1.2.840.10008.5.1.4.1.2.2.3,1.2.840.10008.1.2.1"  

El cual va mediante: ESBSSCC a otro ESBFUERTEV por su servicio dedicado:

Servicios.DICOM.MOVEImagenesMedicasv01r00
 
El cual tiene como clase:
 
EnsLib.DICOM.Service.TCP
 
Obteniendo así cada uno de los 361 estudios con ese StudyInstanceUID
 
Sin embargo se nos ha generado una duda.
Puesto que actualmente disponemos de 2 servicios,:

1 para los FIND "Servicios.DICOM.VNAtoPACSImagenesMedicasv01r00"

1 para los MOVE/GET "Servicios.DICOM.MOVEImagenesMedicasv01r00"

¿Qué es preferible 1 único Servicio donde se aúnan los FIND y MOVE/GET o 2 servicios con los FIND y MOVE/GET separados? ¿separados o juntos?

Hola Alberto,

Gracias por tu respuesta.

Estamos trabajando con el GET como nos has indicado.

Gracias de antemano Alberto.

Un saludo.

Buenos días Alberto,

Recientemente hemos estado indagando desarrollando y profundizando con DICOM para gestionar los FIND obteniendo el listado de imágenes médicas, con el objetivo de extraerlas desde los RISPACS hacia el ESB.

Alberto, agradeceríamos si nos puedes orientar y explicar lo siguiente: ¿estaría soportado realizar la Operacion Retrieve, en el ejemplo que nos explicas en el artículo actual?

La necesidad es el hecho de que quizá sería más apropiado en vez de guardar las imágenes DICOM mediante Move/Store; cachearlas, y trasladarlas desde los RISPACS (Sistemas Destinos) al Origen.

En concreto, lo que conocemos es:

🔎Query/Retrieve, or Q/R for short, is the DICOM service for searching images on the PACS and getting a copy of them to the workstation where they can be displayed.

Mientras que:

 📌C-MOVE is a DICOM command that means this: The calling AE (we) ask the called AE (the PACS) to send all the DICOM Instances that match the identifier to the target AE.

Parece que MOVE es enviar imágenes (guardándolas), mientras que Query/Retrieve es cachear (copiar) las imágenes DICOM.

Por favor, Alberto Fuentes; podrías indicarnos documentación referencias código ejemplos respecto a: ¿estaría soportado realizar la Operacion Retrieve, en el ejemplo que nos explicas en el artículo actual?

Muchas gracias de antemano por tu apoyo y respuestas.

Un saludo.

Hola Alberto,

Muchas gracias por las indicaciones.

Con lo que nos has explicado se ha verificado que es cuestión del simulador el hecho de que deje la etiqueta InstitutionName vacía.

Un saludo Alberto.

Hola Alberto,

Muchas gracias por tu ayuda

Hemos realizado lo que nos has recomendado:

Mostrar el contenido del DICOM mediante dcmdump:

  ./dcmdump "IImagen PatientID 732831 PatientName Milagros ReasonForStudy 350290  InstitutionName RISPACsCHUIMI   StudyDate 20220930.dcm"

Observamos el InstitutionName cumplimentado

632: (0008,0080) LO #14 [RISPACsCHUIMI] InstitutionName

Además, Alberto, hemos realizado los apartados 2 al 4 que has indicado, para generar un Servicio de Lectura de Ficheros DICOM puro.

De esta manera se muestra el InstitutionName con su valor correspondiente en el ESB:

(0008,0080) InstitutionName RISPACsCHUIMI

Alberto ¿de qué manera nos recomiendas, suguieres, expones continuar indagando?

¿Es el simulador, el cual está manipulando los campos de datos del DICOM en el envío?

Para construir el repositorio BBDD simulada empleamos:

./dcmdir -c ./shared/dicom/CHUIMI/DICOMDIR --fs-id SAMPLEDICOMS --fs-desc ./shared/dicom/CHUIMI/descriptor ./shared/dicom/CHUIMI

Una vez generada, iniciamos el repositorio a partir de la BBDD previa:

./dcmqrscp --ae-config ./shared/dicom/CHUIMI/ae.properties -b VNAPRE:11110 --dicomdir ./shared/dicom/CHUIMI/DICOMDIR  

Y para llevar a cabo el FIND empleamos:

./findscu -b VNAPRE -c ESBPRE@10.136.4.141:19586 -m PatientID=12989575 -m PatientName="Milagros" -r StudyInstanceUID -r PatientName -r StudyDate -r InstitutionName -r ReasonForStudy

Alberto ¿de qué manera nos recomiendas depurar para profundizar en las causas y resolver la situación?

Muchas gracias de antemano

Un saludo

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 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