FHIR (Recursos Rápidos de Interoperabilidad en Salud)

FHIR (Recursos Rápidos de Interoperabilidad en Salud) es un estándar de HL7 International para el intercambio de información sanitaria utilizando unidades de datos modulares denominadas recursos e interfaces de programación de aplicaciones (API) de estilo web. Combina el modelado de información estructurada de estándares HL7 anteriores con tecnologías web ampliamente utilizadas —API RESTful, serialización JSON y XML, y HTTP estándar— para facilitar el acceso a los datos de salud y la creación de aplicaciones.

Definition

FHIR es un estándar que representa datos clínicos y administrativos como recursos discretos y autocontenidos —cada uno con una estructura definida y una identidad estable— y los intercambia a través de una interfaz de programación de aplicaciones (API) RESTful sobre protocolos web estándar, de modo que los sistemas y las aplicaciones pueden leer, escribir y buscar datos de salud de manera interoperable.

Scope

Esta entrada abarca el modelo de recursos de FHIR, su paradigma de intercambio RESTful, la elaboración de perfiles para necesidades locales y su relación con estándares HL7 anteriores y con aplicaciones sustituibles como SMART on FHIR. Se considera a FHIR como un estándar de intercambio de datos y un tema metodológico; no proporciona orientación sobre implementación, configuración de seguridad o adquisición.

Core questions

• ¿Qué es un recurso FHIR y cómo se combinan los recursos para representar un registro de paciente?
• ¿En qué se diferencia el enfoque de la API RESTful de la mensajería HL7 v2?
• ¿Qué son los perfiles y las extensiones, y por qué son necesarios?
• ¿Cómo permite FHIR aplicaciones sustituibles como SMART on FHIR?

Key concepts

• Recursos (Paciente, Observación, Encuentro, Solicitud de Medicación, etc.)
• API RESTful (crear, leer, actualizar, eliminar, buscar)
• Serialización JSON y XML
• Referencias y paquetes (bundles)
• Perfiles y extensiones
• Guías de implementación
• Aplicaciones sustituibles SMART on FHIR

Mechanisms

FHIR modela la información sanitaria como recursos —unidades modulares como Paciente (Patient), Observación (Observation) o Solicitud de Medicación (MedicationRequest)— cada uno con un conjunto definido de elementos y una identidad estable y direccionable. Los recursos se referencian entre sí, y los grupos de recursos pueden agruparse en paquetes (bundles). Los sistemas los intercambian a través de una interfaz RESTful en la que las operaciones HTTP estándar crean, leen, actualizan, eliminan y buscan recursos, con datos serializados como JSON o XML. Dado que las implementaciones individuales requieren restricciones locales, FHIR admite la elaboración de perfiles (profiling): los perfiles y las extensiones adaptan los recursos base a una jurisdicción o caso de uso, y las guías de implementación (implementation guides) los empaquetan para una comunidad. Este diseño de recursos y API también sustenta las aplicaciones sustituibles, donde una aplicación autorizada contra un punto final (endpoint) de FHIR (el patrón SMART on FHIR) puede ejecutarse en sistemas conformes.

Clinical relevance

FHIR es cada vez más la base para aplicaciones orientadas al paciente, el acceso a datos clínicos y el intercambio entre organizaciones, y figura en la política nacional de interoperabilidad. Esta entrada describe cómo FHIR estructura y expone los datos; es material de referencia sobre el estándar y no constituye una guía para construir, asegurar o implementar ningún sistema clínico.

Evidence & guidelines

FHIR es un estándar normativo de HL7 International, desarrollado y votado a través de HL7, con guías de implementación nacionales y regionales que lo restringen para uso local. Bender y Sartipi (2013) es una descripción técnica temprana del diseño RESTful del estándar; el libro de texto de Benson y Grieve ofrece una descripción consolidada de FHIR junto con HL7 y SNOMED CT, y Mandl y Kohane (2012) proporcionan la justificación política para la arquitectura abierta basada en aplicaciones que FHIR soporta.

History

FHIR fue iniciado por HL7 alrededor de 2011-2012, liderado por Grahame Grieve, como una alternativa deliberadamente más ligera a HL7 versión 3 que reutilizaba tecnologías web convencionales. Descripciones tempranas como la de Bender y Sartipi (2013) lo enmarcaron como un enfoque ágil y RESTful, y el estándar avanzó a través de sucesivas versiones hacia el estatus normativo durante la década de 2010, convergiendo con argumentos políticos a favor de una TI de salud abierta y sustituible.

Debates

¿Qué tan bien logra FHIR una verdadera interoperabilidad semántica?

FHIR estandariza bien la estructura y el intercambio, pero el significado consistente todavía depende del uso disciplinado de perfiles y vinculaciones de terminología; la variación en la elaboración de perfiles entre implementaciones puede limitar la interoperabilidad semántica predeterminada (out-of-the-box).

Key figures

• Grahame Grieve
• Duane Bender
• Kamran Sartipi
• Kenneth Mandl
• Isaac Kohane

Seminal works

• bender-sartipi-2013
• benson-grieve-2021

Frequently asked questions

¿En qué se diferencia FHIR de la mensajería HL7 v2?

HL7 v2 envía mensajes basados en eventos con segmentos delimitados, mientras que FHIR expone recursos discretos a través de una API web RESTful que los sistemas pueden leer, escribir y buscar directamente, utilizando formatos convencionales como JSON sobre HTTP.

¿Qué significa SMART on FHIR?

SMART on FHIR es un patrón en el que una aplicación se autoriza contra un punto final (endpoint) de FHIR utilizando estándares abiertos, de modo que la misma aplicación puede ejecutarse en diferentes sistemas que exponen API FHIR conformes; es una de las motivaciones para el diseño de recursos y API de FHIR.