ir a la publicación Alberto Fuentes · 3 feb, 2025 Hola César, Es probable que tengas alguna configuración en tu Apache que te impida probarlo correctamente. Puede ser un tanto difícil solucionar en un par de comentarios del artículo :) Lo que puedes hacer es probar el ejemplo que ya está preparado en iris-flask-template y así puedes probar directamente con todos los endpoints.
ir a la publicación Alberto Fuentes · 23 sep, 2024 Hola Óscar, Veo que usas llamadas a ITB.HL7.Util.Convert así que parece que estás utilizando Healthcare HL7 XML para la conversión de HL7 entre formato XML y pipes. Creo que lo que necesitas es poder trabajar con los campos OBX.5 con un tipo de datos dinámico (normalmente el que se indica en OBX.2). En Healthcare HL7 XML tienes explicado como implementar esa opción en Segment fields with Dynamic Data Structures.
ir a la publicación Alberto Fuentes · 9 ago, 2023 Hola, Incluyo aquí la respuesta de Lorezo Scalese utilizando $zdate y $zdateh publicada en la comunidad en inglés : Write $ZDATE($ZDATEH("13/Jun/23",8,,6),8) El resultado sería: 20230613
ir a la publicación Alberto Fuentes · 1 jun, 2023 Hola Kurro, Me parece que en las reglas del enrutador no se puede. Una posible alternativa sería: Desde el enrutador, enviar el mensaje a un Business Process que se encargue de enviar dinámicamente lo que necesites Creas el Business Process anterior, y extraes el valor que necesites del HL7 (e.g. usando .GetValueAt()) y después desde el Business Process sí que puedes hacer envío dinámico utilizando justo esa sintaxis que has puesto (@destino) en la llamada.
ir a la publicación Alberto Fuentes · 17 mar, 2023 Hola Yone, En este caso entiendo que tienes un recurso FHIR en forma de JSON y quieres incluir o no cierta parte en función de si tienes un objeto vacío o no. Puedes probar algo así: primero creas el recurso con las propiedades que seguro vas a incluir, y después a continuación incluyes la lógica para las propiedades que incluirás según ciertas condiciones: set resource = { "resourceType": "Observation", "id": (..Id), "status": "final", "code": { "coding": [ ] }, "subject": { "reference": ("Patient/"_..Patient.Id) }, "effectiveDateTime": ($tr(..TimeStamp, " ", "T")), "valueQuantity": { } } if ..Code="BodyTemp" { set resource.code.coding."0" = { "system": "http://loinc.org", "code": "8310-5", "display": "Body temperature" } set resource.valueQuantity.unit = "C" set resource.valueQuantity.system = "http://unitsofmeasure.org" set resource.valueQuantity.code = "Cel" do resource.valueQuantity.%Set("value", ..ValueNM, "number") }
ir a la publicación Alberto Fuentes · 17 mar, 2023 Hola Yone, El error que te devuelve el servicio quizá esté relacionado con que recibe un elemento que no espera. Te diría que intentes aislarlo lo máximo posible: * Tener un método en Health Connect que te permita lanzar una prueba controlada y puedas investigar. Así puedes lanzar mensaje al cliente de WebService que te está dando el error siempre de la misma forma y probar tus cambios sólo desde Health Connect. * Activar el log de SOAP para tus pruebas. * Intentar reducir esas mínimas diferencias. Eliminando campos o cambiando configuraciones. Si tienes alguna duda en concreto sobre cómo intentar influir en cómo se proyectan los campos en el XML, puedes crear un caso a soporte WRC con la duda concreta!
ir a la publicación Alberto Fuentes · 23 feb, 2023 Mmm exactamente lo mismo no lo sé, pero en el pasado hemos utilizado `EnsLib.PubSub` para alguna funcionalidad que necesitábamos pero terminábamos desarrollando nuestras propias clases para gestionar la complejidad que nos hacía falta. De todas maneras, aún estamos experimentando con esta utilidad :)
ir a la publicación Alberto Fuentes · 13 feb, 2023 Hola, Como comentó Dmitry en otro post, lo más sencillo es depurar utilizando VS Code: Por cierto, si necesitas una introducción sobre cómo utilizar VS Code (incluido depuración) échale un vistazo a https://github.com/intersystems-ib/workshop-vscode-iris
ir a la publicación Alberto Fuentes · 13 feb, 2023 Hola Yone, Le he echado un primer vistazo. Las peticiones que se hacen a /oauth2/token se gestionan en OAuth2.Server.Token:Process -> OAuth2.Server.Token:ProcessClientCredentials -> OAuth2.Server.Token:Authorize. Ese último método es el que retorna el error. En principio no veo un sitio donde puedas personalizar ese error rápidamente porque son clases internas. ¿Podrías por favor crear un caso de soporte WRC para que se pueda analizar en detalle allí? Gracias,
ir a la publicación Alberto Fuentes · 26 ene, 2023 Hola José Manuel, Prueba con usuario superuser y contraseña por defecto del sistema SYS
ir a la publicación Alberto Fuentes · 26 ene, 2023 Hola José Manuel, Creo que quizá la imagen que tiene el ejemplo tiene una versión de IRIS Community que ya ha caducado. En el directorio donde lo hayas descargado, modifica el fichero Dockerfile (al comienzo) y prueba a utilizar por ejemplo esta versión: ARG IMAGE=intersystemsdc/irishealth-ml-community:2022.2.0.368.0-zpm
ir a la publicación Alberto Fuentes · 24 ene, 2023 Hola! He visto que esta pregunta se nos pasó, por suerte en la comunidad en inglés te pudieron ayudar :) Por si a alguien le hace falta, dejo aquí el enlace a la respuesta en inglés: https://community.intersystems.com/post/dot-cleaning
ir a la publicación Alberto Fuentes · 20 dic, 2022 Actualización: Este módulo ahora está disponible en PyPI: Instalar utilizando PyPI pip3 install iris_pex_embedded_python Importa las clases ObjectScript, abrir una sesión de Embedded Python y ejecutar: from grongier.pex import Utils Utils.setup() Atención Si el módulo no está actualizado, asegúrate de borrar la versión antigua: pip3 uninstall iris_pex_embedded_python o borra manualmente el directorio grongier en <iris_installation>/lib/python/ o fuerza la instalación con pip: pip3 install --upgrade iris_pex_embedded_python --target <iris_installation>/lib/python/
ir a la publicación Alberto Fuentes · 29 nov, 2022 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.
ir a la publicación 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.
ir a la publicación 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.
ir a la publicación 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.
ir a la publicación 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.
ir a la publicación Alberto Fuentes · 23 sep, 2022 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.
ir a la publicación Alberto Fuentes · 22 sep, 2022 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.
