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.
FHIR ha revolucionado la industria de la atención médica al proporcionar un modelo de datos estandarizado para crear aplicaciones y promocionar el intercambio de datos entre diferentes sistemas. El estándar FHIR se basa en enfoques modernos impulsados por APIs, lo que lo hace más accesible para los desarrolladores web y móviles. Sin embargo, interactuar con las API de FHIR aún puede ser un desafío, especialmente cuando se trata de consultar datos usando lenguaje natural.
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.
En el artículo anterior vimos cómo podíamos recuperar un recurso almacenado en la base de datos de nuestro HIS particular así que hoy veremos cómo podemos añadir nuevos registros en nuestro HIS cuyo origen es un recurso FHIR que recibamos en nuestro sistema.
Recientemente participé en un hands-on fantásticamente organizado por @Patrick Jamieson en el que se configuraba una aplicación de Angular junto con un servidor FHIR de IRIS siguiendo los protocolos definidos por SMART On FHIR y me resultó fráncamente interesante, por lo que me puse por mi cuenta a desarrollar mi propia aplicación de Angular y así aprovechar lo aprendido para publicarlo en la comunidad.
El objetivo de la aplicación es mostrar cómo de fácil es crear un repositorio FHIR de pacientes y sus datos clínicos utilizando la solucion IRIS for Health.
En conjunto, con esta solucion también estamos empoderando al paciente con sus datos clínicos y ellos los podrán usar como quieran.
Basado en una gran muestra y el taller construido por @Luis Angel Pérez Ramos (ver artículos relacionados y relacionados con Open Exchange app), que incluía un contenedor local de InterSystems IRIS for Health (y la configuración deseada), esta muestra presentada aquí, adaptó el taller para usar el Servidor FHIR en la Nube de InterSystems, y su configuración relacionada.
Se acaba de actualizar la plantilla para desarrollo FHIR de forma que ahora publica el paquete IPM fhir-server que hace que la configuración del servidor FHIR de InterSystems sea una sencilla tarea manual, automática o programática vía un solo comando.
Con frecuencia, cuando colaboramos con el repositorio de alguien en GitHub, seguimos el siguiente ciclo:
1. Fork: crear nuestra bifurcación del repositorio
2. Clone: clonar una copia local de nuestro repositorio bifurcado
3. Realizar nuestros cambios y guardarlos con un Commit en nuestra copia local
4. Push: publicar nuestros cambios al repositorio clonado de GitHub
5. Hacer Pull-Request para solicitar incorporar nuestros cambios desde nuestro fork — bifurcación — al repositorio original
6. Y si todo va bien se hará un Merge — fusión o incorporación — con nuestros cambios en el repositorio original
¡Todo esto es genial y funciona bien!
Y si queremos realizar una segunda colaboración justo después de llevar a cabo un Merge , es necesario que primero realicemos un Fetch upstream en nuestro repositorio clonado para que tengamos disponibles los cambios actualizados que incorporamos al repositorio original a través del Pull Request.
Los más frikies de git lo hacen muy fácilmente, pero muchos terminamos simplemente por eliminar nuestro primer fork y crear otro nuevo.
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.
No se encuentra el método InstallFoundation (IRIS 2023.2+)
Recientemente se lanzó IRIS 2023.2. Esta versión eliminó este método InstallFoundation de esta clase HS.HC.Util.Installer. Este era un método privado y no estaba documentado. Pero la comunidad lo utilizó ampliamente para instalar el servidor FHIR.
Entonces, si encuentramos este error:
<METHOD DOES NOT EXIST> *InstallFoundation,HS.HC.Util.Installer
En una demostración de nuestro propio servidor FHIR, podremos solucionarlo reemplazando esta línea:
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.
Volvemos al ataque con nuestro ejemplo de uso de FHIR Adapter, en este artículo vamos a revisar como podemos configurarlo en nuestras instancias de IRIS y cual es el resultado de la instalación.
Los pasos realizados para la configuración del proyecto son los mismos que indica la documentación oficial, podéis revisarlos directamente aquí. Pues bien, ¡manos a la obra!
Retomamos nuestra serie de artículos sobre la herramienta de FHIR Adapter disponible para los usuarios de HealthShare HealthConnect e InterSystems IRIS.
En mis artículos anteriores, una de las cosas más interesantes de FHIR que mencioné es el amplio rango de posibilidades que tenemos y no solo para crear algo, sino las maneras de conseguir este objetivo.
En mis artículos estoy compartiendo mi experiencia trabajando con FHIR. Solo usaba los Recursos FHIR aportados por la API. Recuperando y actualizando los Recursos FHIR en el servidor FHIR usando javascript con la ayuda de fhir.js
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.
En el pasado artículo presentamos la arquitectura de nuestro proyecto de SMART On FHIR, así que es hora de meternos en harina y empezar a configurar todos los elementos que vamos a necesitar.
Primeramente comenzaremos con Auth0.
Configuración de AUTH0
Comenzaremos creando una cuenta de Auth0 con un correo válido, una vez dados de alta deberemos crear nuestra primera aplicación, y lo haremos desde el menú de la izquieda:
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:
Demo lista para usar de un servidor FHIR con IRIS for Health 2020.2:
* Transformación HL7v2 al servidor FHIR
* Servidor FHIR que se puede consultar en SQL
Google tiene una interesante herramienta llamada Google Data Studio. Esta aplicación permite crear cuadros de mando (dashboards) interactivos, con tus datos, disponibles en internet. Además, ofrece cientos de conectores con cualquier fuente de datos, desarrollados por la comunidad. Y también visualizadores desarrollados por la comunidad. Lo más importante es que Google ofrece una forma de desarrollar tu propio conector con tus datos.
FHIRaaS ofrece una REST API, y está disponible desde internet. Así que he decidido probar a crear un informe básico con los datos almacenados allí. Y al final, conseguí esto.
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.
Quizá os hayáis encontrado con escenarios donde no tenéis que implementar un repositorio FHIR, sino por ejemplo reenviar peticiones FHIR, gestionar las respuestas y tal vez realizar modificaciones o extraer algunos valores por el camino. Aquí encontraréis algunos ejemplos que pueden implementarse con InterSystems IRIS For Health o HealthShare Health Connect.
En este artículo, nos centraremos en OAuth2, un protocolo que se utiliza cada vez con más frecuencia en combinación con FHIR para realizar la autorización.
En esta primera parte, comenzaremos con el contenedor Docker para IRIS for Health y Apache, configuraremos la función del servidor de autorización OAuth2 en IRIS for Health, accederemos a él desde la herramienta de desarrollo Postman para REST y obtendremos un token de acceso. Además, en la Parte 2 y en las siguientes, añadiremos las funciones del repositorio FHIR a IRIS for Health, también agregaremos la configuración del servidor de recursos OAuth2, y explicaremos cómo ejecutar las solicitudes de FHIR utilizando los tokens de acceso desde Postman.
El servidor FHIR usará la última versión de InterSystems IRIS for Health Community Edition y desplegará el servidor FHIR desde esta app a través del paquete IPM en el namespace FHIRSERVER.
Por votos.png)
Open Exchange app.png)
.png)
.png)
.png)
.png)
