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
FHIR (Fast Healthcare Interoperability Resources) es el estándar moderno para almacenar e intercambiar datos clínicos. Pero una vez que tus datos están en un servidor FHIR, ¿cómo puedes explorarlos realmente? Los datos FHIR se almacenan en formato JSON — potente, pero poco práctico de leer directamente. Quería una herramienta en la que pudieras hacer click en un paciente, ver sus condiciones, medicamentos, resultados de laboratorio y más, en un formato limpio y fácil de leer. Así que desarrollé el visor de pacientes FHIR.
Los equipos de Servicios Médicos de Emergencia (EMS) a menudo llegan al departamento de urgencias con pacientes cuyos datos demográficos están incompletos o son desconocidos: sin número de historia clínica (MRN), sin nombre confirmado y, en ocasiones, sin fecha de nacimiento. Sin embargo, las notas de traslado de EMS aún deben registrarse en la historia clínica correcta.
En el panorama sanitario moderno, encontrar pacientes clínicamente similares a menudo es como buscar una aguja en un pajar. Las búsquedas tradicionales por palabras clave suelen fallar porque el lenguaje médico es muy matizado; una búsqueda de "Heart Failure" podría no encontrar un registro que contenga "Congestive Cardiac Failure".
Me complace compartir iris-medmatch, un motor de emparejamiento de pacientes impulsado por IA y desarrollado sobre InterSystems IRIS for Health
Este programa práctico está diseñado para desarrolladores que queráis crear aplicaciones FHIR del mundo real utilizando Python e InterSystems IRIS for Health.
10:47 AM — Los resultados de creatinina de José García llegan al servidor FHIR del hospital.
2.1 mg/dL — un aumento del 35% frente al mes pasado.
¿Qué pasa después?
En un sistema típico: ❌ El resultado queda en una cola hasta que un clínico lo revise manualmente, horas o días después.
Este sistema de ejemplo: 👍 Un agente de IA evalúa la tendencia, consulta guías clínicas y genera recomendaciones basadas en evidencia, en segundos y de forma automática.
Sin chatbot. Sin prompts manuales. Sin razonamiento de caja negra.
Esto es soporte a la decisión clínica impulsado por eventos con trazabilidad completa:
✅ Activado automáticamente por eventos FHIR
✅ Razonamiento multiagente (contexto, guías, recomendaciones)
✅ Trazabilidad completa en SQL (cada decisión, cada fuente de evidencia)
✅ Salidas nativas FHIR (DiagnosticReport publicado en el servidor)
Construido con:
InterSystems IRIS for Health — Orquestación, FHIR, persistencia, búsqueda vectorial
CrewAI — Framework multiagente para razonamiento estructurado
Aprenderás: 🖋️ Cómo orquestar flujos de IA agéntica dentro de sistemas de interoperabilidad listos para producción, y por qué la explicabilidad importa más que la precisión por sí sola.
InterSystems API Manager (IAM) es un componente clave de la plataforma de datos InterSystems IRIS y ofrece una gestión centralizada de APIs con un fuerte enfoque en la seguridad. IAM simplifica todo el ciclo de vida de las APIs, desde su creación hasta su retirada, y proporciona un portal de desarrolladores para facilitar el descubrimiento y la integración de APIs. Las funciones de control de acceso permiten a los administradores definir permisos precisos, y IAM se integra de forma fluida con la plataforma de datos IRIS, mejorando las capacidades de gestión e integración de datos.
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? 🙄
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.
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. Por supuesto, todos estáis invitados a añadir más recursos útiles.
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.
¿Qué es ÚNICAS?
Usando sus propias palabras:
Un proyecto cuyo objetivo es crear un ecosistema de alianzas para mejorar la atención sanitaria de pacientes pediátricos con enfermedades minoritarias (EEMM) complejas.
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. La documentación lo explica paso a paso (aunque este comentario puede resultar útil para quienes estáis empezando).
¿Sabíais que el 80% de los datos de salud están atrapados en formatos no estructurados como el fax? Si dais un paseo por el Mass General en Boston, literalmente veréis una máquina de resonancia magnética de última generación junto a una máquina de fax. La sanidad sigue construyendo tecnología increíble, pero no logra desprenderse de la tecnología heredada. A esto lo llamamos la “paradoja de la modernización heredada”. Este breve corto sigue a una gestora de cuidados en Blue Plan que pasa sus días revisando historiales, leyendo faxes línea por línea y esforzándose por brindar a sus miembros la atención que necesitan. Todo cambia cuando Blue Plan prueba InterSystems Health Evolve, una solución que transforma sus faxes en datos FHIR legibles por máquina, listos para IA y análisis. Para acceder a nuestro prototipo completamente funcional de Texto a FHIR, visitad HealthEvolve.de.
Curso avanzado donde aprenderás a construir soluciones e integraciones con el protocolo HL7-FHIR en InterSystems IRIS for Health™ y HealthShare® Health Connect.
Ahondarás en los fundamentos del estándar FHIR, su arquitectura de instalación, configuración y las diversas opciones de personalización y extensión de servidores FHIR, para almacenar datos en un repositorio FHIR o presentar una fachada FHIR como interfaz para las aplicaciones ya existentes.
He creado un nuevo stack de Docker con WebGateway e IRIS for Health 2025.1. He mapeado los puertos de WebGateway de la siguiente manera:
8743:443
8780:80
Puedo acceder al portal IRIS a través del 8743 sin problemas.
También he creado un repositorio FHIR y puedo acceder a él a través del puerto 8743.
Tengo una aplicación web, en otro servidor con otro dominio, que se conecta a este repositorio de FHIR. He configurado en el endpoint de FHIR el origen permitido para el dominio de esta aplicación.
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.
En este artículo, os voy a presentar mi aplicación iris-fhir-bridge.
IRIS-FHIR Bridge es una potente solución de interoperabilidad diseñada para facilitar un intercambio de datos fluido y confiable entre sistemas de salud. Actúa como un puente entre formatos de datos heredados y los estándares modernos FHIR, lo que permite a las organizaciones de atención médica intercambiar información de manera más eficiente.
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.
La solución consiste en añadir "%DB_HSSYSLOCALTEMP" a las Aplicaciones Web que gestionan las solicitudes FHIR.
Os presento FHIRCraft, una herramienta ligera para generar recursos FHIR sintéticos.
Quizás estéis pensando: “Pero... ¿no existe ya Synthea, que genera un montón de recursos FHIR?” Exactamente — y por eso mismo creé esta aplicación.
FHIRCraft está diseñada para generar recursos FHIR más simples, pequeños y enfocados. A diferencia de Synthea, no pretende simular historiales clínicos completos ni flujos asistenciales. Está pensada para quienes están empezando con FHIR
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.
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.
Finalizamos esta serie de artículos de SMART On FHIR con Auth0 e InterSystems IRIS FHIR Repository revisando nuestra aplicación desarrollada en Angular 16.
Recordemos como es la arquitectura definida para nuestra solución:
Nuestra aplicación de front-end corresponde con la segunda columna y como véis será la encargada de dos cosas:
Redireccionar la petición de login a Auth0 y recibir la respuesta.
Enviar y recibir la respuesta de las solicitudes vía REST enviadas al servidor FHIR.
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.
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.
.png)
.png)
.png)
.png)
.jpg)
.png)
.png)
.png)