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
Seguramente todos habéis oido hablar de FHIR como la panacea y solución a todos los problemas de interoperabilidad y compatibilidad entre sistemas. Aquí mismo podemos ver a uno de sus clásicos defensores sujetando un recurso FHIR con su mano y disfrutando desaforadamente:
Pero para el resto de los mortales vamos a hacer una pequeña introducción.
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
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.
Esta publicación es una introducción a mi aplicación iris-fhir-client en Open Exchange.
Usando Python embebido y con la ayuda de la librería fhirpy, iris-fhir-client puede conectarse a cualquier servidor FHIR abierto. Obten información de recursos por terminal y mediante el uso de la aplicación web CSP.
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.
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:
Hola a todos! Os comparto hoy un artículo sobre la utilización del procesamiento de lenguaje natural y su combinación con FHIR donde se muestra un chatbot que interactúa con FHIR desarrollado por Renato Banzai.
¿Qué significa PLN?
PLN significa Procesamiento del Lenguaje Natural (NLP en inglés) y es un campo de la Inteligencia Artificial muy complejo que utiliza técnicas para, en pocas palabras, “entender de qué se está hablando”.
Solo quería compartir aquí una publicación rápida sobre mi proyecto para el Gran Premio :D
FHIR Patient Viewer es una herramienta de renderizado de una sola página, basada en Vue.js, que muestra de forma sencilla los datos devueltos de una llamada /Patient/{id}/$everything realizada a un servidor FHIR de InterSystems.
En el archivo Readme he incluido 3 cosas principales:
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.
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.
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.
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.
En este artículo mostraré cómo configurar un repositorio FHIR + configuración del servidor de autorización/de recursos OAuth2 en IRIS for Health, como continuación del artículo anterior.
En la Parte 1, presentamos los preparativos preliminares, configuramos el servidor de autorización OAuth2 y obtuvimos el token de acceso.
En la Parte 2, mostraremos cómo crear un repositorio FHIR y cómo configurar un servidor de recursos/cliente OAuth2.
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.
En artículos anteriores hemos visto como configurar y personalizar nuestro EMPI, hemos visto como podemos como podemos incluir nuevos pacientes en nuestro sistema mediante mensajería HL7, pero claro, ¡no todo es HL7 v.2 en esta vida! ¿Cómo podríamos configurar nuestra instancia del EMPI para trabajar con mensajería FHIR?
Quiero compartir mi experiencia creando el portal iris-fhir con FHIR.
Decidí dar un paso adelante y participar en el concurso IRIS for Health FHIR, pero nunca antes había trabajado con FHIR.
Después del webinar para el lanzamiento del concurso sobre FHIR , en el que nos explicaron de forma general cómo funciona IRIS for Health con FHIR, comencé a buscar en la documentación de FHIR para crear mi proyecto de Registro de pacientes.
En la página web de HL7 FHIR (versión 4), encontré un "mapa de recursos":
En nuestro artículo anterior vimos como configurar nuestro EMPI para recibir mensajería FHIR. Para ello instalábamos el Adaptador FHIR que InterSystems pone a nuestra disposición que configuraba un endpoint REST al que podíamos enviar nuestro mensaje FHIR. A continuación obteníamos el mensaje y lo transformábamos a un %String que enviábamos vía TCP a la producción de nuestro EMPI configurada en nuestro namespace HSPIDATA.
Hablando con mi amigo @Renato Banzai, especialista en Machine Learning, me expuso uno de los mayores retos a los que se enfrentan actualmente las empresas: la implementación del Machine Learning (ML) y la Inteligencia Artificial (IA) en entornos reales.
Intersystems IRIS ofrece IntegratedML. IntegratedML es una excelente herramienta para practicar, probar y realizar implementaciones de modelos de ML e IA.
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.
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:
La interoperabilidad en la asistencia sanitaria es esencial para mejorar la atención a los pacientes, reducir los costes de los proveedores de atención médica y ofrecer una imagen más precisa a los proveedores. Pero con tantos sistemas diferentes, los datos se presentan en diferentes formatos. Se han creado muchos estándares para tratar de resolver este problema, incluyendo HL7v2, HL7v3 y CDA, pero cada una tiene sus limitaciones.
Por comentarios.png)
Open Exchange app
.png)
.png)
.png)
.png)