Nueva publicación
Pregunta
· 29 sep, 2022

[DICOM] InstitutionName se retorna vacío

#Principiante #Ensemble

Buenos días,

Nos gustaría compartir con ustedes una duda, y agradeceríamos que nos lean y nos respondan.

Actualmente disponemos de un fichero titulado: "Imagen PatientID 9358340 PatientName Milagros ReasonForStudy 350290 InstitutionName 350290  StudyDate 20220927.xml" , en el cual disponemos del siguiente InstitutionName:

    <DicomAttribute keyword="InstitutionName" tag="00080080" vr="LO">
        <Value number="1">350290</Value>
    </DicomAttribute>

Una vez que generamos el fichero DICOM mediante el comando del simulador dcm4che:

./xml2dcm -x "Imagen PatientID 9358340 PatientName Milagros ReasonForStudy 350290 InstitutionName 350290  StudyDate 20220927.xml" -o "Imagen PatientID 9358340 PatientName Milagros ReasonForStudy 350290 InstitutionName 350290  StudyDate 20220927.dcm"

 

Obtenemos la imagen en un fichero .dcm

Cuando nosotros la abrimos en el visor, sí se muestra InstitutionName = 350290

 

Sin embargo, cuando nosotros peticionamos desde el ESB con versión HealthShare 2020, mediante PatientName = "Milagros" , el simulador DESTINO, nos responde con esta imagen indicando el InstitutionName sin datos, es decir, vacío:

Petición:

DataSet

Tag Name Contents
(0008,0020) StudyDate (null)
(0008,0030) StudyTime (null)
(0008,0050) AccessionNumber (null)
(0008,0052) QueryRetrieveLevel STUDY
(0008,0061) ModalitiesInStudy (null)
(0008,0080) InstitutionName (null)
(0008,0090) ReferringPhysicianName (null)
(0008,1030) StudyDescription (null)
(0010,0010) PatientName Milagros
(0010,0020) PatientID (null)
(0010,0030) PatientBirthDate (null)
(0010,0040) PatientSex (null)
(0010,4000) PatientComments (null)
(0020,000D) StudyInstanceUID (null)

 

Respuesta del Simulador de DESTINO mediante herramienta dcm4che:

 

Respuesta vista desde el ESB:

En la respuesta del ESB se muestra lo mismo que emite el simulador, InstitutionName a (null)

 

 

Por favor, ¿podrían indicarnos documentación, referencias, ejemplos, pistas, clases o herramientas mediante las cuales depurar?

 

Gracias por su tiempo

 

Un saludo

Comentarios (4)2
Inicie sesión o regístrese para continuar
Alberto Fuentes · 30 sep, 2022

Hola Yone,

Para descartar que el simulador esté manipulando los campos de datos del DICOM en el envío, puedes probar lo siguiente:

  • Comprueba con el simulador los datos del fichero DICOM con dcmdump.
  • En una producción de interoperablidad, añade un Business Service que lea ficheros DICOM directamente (EnsLib.DICOM.Service.File)
  • Configura el Business Service para que envíe el DICOM como mensaje a cualquier Business Operation que tengas (incluso desactivado), sólo para probar.
  • Lee el fichero DICOM de prueba que has generado directamente con el Business Service y comprueba los campos.
0 0
Yone Moreno · 30 sep, 2022

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

0 0
Alberto Fuentes · 30 sep, 2022

Hola Yone,

Por lo que pones, parece que si lees el fichero DICOM en Health Connect directamente tienes los mismos valores que el dump usando el simulador o incluso el visor de DICOM que tienes.

Por tanto, es probable que el servicio de envío de DICOM por TCP que estés montando con el simulador quizá esté alterando algo la información antes de enviarla, o al menos la filtre.

Creo que estás haciendo un C-FIND request, y quizá en la respuesta (dependiendo de parámetros del C-FIND request, o del propio motor del simulador que hace de repositorio) se filtre la información. En ese caso, sería un tema ya específico del propio simulador.

0 0