¡Hola!

¿Te gustaría saber si tus transformaciones de datos funcionan como tienes previsto con un solo comando? ¿Y qué te parecería poder escribir pruebas unitarias de forma fácil y simple para las transformaciones de datos que utilizas?

Al hablar de interoperabilidad, normalmente encontraremos muchas transformaciones de datos involucradas. Esas transformaciones de datos se utilizan para convertir datos entre diferentes sistemas o aplicaciones en tu código, así que realmente se encargan de un trabajo muy importante.

Hoy en día es muy común que los datos que necesitas vengan de diferentes fuentes (e.g. aplicaciones externas e internas, distintas bases de datos y servicios, APIs, etc.). Además, seguro que tienes múltiples tipos de consumidores diferentes (e.g. usuarios finales, otras aplicaciones, servicios que publicas a terceros, etc.) y cada uno necesitará acceder a la información de forma diferente y para distintos objetivos. ¿Cómo construir una capa que de forma sencilla te permita gestionar estas necesidades? Hoy hablamos de Data Fabric 👈.

¡Hola Comunidad!

A lo largo de los años siempre he pensado en crear cosas nuevas, modificar las existentes, experimentar, probar, romper (siempre pasa), construir de nuevo, y empezar otra vez.

Los concursos promovidos por InterSystems son una excelente fuente de motivación. Obviamente los premios llaman la atención y eso no se puede negar. Pero no se trata solo de los premios/regalos - los concursos son un reto creativo, una oportunidad de crear, reimaginar, probar, experimentar... Y lo mejor de todo es que eres libre de hacer todo lo que quieras!

Así que ví estos concursos como una oportunidad de crear mi propio Y si...? (la serie en la que Marvel permite a los autores re-imaginar sus historias como quieran) y he sido muy afortunado de encontrar otra persona que recibe estas ideas con los brazos abiertos ¡Muchas gracias, @José Pereira!

En el último concurso de Interoperabilidad, creé el visualizador de mensajes Message Viewer y en este concurso de Interoperabilidad traigo de nuevo el Message Viewer, pero esta vez con Visual Trace!

Introducción: nuestra pequeña pero muy ambiciosa empresa llamada “Black Mushroom Studio” tuvo una idea para desarrollar un proyecto de comercio electrónico, y una aplicación móvil que permitiría a los usuarios pagar por ciertos bienes/servicios mediante un agregador de pagos.

Lo que teníamos inicialmente: un esqueleto para la aplicación en Android que, por supuesto, prefería la comunicación mediante HTTP y JSON, y un sistema de pago con una API, es decir, servicios web con contenido SOAP.

Objetivo: hacer que todo funcionara de manera conjunta.

Ejecutar modelos predictivos de forma nativa en un "Business Process" ("Proceso Empresarial") de InterSystems IRIS siempre ha sido, por supuesto, el objetivo de nuestro soporte para PMML, pero de alguna forma nunca formó parte del paquete porque había algunas dependencias y elecciones que era necesario analizar y decidir. En cualquier caso, gracias a algunas presiones y al código ofrecido amablemente por @Amir Samary (¡gracias de nuevo, Amir!), finalmente conseguimos empaquetarlo en un repositorio de GitHub para que lo disfruteis, lo valoreis y hagáis sugerencias.

Comenzamos esta nueva entrega recordando que hicimos en los anteriores artículos de configuración del EMPI:

• Instalado en modo Standalone el Patient Index sobre una instancia de HealthShare.
• Configurado los parámetros básicos para empezar a trabajar con el EMPI.
• Definido los índices y pesos particulares para nuestro proceso NICE.

Muy bien, estamos ya practicamente preparados para echar a rodar nuestro EMPI. Sólo nos queda un detalle, arrancar la producción creada por la instalación para poder empezar a trabajar.

Bienvenidos miembros de la comunidad a un nuevo artículo, en esta ocasión trataremos las capacidades de interoperabilidad que nos proporciona IRIS for Health para trabajar con ficheros DICOM.

Para ello vamos a montar un pequeño ejemplo haciendo uso de Docker. Al final del artículo podréis encontrar la URL de acceso a GitHub por si queréis verlo en acción en vuestros propios equipos.

Pero antes de empezar vamos a explicar que es DICOM:

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

¡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.

Posiblemente te hayas encontrado con esto y no supiste cómo evitarlo; o tal vez ni siquiera te diste cuenta...

Pero cuando se tienen componentes empresariales de la Producción de Interoperabilidad TCP (por ejemplo, un business service HL7), probablemente tienes (dependiendo de tu configuración de StayConnected) muchas entradas en el Registro de Eventos (Event log) de tipo Info. Cada entrada registraría una conexión o desconexión.

Por ejemplo:

¡Hola a tod@s!

Como saben, el visualizador de mensajes puede reenviar mensajes, pero no es adecuado para reenviar un gran número de estos (más de 100). Para ello, deben utilizar un código Caché Object Script como el siguiente:

¡Hola Comunidad!

Me alegra anunciar la nueva versión de iris-pex-embedded-python (v2.3.1) con una nueva interfaz de línea de comandos.

Esta línea de comandos se llama iop por Interoperability On Python.

Primero me gustaría presentar los principales cambios del proyecto desde la versión 1.

Breve historia del proyecto

La versión 1.0 fue una prueba de concepto para mostrar cómo el framework de interoperabilidad de IRIS se puede utilizar con un enfoque python first mientras sigue siendo compatible con cualquier código existente de ObjectScript.

¿Qué significa eso? Significa que cualquier desarrollador Python puede usar el framework de interoperabilidad de IRIS sin ningún conocimiento de ObjectScript.

Ejemplo:

from grongier.pex import BusinessOperation

class MyBusinessOperation(BusinessOperation):

    def on_message(self, request):
        self.log.info("Received request")

Genial, ¿cierto?

Recientemente empecé a estudiar interoperabilidad y la documentación oficial fue muy útil para comprender la operación de los business hosts, pero aún me costó lograr hacerlo con mis manos. Mis compañeros de trabajo me ayudaron hasta que logré crear una Demo de un sistema y aprender practicando. Por eso, quise escribir acá para pasar adelante la ayuda que tuve.

¡Hola Comunidad!

Para la sincronización de datos dentro de Caché/IRIS, existen varias formas de sincronizar objetos y tablas. A nivel de la base de datos se puede usar Shadowing o Mirroring

Esto funciona perfectamente, y si solo necesitas sincronizar una parte de tus datos, puedes partir tus datos en conjuntos más pequeños usando Global mapping. O, si necesitas sincronización bidireccional a nivel de clase/tabla, puedes usar la herramienta Object Synchronization.

El único límite de todos estos métodos es que sólo funcionan desde Caché/IRIS hacia Caché/IRIS. Si quieres sincronizar tus datos a alguna base de datos externa, necesitas alguna otra solución.