Hola Yone,

Entiendo que quieres montar lo siguiente:

  • Cliente externo (e.g. Postman) que solicite token a servidor de autorización.
  • Servidor de autorización en PREPRODUCCIÓN.
  • Servicio REST en INTEGRACIÓN que actúe como servidor de recursos, que reciba y valide el token.

En principio estás en un escenario como el de Client Credentials del workshop-iris-oauth2.

En resumen, tendrías que configurar lo siguiente:

  • Definir servidor autorización OAuth en PREPRODUCCIÓN.
  • Registrar cliente en servidor de autorización en PREPRODUCCIÓN: tendrás ClientID y ClientSecret. Lo necesitarás para solicitar token.
  • Definir servidor de recursos en INTEGRACIÓN como se hacía en este paso.
    • Cuando defines el servidor de recursos, tienes que indicar cuál es el endpoint del servidor de autorización.
    • Tienes que asignarle un nombre, e.g. "resserver"
    • En el código del servidor de recursos, en INTEGRACIÓN, en el método ValidateJWT sólo necesitas referirte al nombre que le hayas puesto al servidor de recursos (e.g. "resserver").
    • El método ValidateJWT ya se encarga de utilizar tu definición de servidor de recursos "resserver", donde tenías el endpoint del servidor de autorización, y validar el token que le pases.

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.

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.

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.

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.

Hola de nuevo, Yone:

Puedes probar a subir los timeous por ejemplo a 60s.

Además, puedes activar las trazas detalladas de interoperabilidad. Quizá te ponga así más información. Mira en:
https://docs.intersystems.com/irisforhealth20221/csp/docbook/Doc.View.cl...

set ^Ens.Debug("TraceCat","queue")=1

En otro caso, quizá habría que ya verlo a nivel de red (e.g. captura con WireShark y demás), o si lo quieres ver muy en detalle abrir un caso WRC.

Hola Yone,

En IRIS y Health Connect se soportan adaptadores para recibir, enviar y tratar mensajes DICOM con dispositivos que soporten el protocolo. En la documentación del producto encuentras información relativa a estos puntos que se soportan.

Pero el estándar DICOM en sí tiene su propia definición y documentación (como ocurre co HL7, FHIR, etc.).
Échale un vistazo por ejemplo a https://www.dicomstandard.org/current. Encontrarás los diferentes capítulos del estándar y su especificación.

Hola Yone,

Podrían ser errores de red, o de timeouts durante la transferencia.

Echa un vistazo a Tasks for DICOM Productions, en particular a Configuring a DICOM Duplex Business Host. Tienes varios configuraciones que quizá te ayuden como TraceVerbosity, ARTIM, TXTIM para mostrar más o menos información y modificar ciertos timeouts.

También te puede servir lo que te dice el otro lado de la comunicación (lo que parece que es el simulador).

De todas formas, ten en cuenta que parece que estás trabajando con un simulador y a veces pueden tener ciertas limitaciones.

Hola Yuri,

Una opción muy sencilla es utilizar $zdatetime, por ejemplo:

write $translate($zdatetime($horolog, 3, 1)," ","T")

En la documentación puedes ver distintos formatos disponibles para fecha y hora con los que puedes jugar con $zdatetime.

Hola Luis,

Parece que estás en una versión muy antigua (2012) y utilizando una tecnología (ZEN) también antigua. ZEN se soporta aún por compatibilidad, pero échale un vistazo al InterSystems IRIS Migration Guide en el WRC > Software Distribution > Docs.

Sobre tu cuestión, el error probablemente viene dado de que intentas establecer el value de algo nulo. No consigues referencia el parámetro. Prueba con el ejemplo que te ha pasado Mario, o incluso mejor añade un id al parámetro para que puedas referenciarlo directamente a través del identificador.

<tablePane id="table"
           queryClass="MyApp.Employee"
           queryName="ListEmployees">
    <parameter value="Sales" id="param1"/>
    <parameter value="NEW YORK"/>
</tablePane>

Mira por ejemplo en Query Parameters