HL7 FHIR: el estándar del futuro para los datos de atención médica

La atención médica ha sufrido durante mucho tiempo un problema de fragmentación. El HL7 FHIR puede ser la solución más creíble que haya producido la industria.

Un problema que se está gestando desde hace décadas

Pregúntele a cualquier médico que haya trabajado en más de una organización de atención médica y le describirá una versión de la misma frustración. Un paciente llega al servicio de urgencias. Su médico de atención primaria usa un sistema de registro médico electrónico. El especialista que consultaron el mes pasado usa otro. El laboratorio que procesó sus análisis de sangre recientes opera en una tercera plataforma. El centro de imágenes tiene su propio archivo. Ninguno de estos sistemas se comunica con fluidez, si es que se comunican entre sí.

El resultado es que los médicos toman decisiones con información incompleta, los pacientes repiten las pruebas que ya se han realizado, las transiciones de atención generan brechas peligrosas y el costo acumulado (en errores evitables, trabajo duplicado y oportunidades perdidas de atención coordinada) asciende a cientos de miles de millones de dólares al año en todo el sistema de salud mundial.

No se trata de un problema nuevo. La industria de la salud lleva décadas intentando resolver la interoperabilidad de los datos. La novedad es que la solución, el HL7 FHIR, ha alcanzado un nivel de madurez técnica, respaldo regulatorio y adopción por parte de la industria que hace que la interoperabilidad genuina no solo sea teóricamente posible, sino que sea prácticamente alcanzable en la década actual.

Qué es realmente el HL7 FHIR

HL7 son las siglas de Health Level Seven International, una organización de desarrollo de estándares sin fines de lucro que produce estándares de datos de atención médica desde 1987. FHIR son las siglas de Fast Healthcare Interoperability Resources. Es el estándar más reciente y más eficaz que ha elaborado la organización, y representa un cambio fundamental con respecto al enfoque adoptado por sus predecesores.

En esencia, el FHIR es un estándar para el intercambio electrónico de información médica. Define un conjunto de componentes modulares denominados recursos: unidades discretas y bien definidas de información sanitaria, como un paciente, una observación, un medicamento, una afección, un informe de diagnóstico o una cita. Actualmente, hay más de 150 recursos de este tipo definidos en la especificación del FHIR, cada uno con una estructura de datos estandarizada, un conjunto definido de valores permitidos y reglas claras sobre su relación con otros recursos.

Lo que distingue al FHIR de las normas anteriores es la forma en que aborda el problema del intercambio. En lugar de definir formatos de mensajes complejos que deben traducirse entre sistemas, el FHIR utiliza una arquitectura de API RESTful basada en los mismos fundamentos técnicos que la web moderna. Los sistemas que implementan el FHIR exponen los puntos finales que otros sistemas pueden consultar mediante protocolos web estándar y reciben datos en formatos JSON o XML de lectura universal.

En términos prácticos, esto significa que un desarrollador que crea una aplicación orientada al paciente, una herramienta de apoyo a la toma de decisiones clínicas o una plataforma de análisis de la salud de la población puede recuperar datos de salud estructurados de un servidor compatible con el FHIR mediante el mismo tipo de llamada a la API que utilizaría para recuperar datos de cualquier servicio web moderno. La barrera técnica para la integración de los datos sanitarios se reduce drásticamente.

La arquitectura: recursos, perfiles y guías de implementación

Comprender cómo funciona el FHIR en la práctica requiere estar familiarizado con algunos conceptos arquitectónicos clave.

Los recursos son los componentes fundamentales. Cada recurso representa un concepto clínico o administrativo específico y contiene un conjunto definido de elementos de datos. El recurso para pacientes, por ejemplo, contiene campos para el nombre, la fecha de nacimiento, el sexo, la dirección, la información de contacto y los identificadores. El recurso de observación se utiliza para los resultados de laboratorio, los signos vitales y otras mediciones clínicas, e incluye el código de observación, el valor, la unidad, el rango de referencia y el paciente y el encuentro al que se refiere. Los recursos pueden hacer referencia entre sí: una observación hace referencia al paciente al que pertenece, al encuentro durante el cual se grabó y al médico que la solicitó.

Los perfiles son restricciones que se aplican a los recursos básicos para adaptarlos a casos de uso específicos o contextos nacionales. Un recurso básico de observación del FHIR es lo suficientemente genérico como para representar cualquier cosa, desde una medición de glucosa en sangre hasta una puntuación de dolor notificada por un paciente. Un perfil lo limita a un propósito específico: exigir la presencia de ciertos campos, restringir los conjuntos de valores a la terminología aprobada y agregar extensiones para los elementos de datos específicos de cada caso de uso. Los perfiles permiten conciliar la flexibilidad del FHIR con la necesidad de coherencia en determinados dominios.

Las guías de implementación reúnen los recursos y los perfiles en una especificación coherente para un caso de uso específico, como el intercambio de notas clínicas entre hospitales, el apoyo a la conciliación de los medicamentos en las transiciones de atención o el acceso de los pacientes a sus propios registros de salud. Entre las guías de implementación más conocidas se encuentran la US Core, que define el conjunto mínimo de datos para el intercambio de historias clínicas en los Estados Unidos, y la International Patient Summary, que especifica un documento clínico estandarizado adecuado para la atención transfronteriza.

Los enlaces terminológicos conectan los elementos de datos del FHIR con la terminología clínica estándar: SNOMED CT para conceptos clínicos, LOINC para observaciones clínicas y de laboratorio, RxNorm para medicamentos, ICD-10 e ICD-11 para diagnósticos. Sin una terminología uniforme, dos sistemas pueden intercambiar recursos del FHIR idénticos desde el punto de vista sintáctico y que significan cosas diferentes porque utilizan códigos diferentes para el mismo concepto. Los estándares terminológicos son la capa semántica que hace que el intercambio sintáctico sea significativo.

En qué se diferencia el FHIR de sus predecesores

Para apreciar lo que representa el FHIR, es útil entender lo que lo precedió.

La versión 2 del HL7, que se introdujo a finales de la década de 1980, es un estándar de mensajería que, a pesar de su antigüedad, sigue siendo extraordinariamente generalizado; las estimaciones sugieren que sigue siendo la base de la mayoría del intercambio de datos sanitarios operativos a nivel mundial. Los mensajes del HL7 v2 se intercambian entre sistemas en tiempo real para transacciones como las admisiones de pacientes, los pedidos de laboratorio y la presentación de informes de resultados. El estándar funciona, pero es flexible hasta un punto que socava la interoperabilidad: diferentes implementadores pueden representar el mismo concepto de docenas de maneras diferentes, lo que significa que la integración entre dos sistemas normalmente requiere un trabajo de traducción personalizado, independientemente de si ambos cumplen técnicamente con el HL7 v2.

La versión 3 del HL7 fue un intento ambicioso de resolver este problema mediante un enfoque más riguroso y basado en modelos. Era técnicamente sofisticado, pero demostró ser extremadamente complejo de implementar, y su adopción siguió siendo limitada fuera de dominios y regiones geográficas específicos.

La arquitectura de documentos clínicos, también desarrollada bajo el paraguas del HL7, proporciona un formato estándar para los documentos clínicos, como los resúmenes de alta y las cartas de remisión. Los documentos CDA se utilizan ampliamente en algunos mercados, pero están optimizados para el intercambio de documentos en lugar de para la recuperación de datos detallados.

El FHIR incorpora las lecciones de todos estos predecesores y, al mismo tiempo, adopta una arquitectura orientada a los recursos y nativa de la web que ha demostrado su escalabilidad y accesibilidad para desarrolladores en prácticamente todos los demás sectores con uso intensivo de datos. No sustituye a la HL7 v2 a corto plazo (la base instalada es demasiado grande y la migración demasiado compleja), pero es el marco en el que se basará cada vez más el intercambio de datos sanitarios de cara al futuro.

Mandatos reglamentarios que impulsan la adopción

El FHIR ha pasado de ser un estándar técnico prometedor a convertirse en un requisito reglamentario en varios mercados importantes, y este ha sido el acelerador de adopción más poderoso de los últimos años.

En los Estados Unidos, la Ley de Curaciones del Siglo XXI y las subsiguientes normas de interoperabilidad emitidas por la Oficina del Coordinador Nacional de Tecnología de la Información Sanitaria y los Centros de Servicios de Medicare y Medicaid han creado requisitos vinculantes para que los sistemas de salud, los proveedores de historiales médicos electrónicos y los pagadores implementen las API basadas en el FHIR. Las normas exigen específicamente la compatibilidad con la especificación HL7 FHIR versión 4 y la Guía básica de implementación de EE. UU., y establecen disposiciones de bloqueo de información que prohíben las prácticas que restringen de manera irrazonable el acceso a la información médica electrónica.

El efecto práctico ha sido transformador. Todos los principales proveedores de registros electrónicos electrónicos de los Estados Unidos (Epic, Oracle Health, athenahealth y otros) ahora exponen las API de FHIR, y un ecosistema cada vez mayor de aplicaciones de terceros basadas en esas API ofrece capacidades de análisis, apoyo a la toma de decisiones clínicas y participación de los pacientes que antes eran imposibles sin costosas integraciones personalizadas.

En Europa, el reglamento sobre el espacio europeo de datos de salud establece un marco para el intercambio de datos de salud entre los estados miembros, con el FHIR como pilar técnico central. Los programas nacionales de implementación en países como Alemania, Finlandia, Australia y Canadá han convergido todos en el FHIR como su principal estándar de interoperabilidad.

Casos de uso clínico que el FHIR posibilita

La arquitectura técnica del FHIR tendría un interés limitado si no permitiera mejoras clínicas y operativas significativas. Los casos de uso que respalda abarcan toda la gama de la prestación de atención médica moderna.

Los registros de salud controlados por los pacientes y la agregación longitudinal de datos de salud son posibles cuando los pacientes pueden autorizar las solicitudes para recuperar sus datos de varios proveedores mediante las API de FHIR estandarizadas. Las aplicaciones que consolidan los historiales de un paciente desde su médico de atención primaria, sus especialistas, sus consultas con el hospital, el proveedor de laboratorio y la farmacia en un único cronograma coherente ya no son actos heroicos de ingeniería, sino que se pueden lograr con un esfuerzo razonable de desarrollo utilizando fuentes de datos que cumplan con las normas del FHIR.

Las transiciones asistenciales y la conciliación de la medicación se benefician enormemente de los datos estructurados del FHIR. Cuando un paciente es dado de alta del hospital, puede enviar al sistema de su médico de atención primaria un documento de transición de cuidados basado en el FHIR que incluya su lista actual de medicamentos, su lista de problemas activos, los resultados de laboratorio recientes y las instrucciones de seguimiento, en un formulario que rellena campos estructurados en lugar de aparecer como un archivo PDF adjunto que alguien debe revisar y volver a introducir manualmente.

Las herramientas de apoyo a la toma de decisiones clínicas pueden consultar las API del FHIR en tiempo real para recuperar los datos que necesitan para evaluar a un paciente según una guía clínica o un modelo de riesgo. En lugar de basarse en una instantánea estática de los datos extraídos de una historia clínica clínica en un momento determinado, un sistema de apoyo a la toma de decisiones basado en el FHIR puede recopilar los signos vitales actuales, los resultados de laboratorio recientes, la lista de medicamentos y la lista de problemas en el momento en que es necesario tomar una decisión clínica.

La gestión de la salud de la población y los informes de calidad se vuelven sustancialmente menos onerosos cuando los datos subyacentes se estructuran y codifican de manera consistente de acuerdo con los perfiles del FHIR y las terminologías estándar. La elaboración de un informe sobre el control de la hemoglobina A1c en una población diabética, la identificación de los pacientes que ya no se han sometido a una prueba de detección preventiva o la medición del rendimiento comparándola con una medida de calidad asistencial basada en el valor, requieren el tipo de datos estructurados y consultables para los que está diseñado el FHIR.

La investigación y la generación de evidencia en el mundo real se aceleran cuando los datos clínicos están disponibles en un formato estandarizado y legible por máquina. Los estudios de investigación en varios sitios que actualmente requieren meses de trabajo de armonización de datos antes de poder comenzar el análisis podrían basarse en datos del FHIR prearmonizados, lo que reduciría los plazos y reduciría los costos de manera significativa.

Desafíos de implementación que las organizaciones deben superar

El FHIR no es una solución plug-and-play. Implementarlo en una organización de atención médica real implica superar una serie de desafíos que requieren una planificación cuidadosa y una inversión sostenida.

La coherencia terminológica es con frecuencia el primer obstáculo que se encuentra en la práctica. Un recurso de observación del FHIR que contenga un resultado de laboratorio es tan interoperable como la terminología utilizada para codificar la observación. Si un sistema usa un código local para la creatinina sérica y otro usa el código LOINC correcto, el intercambio es sintácticamente válido pero semánticamente interrumpido. Lograr una terminología uniforme en todas las fuentes de datos es una tarea importante que, por lo general, requiere recursos específicos de gobierno terminológico.

La conformidad del perfil requiere que las organizaciones validen que los recursos del FHIR que producen y consumen se ajustan a los perfiles especificados en las guías de implementación pertinentes. Las herramientas de validación han mejorado sustancialmente, pero mantener la conformidad a medida que los sistemas se actualizan y las guías de implementación evolucionan requiere una atención continua.

La gestión de la identidad (garantizar que los registros relacionados con el mismo paciente estén correctamente vinculados entre los sistemas) es un requisito fundamental para una interoperabilidad significativa que el FHIR por sí solo no resuelve. Las capacidades principales de indexación de pacientes, ya sea que se implementen localmente o a través de una red de información de salud, son un requisito previo para que el intercambio basado en el FHIR funcione de manera confiable en entornos multiorganizacionales.

La gestión de la seguridad y el consentimiento debe abordarse con rigor. Las API del FHIR que exponen los datos de los pacientes requieren mecanismos sólidos de autenticación y autorización. El marco SMART on FHIR (un estándar para la autorización basada en OAuth 2.0 con las API del FHIR) proporciona la base, pero implementarlo correctamente y mantenerlo en un entorno de amenazas que cada año es más sofisticado no es tarea fácil.

La integración de sistemas heredados sigue siendo una realidad práctica para la mayoría de las organizaciones de atención médica. Implementar el FHIR no significa reemplazar los sistemas heredados de la noche a la mañana. Por lo general, implica construir una fachada de FHIR sobre los sistemas existentes: extraer datos de formatos antiguos, transformarlos en recursos del FHIR y exponerlos a través de una API del FHIR. Esta capa de integración requiere inversiones en desarrollo y mantenimiento e introduce un punto de posible degradación de la calidad de los datos que debe supervisarse.

SMART sobre el FHIR y el ecosistema de aplicaciones

Uno de los aspectos más importantes del diseño del FHIR es el ecosistema de aplicaciones que permite. El marco SMART on FHIR define una forma estándar para que las aplicaciones de terceros se ejecuten en un contexto de historia clínica electrónica y accedan a los datos de los pacientes a través de las API del FHIR, con la autorización del paciente o del médico.

Esto ha creado las condiciones para un verdadero mercado de aplicaciones en el sector de la salud por primera vez. Las aplicaciones clínicas basadas en SMART on FHIR se pueden implementar en cualquier historia clínica electrónica compatible con el estándar, sin el trabajo de integración personalizado que anteriormente hacía que dicha interoperabilidad fuera económicamente inviable para todas las empresas de tecnología, excepto para las más grandes empresas de tecnología. Las herramientas especializadas de apoyo a la toma de decisiones clínicas, las aplicaciones de educación de los pacientes, las plataformas de coordinación de la atención, las integraciones de monitorización remota y los paneles de control de la salud de la población pueden crearse una sola vez e implementarse en cualquier lugar.

La función Apple Health Records, que permite a los pacientes descargar los historiales médicos de los proveedores participantes directamente a su iPhone mediante las API del FHIR, es quizás la manifestación más destacada de este ecosistema entre los consumidores. Ha hecho que millones de pacientes conozcan el concepto de historiales médicos portátiles y ha generado una demanda de aplicaciones más completas para los pacientes que se basen en esa base de datos.

El FHIR y la arquitectura sanitaria digital más amplia

El FHIR no existe de forma aislada. Es más potente si forma parte de una arquitectura de salud digital más amplia que incluye plataformas de atención integradas, sistemas de monitorización remota, herramientas de participación de los pacientes e infraestructura de análisis, todo ello conectado a través de API estandarizadas.

Para las organizaciones de atención médica que buscan modelos de atención basados en el valor, la interoperabilidad basada en FHIR es la capa de datos que hace posible todo lo demás. Una plataforma de gestión de la atención que pueda extraer datos clínicos estructurados de múltiples fuentes a través de las API del FHIR, combinarlos con datos de monitorización remota y presentarlos en una vista unificada para el equipo clínico es, en esencia, más eficaz que una plataforma que funciona con datos aislados. La capacidad de coordinar la atención en todos los entornos, hacer un seguimiento de los resultados longitudinalmente e identificar a los pacientes que necesitan una intervención proactiva depende del tipo de datos completos, actuales y estructurados para los que está diseñado el FHIR.

Qué nos depararán los próximos cinco años

El panorama del FHIR seguirá evolucionando rápidamente. La versión 5 del FHIR, publicada en 2023, introdujo mejoras en áreas como las suscripciones, el razonamiento clínico y la compatibilidad entre versiones, que irán incorporándose progresivamente a las implementaciones de producción. La especificación de acceso masivo a datos, que permite la exportación eficiente de grandes conjuntos de datos para fines de investigación y salud poblacional, se está convirtiendo en una expectativa estándar junto con las API transaccionales del FHIR.

Las aplicaciones de inteligencia artificial y aprendizaje automático en el cuidado de la salud dependerán cada vez más de los datos estructurados por el FHIR como entrada. La calidad, la coherencia y la integridad de las implementaciones del FHIR determinarán directamente la calidad de los resultados de la IA, lo que convierte la inversión en la infraestructura del FHIR en una inversión en la preparación para la IA.

La convergencia del FHIR con la tecnología de gemelos digitales representa una de las perspectivas a largo plazo más interesantes. Una historia clínica basada en el FHIR que se actualiza continuamente y que recopila datos de los encuentros clínicos, los dispositivos de monitorización remota y los resultados notificados por los pacientes proporciona exactamente el tipo de conjunto de datos longitudinales, estructurados y multiparamétricos que necesita un gemelo digital a nivel de paciente. Las organizaciones que están creando una infraestructura sólida de FHIR en la actualidad están sentando las bases para las aplicaciones más transformadoras de la próxima década.

Conclusión

El HL7 FHIR ha pasado de ser una especificación prometedora al marco definitivo para la interoperabilidad de los datos sanitarios. Los mandatos reglamentarios han acelerado la adopción a un ritmo que las fuerzas del mercado por sí solas hubieran acelerado. La arquitectura técnica está madura, las herramientas son cada vez más eficaces y los casos de uso que permiten utilizar (desde las historias clínicas controladas por los pacientes hasta el apoyo a la toma de decisiones clínicas en tiempo real y la salud de la población basada en la IA) son atractivos desde el punto de vista clínico y económico.

El trabajo de implementación no es trivial. La gobernanza terminológica, la gestión de identidades, la arquitectura de seguridad y la integración del sistema heredado requieren un compromiso organizacional sostenido. Sin embargo, la dirección es clara y el impulso es irreversible. Las organizaciones sanitarias que inviertan ahora en las capacidades del FHIR se encontrarán con una ventaja decisiva en cuanto a la liquidez de los datos, la eficacia de la coordinación de la atención y la preparación para la próxima generación de tecnología clínica.

La era del silo de datos en la atención médica está llegando a su fin. El HL7 FHIR es cómo termina.

CareExpand está diseñado para el ecosistema de atención médica conectado, integrando la atención presencial, la telemedicina y la continuidad de la atención en una plataforma diseñada en torno a un flujo de datos continuo. Descubra cómo ayudamos a las organizaciones de atención médica a brindar una atención coordinada y basada en el valor.

‍