🔥 La guía FHIR para CTO y líderes técnicos

Escrito por Niquola Ryzhikov, CTO de Health Samurai.

Me gustaría compartir una introducción a FHIR (Fast Healthcare Interoperability Resources) dirigida a CTO y responsables tecnológicos interesados en las tecnologías sanitarias modernas que perdurarán a largo plazo.

Descripción general de FHIR:

FHIR es un estándar de interoperabilidad creado por la organización internacional HL7 para el intercambio de información médica y otra información sanitaria relacionada entre sistemas. Se está convirtiendo rápidamente en el estándar de facto para el intercambio de datos sanitarios.
FHIR cuenta con un sólido respaldo público y privado por parte de líderes en sistemas de historia clínica electrónica como Epic y Cerner, Apple y Google, así como de gobiernos (EE. UU., Australia, etc.).
FHIR es una comunidad abierta de expertos en tecnologías de la información sanitaria. Una forma sencilla de unirse a las conversaciones ahora mismo es: https://chat.fhir.org/. También puede asistir a los connectathons de FHIR y conectar de forma presencial con la comunidad FHIR.
FHIR es de código abierto y cuenta con un ecosistema comercial de servidores, bibliotecas de referencia

y otras herramientas para el desarrollo ágil.

La adopción de FHIR en el sector ha sido sin precedentes, y todo apunta a que FHIR se convertirá en el estándar de referencia de las tecnologías de la información sanitaria durante los próximos 5-10 años.

¿Qué es FHIR desde una perspectiva técnica?

FHIR es una especificación legible por máquina de un servidor REST. FHIR es como el Swagger/OpenAPI para las tecnologías de la información sanitaria. Mientras que Swagger proporciona herramientas genéricas para especificar cualquier API REST, FHIR va un par de pasos más allá y ofrece modelos informacionales listos para usar y semántica operacional, junto con mecanismos para extender los modelos de datos a su caso de uso específico.

Modelo informacional: datos FHIR

FHIR introduce la noción de Resource como unidad principal de información para transferir y almacenar datos. Cada recurso tiene una etiqueta resourceType (equivalente a una clase en POO), que define su estructura y significado. FHIR incluye más de un centenar de definiciones de recursos diseñadas por grupos de trabajo especializados. La estructura (esquema) de los recursos se describe mediante StructureDefinition, que es legible por máquina y puede utilizarse para la generación de código o sistemas basados en metadatos. Los recursos fueron diseñados para cubrir las necesidades de datos más habituales, siguiendo la regla del 80/20.

Si lleva tiempo trabajando en tecnologías de la información sanitaria, probablemente comprenda el coste de un buen modelo de dominio y lo fácil que es equivocarse en su diseño. Los formatos de datos personalizados sin estandarización también crean silos entre sistemas y restringen el flujo de información. La complejidad esencial de nuestro sector reside en el modelado de datos, y FHIR nos proporciona modelos de datos estandarizados y de calidad con los que trabajar.

Terminology

Otra parte esencial de la semántica en las tecnologías de la información sanitaria son los valores y atributos codificados. Utilizamos terminologías especializadas para medicamentos, diagnósticos, pruebas de laboratorio, etc. FHIR incluye un enfoque unificado para todos los valores codificados en los recursos, así como la especificación de un servicio de terminología para las operaciones terminológicas habituales.

Modelo operacional: API

FHIR define un conjunto de endpoints REST estándar (operaciones), que se manifiestan para el descubrimiento dinámico en el CapabilityStatement y tienen un significado predefinido. Por ejemplo, endpoints para CRUD (crear, leer, actualizar y eliminar), historial, lotes/transacciones y búsqueda. También es posible ampliar la API FHIR con operaciones personalizadas.

¿Cómo puedo utilizar FHIR?

1. Como fuente de inspiración

Una gran cantidad de conocimiento y experiencia ha sido aportada a FHIR por expertos apasionados. Puede utilizar FHIR como inspiración o guía al diseñar su sistema. Puede acudir a la comunidad FHIR para plantear preguntas complejas y contrastar sus hipótesis con personas que están construyendo con éxito sistemas modernos de tecnologías de la información sanitaria.

2. Como OpenAPI para sistemas externos

Si su sistema necesita obtener datos de pacientes para funcionar, puede esperar ver en unos pocos años APIs FHIR de la mayoría de los proveedores de sistemas de historia clínica electrónica y otras fuentes de datos. FHIR está ganando impulso rápidamente y ha demostrado ser una tecnología que llegó para quedarse. Su adopción significa que, con el tiempo, será más fácil obtener los datos que necesita.

3. Como API externa para su sistema existente

Puede proporcionar una API FHIR a su sistema existente para hacerlo extensible y fácil de integrar. Si su sistema es similar a un sistema de historia clínica electrónica, también puede integrar el ecosistema SMART on FHIR y un marketplace de aplicaciones, convirtiendo su sistema en una plataforma dinámica con una amplia variedad de aplicaciones entre las que elegir.

Desde el punto de vista técnico, existen varias formas de implementar una API FHIR sobre sistemas existentes:

Fachada: escribir un middleware para convertir al vuelo sus datos internos y métodos en recursos y operaciones FHIR. La ventaja es que su capa FHIR estará íntimamente ligada a su sistema actual y podrá reutilizar su código y tecnología. La desventaja es que deberá implementar la parte esencial de la especificación FHIR desde cero para su sistema.
Adaptador: puede replicar los datos de su sistema en un servidor FHIR existente. Generalmente, esto puede ser más sencillo que la fachada, ya que desacopla la implementación FHIR de la traducción de su modelo de datos a FHIR. Existen requisitos: su sistema debe ser capaz de proporcionar un flujo de cambios para transformar y replicar. El adaptador puede funcionar en una o en ambas direcciones: desde su sistema a FHIR y/o a la inversa. Sin embargo, las integraciones bidireccionales son complejas, como ocurre con cualquier sistema multi-maestro.

4. Construir un sistema FHIR nativo

Si está creando un sistema desde cero y desea hacerlo compatible con FHIR, puede optar por implementar un sistema FHIR nativo utilizando FHIR como núcleo de su sistema. Puede aprovechar el modelo informacional de FHIR y los servidores y herramientas existentes en el mercado. Este enfoque le proporciona una arquitectura limpia y extensible, y le evita el doble modelado y las traducciones.

Los modelos estables y bien documentados también le ayudarán a mantener su sistema preparado para el futuro y más

resistente a los cambios. FHIR le ofrece un modelo informacional maduro y limpio, que puede utilizarse como una buena base para implementaciones e interfaces.

Sin embargo, nada es gratis y definitivamente tendrá que pagar cierto precio por FHIR:

Para casos de uso sencillos, los modelos genéricos de FHIR pueden requerir una sobrecarga mental y técnica que no resulta rentable. Por tanto, si su sistema no necesita una gran profundidad de dominio, puede usar FHIR únicamente como inspiración.
Deberá invertir en formación e implementación de FHIR. Puede reducir este coste contratando ingenieros que conozcan FHIR y utilizando productos de código abierto y comerciales. Creemos que el ecosistema FHIR seguirá creciendo y reducirá el coste global de implementación.
Para casos de uso muy especializados, la especificación FHIR puede no ser suficiente. El comité de FHIR utilizó la regla del 80/20 para priorizar el modelado de los casos de uso más comunes. Por tanto, es probable que su caso de uso especializado esté en cola. La buena noticia: puede unirse a la comunidad abierta de FHIR y facilitar o iniciar conversaciones interesantes para su subdominio. La mala noticia: tendrá que esperar a que este proceso concluya. Si bien puede extender los recursos existentes, FHIR está cerrado en cuanto a nuevos recursos (es decir, no se permite definir un tipo de recurso propio). Esta limitación se estableció con la intención de canalizar todos los nuevos recursos a través de la comunidad y garantizar un determinado nivel de calidad. Pero si está construyendo un sistema real, no tiene tiempo para esperar. Por eso en nuestro backend FHIR Aidbox le permitimos crear recursos personalizados no FHIR.

5. CDS (Clinical Decision Support) Hooks

Otra tendencia interesante en FHIR son los CDS hooks, una especificación de API que invoca soporte a la decisión clínica desde el flujo de trabajo del sistema de historia clínica electrónica del proveedor mediante llamadas activadas que devuelven información y sugerencias relevantes, y pueden lanzar una aplicación SMART dentro del sistema de historia clínica electrónica. Esta es una forma no disruptiva de ayudar al clínico a ofrecer una atención basada en datos en tiempo real, mediante la invocación automática de aplicaciones e información relevantes en cada interacción con el paciente.

6. Analítica de datos con FHIR

El modelo estandarizado y bien documentado, así como el soporte de formatos similares a JSON por parte de las bases de datos modernas (PostgreSQL, BigQuery, Spark), hacen de FHIR una opción interesante como base para construir sistemas analíticos, de BI e IA. Los servidores FHIR pueden utilizarse para agregar datos de diferentes fuentes y como repositorio de datos clínicos.

Observamos un creciente interés en el sector por el uso de FHIR para analítica:

Resumen

Si usted es la persona responsable de las decisiones técnicas, FHIR merece su atención. Puede convertirse en una parte esencial de su arquitectura y proporcionarle una base sólida y preparada para el futuro, junto con herramientas y comunidad.

Si tiene ideas o preguntas, únase a nuestra comunidad FHIR y contácteme (nicola en el chat de FHIR o en niquola@health-samurai.io).

Comience con el servidor FHIR de Aidbox para almacenamiento de datos, integraciones, analítica sanitaria y mucho más, o contrate a nuestro equipo para dar soporte a sus necesidades de desarrollo de software.

Véase también: Uso de FHIR para simplificar el desarrollo en el ámbito sanitario y Construcción de microservicios sanitarios.