新しい投稿

検索

ダイジェスト
· 2026年1月13日

InterSystems Community Annual Newsletter 2025

Hello and welcome to the 2025 Annual Developer Community Newsletter.
General Stats
2,889 posts published in 2025:
  – 1,123 articles
  – 955 announcements
  – 755 questions
  – 56 discussions
4,592 members joined the Developer Community in 2025
25,158 posts published in total
25,553 members joined in total
Most Popular Articles
633
By Alessandra Carena
571
By Andre Larsen Barbosa
Most Discussed Articles 
Most Liked Articles
76
By Alessandra Carena
69
By Andre Larsen Barbosa
Most Popular Authors
Authors with the Most Articles
2025 at a GlanceInterSystems Developer Community
記事
· 2026年1月13日 7m read

Aspectos destacados de la búsqueda FHIR 2025.1 - Soporte de búsqueda relacionado con listas (_List, $find, Listas funcionales/"Actuales")

A veces es más conveniente, más eficiente y más seguro limitar las búsquedas FHIR a "listas" de recursos predefinidas.

Desde la versión v2025.1, soportamos varias funcionalidades relacionadas con listas en nuestro servidor FHIR.

Aquí las destacaré y os proporcionaré algunos ejemplos.

En general, podéis consultar los detalles sobre el recurso List en la documentación oficial de FHIR. 

Pero aquí tenéis una breve descripción basada en lo anterior:

El recurso List de FHIR representa una colección plana (opcionalmente ordenada) de registros utilizada para listas clínicas (por ejemplo, alergias, medicación, alertas, historiales) y para la gestión de flujos de trabajo (por ejemplo, seguimiento de pacientes, casos de enseñanza).
Las listas pueden ser homogéneas (un único tipo de recurso) o heterogéneas (tipos mezclados, por ejemplo, una lista de problemas que abarque Conditions, AllergyIntolerances y Procedures).
Usad List cuando necesitéis un conjunto seleccionado/filtrado que no pueda obtenerse mediante una consulta simple (por ejemplo, “alergias actuales” frente a todas las alergias registradas).
Consultar una List devuelve una instantánea curada por humanos en un momento determinado, mientras que consultar el endpoint del recurso normalmente devuelve un conjunto de datos más amplio, no curado, “tal como está ahora”.

En nuestras versiones más recientes (2025.1+) podéis encontrar un nuevo soporte para trabajar con Lists:

  • El parámetro de búsqueda _list

Consultad la documentación FHIR relacionada para una descripción completa. Consultad también nuestra documentación relacionada para conocer los detalles del soporte disponible (específicamente sobre búsquedas a nivel de tipo frente a búsquedas a nivel de sistema).

Con esta funcionalidad podéis definir, por ejemplo, una List de ciertos recursos, como Encounters o Patients, que queráis buscar según ellos, sin tener que detallar todos como múltiples parámetros de búsqueda.

Por ejemplo, podría definir una List de Patients:

 
PUT /List cURL snippet

Y luego buscarlos de esta manera:

 
GET /Patient?_list cURL snippet

Y recibir de vuelta una lista curada de los Patients que quería, en lugar de tener que “mencionar” a todos ellos en múltiples parámetros de búsqueda.

Y, por supuesto, hay muchos otros casos de uso.

  • Listas funcionales (incluida la operación personalizada $update-functional)

Un tipo especial de listas son las Listas Funcionales (o listas de “Current Resource”).

Consultad la documentación FHIR relacionada para una descripción completa.

Para vuestra comodidad, aquí tenéis una breve descripción basada en lo anterior:

Muchos sistemas clínicos mantienen listas de pacientes “actuales” (por ejemplo, una lista de problemas actuales y una lista de medicación actual), pero FHIR no puede inferir de manera fiable la “actualidad” simplemente examinando una única instancia de recurso.

Usando Condition como ejemplo, el mismo tipo de recurso puede registrarse con múltiples fines legítimos (entrada curada en la lista de problemas, queja/diagnóstico de un encuentro, contexto de flujo de trabajo diagnóstico o datos de derivación entrante), y Condition no tiene un elemento que distinga claramente estos usos.

Dado que diferenciar entre actual y pasado requeriría alteraciones retrospectivas (generando problemas de integridad y firma digital), una búsqueda normal de Condition para un paciente devolverá más que solo los “problemas actuales” curados, y limitarla a “solo actuales” ocultaría otros registros importantes de Condition.

Por lo tanto, si un Condition (o un registro similar) forma parte de la “lista actual” de un paciente podría determinarse según si está referenciado desde la List correspondiente.

A través de la API REST, esto se expresa mediante el mecanismo de búsqueda _listutilizando nombres estándar de listas funcionales (por ejemplo, GET [base]/AllergyIntolerance?patient=42&_list=$current-allergies), y el servidor puede soportarlo sin necesariamente exponer una instancia de List independiente.

Existen varios nombres “comunes” de listas funcionales, como $current-problems, $current-medications, $current-allergies y $current-drug-allergies (un subconjunto de alergias). 

Para permitir el mantenimiento de estas Listas Funcionales, hemos definido una Operación Personalizada llamada $update-functional, que permite crear y actualizar este tipo de listas. Podéis consultar más detalles en nuestra documentación.

Por ejemplo, podéis definir una lista de alergias actuales de la siguiente manera:

 
POST /List/$update-functional?for=...&name=\$current-allergies cURL snippet

Esto creará/actualizará la lista $current-allergies para un paciente específico (ID 34 en el ejemplo anterior).

Tened en cuenta que incluyo el for= en la URL apuntando al ID del paciente, y en la List tengo 'subject ' haciendo referencia al paciente.

(También observad que, para el signo de dólar ($), he usado una barra invertida () antes, es decir: \$)

Y ahora, puedo solicitar el recurso AllergyIntolerance de este paciente, y en lugar de obtener todos, puedo pedir solo los “actuales”, tal como se definen en la List anterior.

Esto se vería así:

 
GET /AllergyIntolerance?patient=...&_list=\$current-allergies cURL snippet

Y esto devolvería un subconjunto de las alergias de este paciente, según la lista de alergias actuales.

Tened en cuenta que estamos usando el mismo parámetro de búsqueda _list mencionado anteriormente, solo que esta vez, en lugar de una “Custom List”, se utiliza una “Functional List”.

Tened en cuenta que podéis controlar los nombres de las listas funcionales (y, para cada lista, su parámetro de búsquedasubjecty el tipo de recurso subject; por ejemplo, en el ejemplo anterior el parámetro de búsqueda subject era patient y el tipo de recurso subject era Patient), a través de la configuración del endpoint FHIR, específicamente en los "Interactions Strategy Settings". Consultad la documentación relacionada aquí. Esto se ve así:

  • Operación $find

Además, si simplemente queréis obtener la Lista Funcional en sí (para un subject en particular y de un tipo concreto), podéis usar la operación $find.

Consultad la documentación FHIR relacionada para una descripción completa. También consultad nuestra documentación relacionada.

Aquí tenéis un ejemplo, basado en el anterior:

 

 

 
/List/$find?patient=...&name=\$current-allergies cURL snippet

Esto devolverá la lista $current-allergies relacionada con este paciente, tal como se definió anteriormente mediante la función $update-functional.

Consultad la aplicación relacionada en Open Exchange, que incluye una colección de Postman con los ejemplos anteriores (y algunos más) e instrucciones para ejecutarlos contra el contenedor Docker de la plantilla del servidor FHIR de @Evgeny Shvarov (de hecho, el ejemplo anterior se creó a partir de este ejemplo, con un pequeño cambio… consultad los detalles en las instrucciones de uso de mi aplicación).

Una nota general: toda esta funcionalidad asume que estáis usando la estrategia de almacenamiento JsonAdvSQL, relativamente nueva y actualmente por defecto, para vuestro endpoint. (Si es relevante, consultad aquí sobre cómo migrar desde una estrategia heredada).
ディスカッション (0)1
続けるにはログインするか新規登録を行ってください
お知らせ
· 2026年1月13日

Global Masters: Points and a Badge for Turning Ideas into Reality

Hi Community!

Starting from January 2026, developers who turn product ideas from the Ideas Portal into real, working solutions with be awarded with 7,000 points on Global Masters and a badge.

✨ What you get:
🧙‍♂️ Idea to Reality Wizard badge —
awarded once to community members who implement a product idea suggested at the Ideas Portal
⭐ 7,000 Global Masters points — awarded for every implemented idea from the "Community Opportunity" list.

 

Details: 

As you might know, anyone can submit product ideas / suggestions on the InterSystems Ideas Portal (and earn points and badges for that — see this related post).
Anyone can jump in, take an idea, and help the whole community by making it real!
Now, when an idea is implemented by a community member, we want to thank you by recognizing your contribution and awarding you Global Masters points and a badge.

🤝 Working as a team?
If an idea is implemented together with other developers, the 7,000 points are split equally between all contributors.

The badge is awarded once, but points can be earned again and again as you implement more ideas.

Thanks to everyone who builds, contributes, and helps turn ideas into reality. We’re excited to see what you work on next 💡

If you are not a Global Masters Advocacy Hub member yet - join now to stay up-to-date, get nice prizes, and let us recognize your contribution to the Developer Community! 👍

1 Comment
ディスカッション (1)2
続けるにはログインするか新規登録を行ってください
記事
· 2026年1月13日 3m read

Exportando datos de configuración de Interoperabilidad a CSV

 

Al trabajar con InterSystems Interoperability (IRIS / Health Connect / Ensemble), los datos de configuración a menudo están distribuidos en muchos elementos de producción: servicios, procesos, operaciones, adaptadores y sus configuraciones.

Una necesidad operativa o de seguridad común es responder preguntas como:

  • ¿Qué interfaces hacen referencia a rutas del sistema de archivos?
  • ¿Dónde están configurados directorios, recursos de red o rutas absolutas?
  • ¿Puedo auditar o documentar rápidamente esta información en todas mis producciones?

La utilidad en ObjectScript que se muestra a continuación resuelve exactamente este problema exportando configuraciones seleccionadas a un archivo CSV.

Este script:

  1. Recorre todos los namespaces existentes
  2. Consulta todos los elementos de configuración de Interoperabilidad (Ens_Config.Item) en todos los namespaces
  3. Itera sobre la configuración de cada elemento
  4. Extrae rutas del sistema de archivos/URLs (valores que contienen :, /, o \)
  5. Escribe los resultados en un archivo CSV, agrupados por Categoría
  6. Genera un resultado fácil de auditar que se puede abrir en Excel o compartir con los equipos de operaciones/seguridad

    Casos de uso típicos

    Debéis usar esta utilidad cuando necesitéis:

    • 🔍 Auditar el uso del sistema de archivos en todas las producciones
    • 🛡 Revisar posibles exposiciones de seguridad (rutas locales, recursos de red, conexiones a bases de datos)
    • 📄 Documentar la configuración para migraciones, actualizaciones o planificación de recuperación ante desastres
    • 🔄 Comparar entornos (DEV vs TEST vs PROD)
    • 🧹 Limpiar rutas heredadas o no usadas

    Esto es especialmente útil en instancias grandes con varias producciones que utilizan muchas interfaces y adaptadores.

    Formato de salida

    El CSV generado contiene las siguientes columnas:

    Namespace, Categoría, Nombre del elemento, Nombre de la clase, Nombre de la propiedad, Valor

    Además:

    • Los elementos de configuración se agrupan por categoría.
    • Solo se exportan las rutas de configuración relevantes; podéis modificar fácilmente la lógica para exportar usando el nombre de la configuración (por ejemplo, "DSN" para conexiones SQL) o cualquier otro valor de configuración.
    • Es fácil de filtrar y analizar en Excel.
    • Ejecutad la utilidad desde el terminal proporcionando el parámetro con la ruta completa y el nombre del CSV.

    Por ejemplo:

    > do ##class(Test.Properties).GetData("c:\temp\loop.csv")

    Ejemplo del CSV abierto en Excel:

     

    Notas y consejos

    • 🧪 Probad primero en entornos que no sean PROD si no estáis seguros de los permisos.
    • 📂 Aseguraos de que el directorio de destino exista y sea escribible por IRIS/Health Connect.
    • 🔎 Podéis ampliar fácilmente la lógica para:
      • Exportar propiedades adicionales
      • Filtrar por categoría o clase
      • Enmascarar valores sensibles (contraseñas)
      • Cambiar la lógica para datos relevantes

    Si lo ampliáis o mejoráis, no dudéis en compartir vuestras mejoras con la comunidad.

    ディスカッション (0)1
    続けるにはログインするか新規登録を行ってください
    記事
    · 2026年1月13日 12m read

    Streaming de Données avec InterSystems IRIS Interoperability

    Les architectures de données modernes utilisent des solutions de capture, transformation, déplacement et chargement de données en temps réel pour construire des lacs de données, des entrepôts analytiques et des référentiels de big data. Cela permet l'analyse de données provenant de diverses sources sans impacter les opérations qui les utilisent. Pour y parvenir, il est essentiel d'établir un flux de données continu, évolutif, élastique et robuste. La méthode la plus répandue pour cela passe par la technique CDC (Change Data Capture). Le CDC surveille la production de petits ensembles de données, capture automatiquement ces données et les transmet à un ou plusieurs destinataires, y compris les référentiels de données analytiques. L'avantage majeur est l'élimination du délai J+1 dans l'analyse, car les données sont détectées à la source dès qu'elles sont produites, puis répliquées vers la destination.

    Cet article démontrera les deux sources de données les plus courantes pour les scénarios CDC, à la fois comme source et comme destination. Pour la source de données (origine), nous explorerons le CDC dans les bases de données SQL et les fichiers CSV. Pour la destination des données, nous utiliserons une base de données en colonnes (un scénario typique de base de données analytique haute performance) et un topic Kafka (une approche standard pour le streaming de données vers le cloud et/ou vers plusieurs consommateurs de données en temps réel).

     

    Aperçu

    Cet article fournit un exemple pour le scénario d'interopérabilité suivant:

     

    1 Comment
    ディスカッション (1)2
    続けるにはログインするか新規登録を行ってください