Introducción

Si alguna vez os habéis preguntado cómo depurar algunas solicitudes que se realizan hacia o desde IRIS, este es un pequeño tutorial sobre cómo se hace.

Durante un proyecto complejo, normalmente se obtienen las especificaciones y se implementa la comunicación entre IRIS y otros sistemas basándose en eso. Pero del papel al mundo real normalmente hay un gran trecho y hay que saber por qué se recibe un error en un parámetro o en una cabecera, por qué no se reciben los datos, etc.

Si la conexión es una conexión http sencilla, no hay problema, siempre se puede iniciar tcpdump y capturar el tráfico, pero ¿qué pasa con la comunicación https?

¿Qué tal tener una interfaz web limpia, algo que iniciáis y después el desarrollador puede mirar ese portal cuando quiera?

Si alguna vez habéis estado en esta situación, una solución sencilla es mitm proxy ( https://mitmproxy.org/ ).

Este programa tiene la capacidad de actuar como un proxy (se puede configurar en el Business Operation, por ejemplo), un proxy transparente (lo que me gusta), proxy upstream (proxy transparente que envía la conexión a otro proxy), etc.

Experiencia & comentarios del curso online "Hands-On with InterSystems API Manager for Developers"

Con mis conocimientos básicos de contenedores Docker y API REST, me gustaría probar el uso del administrador de APIs de InterSystems para gestionar las API y los microservicios. Completé este curso en línea utilizando mi instancia local de IRIS como host (sistema operativo Windows) e IAM ejecutándose en una máquina virtual Linux.

Este es un artículo de la página de "Preguntas frecuentes" (FAQ) de InterSystems.

1. Exportar API

a. Usa $system.OBJ.Export() para especificar rutinas individuales para exportar. Por ejemplo:

El formato que debes especificar es: NombreDeLaRutina.extension, y la extensión puede ser: mac, bas, int, inc, obj.

HL7 (Health Level 7) es un conjunto de especificaciones técnicas para el intercambio informatizado de datos clínicos, financieros y administrativos entre Sistemas de Información Hospitalaria (HIS). Estas especificaciones se integran de diversas formas en el conjunto de Normas oficiales americanas (ANSI) e Internacionales (ISO).

La L7 de HL7 indica que es una norma que opera en la capa 7, es decir, en la capa de aplicación, del modelo OSI. Esto significa que HL7 no tiene que tener en cuenta las consideraciones de seguridad en el intercambio, ni las de transporte de mensajes (de eso se encargan capas de nivel inferior como SSL/TLS para la seguridad o TCP para el transporte de datos, por ejemplo). Para ser más precisos, la capa 7 soporta las comunicaciones para los procesos y aplicaciones de usuario final y la presentación de datos para las aplicaciones de software orientadas al usuario. Al ser la capa más alta del modelo OSI, y la más cercana al usuario final, la capa 7 proporciona funciones específicas de la aplicación, como identificar la comunicación de los partners y la calidad del servicio entre ellos, determinar la disponibilidad de recursos, considerar la privacidad y la autenticación del usuario, y sincronizar la comunicación, así como conectar la aplicación con los niveles inferiores del modelo OSI.

¡Bienvenidos, estimados miembros de la comunidad!

En este artículo vamos a demostrar el gran potencial que IRIS/HealthConnect pone a disposición de todos sus usuarios con el uso de Python Embebido y lo vamos a hacer mediante el desarrollo de una pequeña producción que nos va a permitir reconocer e identificar las caras presentes en un archivo JPG a partir de unas imágenes que usaremos como referencia.

En nuestro artículo anterior vimos como podíamos capturar ficheros de tipo DICOM ubicados en una carpeta de nuestro servidor y como los enviábamos a un PACS (en nuestro caso la solución open source ORTHANC) para su almacenamiento y consulta. Pues bien, en este artículo vamos a tratar el movimiento opuesto.

¡Hola Comunidad!

Recientemente tuve que configurar un servidor FHIR local usando IRIS for Health y creo que encontré la forma más sencilla y simple de hacerlo.

Simplemente ejecuta estas dos líneas en el terminal:

docker run --rm --name my-iris -d --publish 9091:1972 --publish 9092:52773 intersystemsdc/irishealth-community

y

docker exec -it my-iris iris session iris -U "USER" '##class(%ZPM.PackageManager).Shell("install fhir-server")'

Y tendrás un servidor FHIR ejecutándose localmente en http://localhost:9092/fhir/r4.

¡Y eso es todo!

El servidor FHIR usará la última versión de InterSystems IRIS for Health Community Edition y desplegará el servidor FHIR desde esta app a través del paquete IPM en el namespace FHIRSERVER.

Recientemente he estado trasteando con la utilización de IRIS como servidor para una conexión mediante web socket desde el frontend de una aplicación en NodeJS.

En esta URL tendréis la información relativa a las conexiones de web sockets tanto en modo cliente como en modo servidor: https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls...

Si estás desarrollando soluciones en IRIS y quieres utilizar Git, ¡es genial! Sólo tienes que utilizar VSCode con un repositorio git local y enviar los cambios al servidor, así de fácil.

Pero qué sucede si:

• Colaboras con otros desarrolladores en un entorno de desarrollo remoto compartido y quieres evitar la edición simultánea del mismo archivo
• Utilizas editores basados en el portal de administración para BPL, DTL, tablas dinámicas, cuadros de mando, etc. y quieres incluir esos elementos en el control de código de forma sencilla.
• Aún utilizas Studio para realizar algunas cosas y/o ocasionalmente vuelves a usarlo desde VSCode. O tu equipo todavía no ha adoptado completamente VSCode y algunos miembros del equipo todavía quieren utilizar Studio
• Trabajas en varios proyectos diferentes al mismo tiempo en el mismo namespace - digamos, en varios paquetes definidos mediante InterSystems Package Manager - y quieres trabajar con todos ellos desde una vista de edición de isfs (en vez de en varios proyectos distintos) con los cambios rastreados automáticamente en el repositorio de git apropiado

No sé si alguna vez os ha ocurrido. Nosotros trabajamos con VSCode para programar en IRIS, sincronizamos las clases con un servidor de desarrollo y lo tenemos conectado a un repositorio Git.

Tenemos proyectos que tienen cientos de clases, algunos hasta miles. Nos ocurre a menudo que, estamos realizando un desarrollo en un Namespace, y sin terminarlo, surge una incidencia que hay que solventar (o un nuevo desarrollo más prioritario). Dejamos el desarrollo que estamos haciendo, comiteando todo lo realizado hasta el momento.

Hola a todos,

Aquí estamos de nuevo. Nuevo año, nuevo concurso, nuevo proyecto, viejos motivos.

¡Triple Slash ya está en casa!

¡Hola desarrolladores!

Python tiene un ecosistema muy extenso y potente que contiene miles de librerías y paquetes disponibles, especialmente en Data Science.

Por ello, quería hacer un primer intento de usar la funcionalidad Python Embebido para, de forma sencilla, importar una librería de Python llamada datetime, generar datos con un componente timestamp y persistirlo en InterSystems IRIS for Health. También funcionará en InterSystems IRIS.

Schematron es un lenguaje de validación basado en reglas para hacer aserciones/afirmaciones sobre la presencia o ausencia de ciertos patrones en documentos XML. Un Schematron se refiere a una colección de una o más reglas que contienen pruebas. Los Schematron están escritos en una forma de XML, lo que los hace relativamente fáciles de inspeccionar, comprender y escribir para todos, incluso los que no son programadores.

Las rutinas con privilegios te permiten elevar los roles de un usuario mientras las utiliza. Estas rutinas con privilegios (Privileged Routine Application) pueden utilizarse con rutinas y también con clases / métodos.

Cuando las utilices, es importante asegurarse de incluir new $ROLES, antes de elevar los privilegios con AddRoles(). Por ejemplo:

 new $ROLES
 set status=$System.Security.AddRoles("MyPrivilegedRoutineApplication")