El problema

En un entorno clínico acelerado, en el que la toma rápida de decisiones es crucial, la falta de sistemas eficientes de almacenamiento y acceso a los documentos plantea varios obstáculos. Aunque existen soluciones de almacenamiento de documentos (por ejemplo, FHIR), el acceso y la búsqueda eficaz de datos específicos de pacientes dentro de esos documentos puede suponer todo un reto.

La base de datos documental de InterSystems IRIS (DocDB) ofrece un enfoque flexible y dinámico para gestionar datos. DocDB aprovecha el poder de JSON (JavaScript Object Notation), proporcionando un entorno sin esquemas para el almacenamiento y la recuperación de datos.

Es una herramienta poderosa que permite a los desarrolladores evitar un montón de código repetitivo cuando se interactúra con aplicaciones existentes, serialización, paginación e integración. La sencillez del uso de DocDB con los servicios y operaciones API REST permite mejorar en la producción y gestión de APIs.

Aquí podéis revisar la documentación oficial. En este artículo mostraremos un caso de uso en el que DocDB encaja perfectamente.

Introducción

A InterSystems le gustaría optimizar IRIS para aprovechar las modernas extensiones del conjunto de instrucciones de la CPU. Eso está genial para el rendimiento del producto, pero ¿cómo sabéis si vuestra CPU seguirá siendo compatible con las nuevas versiones de IRIS? En este artículo os explico cómo saber la familia de microarquitectura de la CPU, y cómo averiguar las extensiones específicas del conjunto de instrucciones de la CPU.

¡Hola Comunidad!

Me gustaría presentaros una nueva utilidad para importar CSV a IRIS - ¡csvgenpy!

Instalación

USER>zpm "install csvgenpy"

Uso:

do ##class(shvarov.csvgenpy.csv).Generate("file or url","table","schema")

Ejemplo:

USER>do ##class(shvarov.csvgenpy.csv).Generate("https://raw.githubusercontent.com/datasciencedojo/datasets/master/titanic.csv","titanic","data")

Esto creará la tabla y la clase data.titanic en IRIS y a continuación cargará los datos. Podéis probarlo con:

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

Esta es una aplicación de prueba, que muestra cómo usar el Repositorio FHIR de InterSystems IRIS for Health para crear un Repositorio FHIR con autorización OAuth2. El endpoint FHIR será el servidor de recursos y el Google OpenId será el servidor de autorización.

Al empezar el desarrollo con IRIS tenemos un kit de distribución o, en el caso de Docker, obtenemos la imagen Docker y después a menudo tenemos que iniciarla y configurar el entorno de desarrollo. Puede que necesitemos crear bases de datos, namespaces, activar/desactivar algunos servicios, crear recursos. Muchas veces necesitamos importar el código y los datos a la instancia de IRIS y ejecutar algún código personalizado para iniciar la solución.

Hola!

Aquí les dejo un video que hice para mostrar cómo se configura la alta disponibilidad (mirroring) en IRIS en un ambiente docker, el video esta completamente en español y los archivos necesarios estarán en mi Github.

El video en YouTube en https://youtu.be/rBdiTxavWmU

https://github.com/I-am-seven/iris-mirroring-video

Espero les sea de Utilidad!

Joel

Preguntas frecuentes de InterSystems

Si se establece una relación y hay una gran cantidad de n en una proporción de 1:n, se puede consumir una gran cantidad de memoria debido al procesamiento secuencial de la relación.

Después de hacer referencia a un objeto de muchos lados en un programa y cambiarlo internamente, simplemente liberar la variable que contiene el OREF (eliminarla, establecer otro valor, etc.) no liberará el objeto de muchos lados ni el objeto de relación. Ésta es la causa.

Necesitaba averiguar en tiempo de ejecución si el último test había fallado o no.

Después de investigar un poco, aquí está el código:

ClassMethod isLastTestOk() As %Boolean
{
  set in = ##class(%UnitTest.Result.TestInstance).%OpenId(^UnitTest.Result)
  for i=1:1:in.TestSuites.Count() {
    #dim suite As %UnitTest.Result.TestSuite
    set suite = in.TestSuites.GetAt(i)
    return:suite.Status=0 $$$NO
  }
  quit $$$YES
}

Si tenéis tablas de sistema que implementan la funcionalidad "VERSIONPROPERTY", podéis encontraros con el error 5800. Este artículo explica cómo se produce este error y proporciona soluciones para resolver el problema.

Cuando se implementa la comprobación de versiones, la propiedad especificada por VERSIONPROPERTY se incrementa automáticamente cada vez que se actualiza una instancia de la clase (ya sea mediante objetos o SQL).

Por ejemplo: