Fast Healthcare Interoperability Resources (FHIR, pronunciado como "fire") es proyecto estándar que describe formatos y elementos de datos (conocidos como "recursos") y una Interfaz de programación para aplicaciones (API) con el fin de intercambiar expedientes clínicos electrónicos
En este artículo vamos a presentar un ejemplo de un proyecto de implementación de una solución basada en FHIR. Este proyecto se basará en el proyecto nacional (nacional de España), conocido como ÚNICAS.
Es posible que hayáis notado que, para configurar un mirror en InterSystems IRIS for Health™ y HealthShare® Health Connect, hay un requisito especial. En este artículo, quiero guiaros paso a paso por el proceso.
Cuando creamos un repositorio FHIR en IRIS, tenemos un endpoint para acceder a la información, crear nuevos recursos, etc. Pero hay algunos recursos en FHIR que probablemente no tengamos en nuestro repositorio, por ejemplo, un recurso Binary (este recurso devuelve un documento, como un PDF, por ejemplo).
He creado un ejemplo en el que cuando se solicita un recurso Binary, el endpoint de FHIR devuelve una respuesta, como si existiera en el repositorio.
IRIS admite transformaciones CCDA y FHIR de forma nativa, pero acceder y visualizar estas funcionalidades requiere tiempo de configuración y conocimiento del producto. La aplicación IRIS Interop DevTools fue diseñada para cerrar esa brecha, permitiendo a los implementadores comenzar de inmediato y explorar las capacidades de transformación integradas del producto.
Además del entorno de transformación IRIS XML, XPath y CCDA, el paquete Interop DevTools ahora proporciona:
A menudo, durante el desarrollo de una aplicación frontend o cualquier otro tipo de comunicación vs API REST, vale la pena tener una Swagger UI - una interfaz de usuario de prueba para la API REST que sigue la especificación Open API 2.0. Por lo general es de gran ayuda, ya que permite, todo en uno, hacer pruebas manuales rápidas vs API REST, con sus respuestas y todos los datos.
Este será un artículo muy corto ya que en abril de 2025, con Lovable y otras herramientas de Prompt-to-UI, se vuelve posible crear el frontend mediante indicaciones. Incluso para vosotros, que como yo, no estáis familiarizados en absoluto con las técnicas modernas de UI.
Bueno, al menos conozco las palabras javascript, typescript y ReactJS, así que en este artículo muy corto construiremos la interfaz de usuario en ReactJS para un servidor InterSystems FHIR con Lovable.ai.
Después de los dos webinars que realizamos centrados en VS Code ["Introducción" y "Más allá de lo básico"; en hebreo], un compañero de la comunidad inglesa preparó para los participantes algunos enlaces relacionados con recursos relevantes que enviamos como seguimiento. Los compartimos aquí también.
Una extensión "extiende" o mejora un recurso FHIR o un elemento de datos de forma personalizada. La extensión puede añadirse a la raíz de un recurso, como “Patient.ethnicity” en el perfil US Core, y también pueden añadirse a elementos individuales como HumanName, Address o Identifier.
¿Sabíais que también podéis añadir una extensión a un tipo de dato primitivo?
Los elementos primitivos normalmente almacenan un solo elemento y son el componente más básico en FHIR. Por ejemplo: "Keren", false, 1234, 12/08/2024, etc.
Muchas veces, al trabajar con datos FHIR, por ejemplo con IRIS For Health, resulta útil crear una operación FHIR personalizada. El estándar FHIR incluye un conjunto de operaciones definidas (como $everything), pero una operación personalizada es práctica cuando necesitáis añadir funcionalidades adicionales que van más allá del conjunto de operaciones estándar de FHIR.
Después de que desplegáramos un nuevo contenedor basado en containers.intersystems.com/intersystems/irishealth:2023.1 esta semana, notasteis de repente que el Repositorio FHIR empezó a responder con un Error 500. Esto se debe a violaciones de PROTECT en el nuevo espacio de nombres y base de datos HSSYSLOCALTEMP, utilizado por esta versión de los componentes FHIR de IRIS for Health.
También en versiones anteriores podíais definir vuestro servidor FHIR para aceptar solicitudes mediante OAuth 2.0 (por ejemplo, para un cliente SMART on FHIR), pero hoy en día, con la versión v2024.3, que se lanzó hace ya un tiempo, existe una nueva funcionalidad que permite hacerlo de forma más sencilla: el OAuth FHIR Client QuickStart.
Enviáis una petición HTTP y recibís un error HTTP, pero con una página de error HTML que no esperabais… ¿qué está pasando? 🤔
Por ejemplo, puede que hayáis intentado LEER un recurso FHIR (por ejemplo, /Patient/123) y recibáis una página de error 404, aunque con otros IDs de Patient sí obtenéis la carga útil del recurso. Es decir, “la página” definitivamente existe… ¿por qué os está devolviendo una página de error 404? 🙄
Año.png)
Open Exchange app
.png)
.png)