Artículo
· 26 mayo, 2022 Lectura de 2 min
Open Exchange

Ejemplo de integración DICOM con un simulador

#Interoperabilidad #InterSystems IRIS for Health

¡Hola desarrolladores! ¿habéis tenido que desarrollar alguna integración DICOM alguna vez? Es posible que hayáis buscado ejemplo, o incluso un simulador con el que poder simular ciertas comandos. Aquí os paso un ejemplo que puede seros útil.

DICOM es un protocolo de comunicaciones muy extendido en sanidad en el ámbito de la imagen diagnóstica. Tanto con IRIS For Health como con Health Connect podéis desarrollar integraciones que empleen el protocolo DICOM, aquí tenéis disponible la documentación.

En muchas ocasiones, cuando estamos desarrollando la integración DICOM es muy útil que podamos contar con un simulador que haga las veces de un sistema externo (e.g. un PACS) y podamos probar por completo el circuito a implementar antes de conectarlo con un sistema real.

Aquí os paso un ejemplo que implementa dos ejemplos de integraciones DICOM utilizando IRIS For Health y también el simulador dcm4che.

Los dos circuitos de ejemplo que encontraréis son:

Recepción de un DICOM por TCP que contiene un informe PDF embebido

image

Búsqueda y recepción (Query / retrieve) de imágenes en un PACS

Circuito de búsqueda

image

Circuito de recepción

image

Cualquier aporte será bienvenido! :)

Ir a la aplicación en InterSystems Open Exchange
Comentarios (6)1
Inicie sesión o regístrese para continuar
Yone Moreno · 20 oct, 2022

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.

0 0
Alberto Fuentes · 24 oct, 2022

Hola Yone,

En el ejemplo está implementado utilizando un C-MOVE. Básicamente una vez elegidas las imágenes, se pide al PACS que te las envíe con un C-MOVE, y él te las hará llegar con un C-STORE.

Otra opción sería hacerlo con un C-GET. Y pedir la imagen directamente (creo que en el simulador dcm4chee también tienes opción para simular un C-GET). Y sí claro, podrías implementarlo utilizando un C-GET ya que es un mensaje DICOM y podrías enviarlo con Health Connect de la misma forma que se ha hecho con los otros.

0 0
Yone Moreno · 2 nov, 2022

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?
0 0
Yone Moreno · 2 nov, 2022

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.
 

1 0
Alberto Fuentes · 2 nov, 2022

jaja! es verdad: mejor, peor o poca diferencia? 

Bueno, en este caso yo creo que depende de cómo te sea más fácil mantener el código de tu producción.

Dependiendo de cuál es tu caso de uso de la integración, quizá te interese mantener por separado lo que tenga que ver con la búsqueda C-FIND y por otro servicio independiente el obtener el studio con un C-GET.

De esa forma podrías tener puntualmente deshabilitado uno y habilitado el otro por ejemplo.

0 0