Qué es FHIR y por qué importa para tu historial médico

Si alguna vez has buscado una aplicación para tu historial médico, te has encontrado con las siglas FHIR. Aparecen en descripciones, en páginas de «seguridad y cumplimiento», en anuncios de hospitales y ministerios. Rara vez se explican. Esta guía lo hace sin convertirte en programador: qué es FHIR, qué problema resuelve, qué significa para ti en concreto y cómo saber si una aplicación lo usa de verdad o solo lo escribe en su web.

El problema: cada sistema habla un idioma distinto

Un análisis de sangre hecho en un laboratorio te llega como PDF. El mismo análisis, en el sistema del hospital, es una fila en una base de datos con formato propio. En tu médico de cabecera es, quizá, una nota de texto libre. Tres lugares, tres formatos, ninguna conexión entre ellos. Cuando quieres juntarlos, la única herramienta es una persona que los lee y los vuelve a escribir.

Durante décadas, los sistemas sanitarios se construyeron exactamente así: cada uno con su formato, intercambiando datos con otros solo mediante «puentes» escritos a medida, caros y frágiles. Los estándares antiguos (HL7 versión 2, de los años 80, o CDA) resolvieron en parte el problema para los hospitales, pero son difíciles de usar por aplicaciones modernas y casi imposibles de leer por una persona.

Qué es FHIR

FHIR (se pronuncia «fire») significa Fast Healthcare Interoperability Resources. Es un estándar publicado por HL7 International, la organización que define desde hace más de 35 años cómo se intercambian los datos médicos entre sistemas. La versión de uso generalizado hoy es R4 (4.0.1), publicada en 2019; existe una versión más nueva, R5, desde 2023, pero la mayoría de los sistemas del mundo, incluidos los requisitos legales de la UE y de EE. UU., se basan en R4.

La idea central es sencilla: cualquier información médica se describe como un recurso con una estructura conocida. Hay un recurso para el paciente (Patient), uno para un análisis o una medición (Observation), uno para un diagnóstico (Condition), uno para un medicamento prescrito (MedicationRequest), uno para una alergia (AllergyIntolerance), uno para una vacuna (Immunization), uno para un documento (DocumentReference), y así hasta unos 150 en total. Cada recurso tiene campos definidos: una Observation tiene un código de lo que se midió, un valor, una unidad, la fecha, quién midió y para quién.

Los recursos se escriben en JSON o XML, formatos que cualquier lenguaje de programación lee, y viajan por internet igual que las páginas web, mediante direcciones y peticiones HTTP. Esa es la diferencia con los estándares antiguos: FHIR usa las herramientas que cualquier programador ya conoce, así que es barato de implementar y difícil de implementar mal.

Los códigos: para que todos entiendan lo mismo

La estructura no basta. Si un sistema escribe «glucemia» y otro «glucosa sérica», siguen sin entenderse. FHIR lo resuelve exigiendo códigos estándar para el contenido:

• LOINC para análisis y mediciones: la glucosa en ayunas tiene el código 1558-6 en cualquier lugar del mundo.
• SNOMED CT e ICD-10 para diagnósticos y procedimientos.
• ATC (clasificación de la OMS) para medicamentos, por principio activo.
• UCUM para unidades: mg/dL y mmol/L se escriben igual en todas partes, y la conversión es automática.

Con estructura y códigos, un recurso FHIR producido por un laboratorio de Sibiu lo lee correctamente un hospital de Viena o una aplicación de California, sin que nadie haya escrito un «puente» entre ellos.

Qué significa para ti, en concreto

Cuatro cosas, de la más visible a la más importante.

Tus datos se pueden mover. Si tu historial está guardado como FHIR, puede exportarse completo e importarse en cualquier otro sistema compatible. No dependes de una sola aplicación ni eres rehén de un formato que solo ella entiende. «Tuyo» significa, en la práctica, «exportable en formato estándar».

Tus datos los entienden los médicos. Un médico nuevo, un hospital de otro país, un servicio de urgencias: todos pueden recibir un resumen FHIR (normalmente como Resumen Internacional del Paciente) y leerlo en su sistema, con sus códigos, en su idioma. No un PDF de 40 páginas, sino datos que pueden buscar, filtrar y comparar.

Tus datos se pueden juntar. Análisis de laboratorios distintos, mediciones del reloj, medicamentos de recetas, documentos escaneados: cuando todos son recursos FHIR con códigos LOINC y fechas, caben en la misma línea de tiempo y se pueden comparar. Una buena aplicación lo hace automáticamente.

Tus datos están protegidos por un estándar, no por una promesa. FHIR también describe cómo se concede el acceso a los datos: mediante SMART on FHIR, un marco basado en OAuth 2 en el que tú apruebas explícitamente qué aplicación ve qué parte del historial, durante cuánto tiempo, y puedes retirar el acceso. Es el mismo mecanismo que usas al «entrar con Google» en una web, aplicado a datos médicos, con permisos finos (solo los análisis, solo los medicamentos, solo lectura).

Dónde se usa ya FHIR

FHIR no es un estándar «del futuro». Ya es obligatorio o está en uso en lugares que conoces:

• Estados Unidos exige por ley (21st Century Cures Act y las normas de la ONC de 2020) que todo sistema sanitario certificado exponga los datos del paciente mediante una API FHIR R4, y que el paciente pueda llevarse sus datos con la aplicación que elija.
• Apple Health Records lleva el historial de cientos de hospitales a la aplicación Salud del iPhone mediante FHIR.
• La Unión Europea eligió FHIR para el formato europeo de intercambio de historia clínica electrónica (EEHRxF), que el reglamento EHDS impone a los Estados miembros; los resúmenes de paciente intercambiados entre países a través de MyHealth@EU se construyen sobre él.
• Reino Unido, Países Bajos, Alemania y los países nórdicos usan FHIR en sus infraestructuras nacionales, desde la receta electrónica alemana hasta el historial neerlandés.
• La Organización Mundial de la Salud eligió el Resumen Internacional del Paciente, basado en FHIR, para su red mundial de certificados sanitarios digitales.

Para ti, esto significa que una aplicación que guarda tu historial como FHIR R4 no es una isla: habla el idioma que ya hablan hospitales y autoridades, ahora y durante la próxima década.

Cómo reconocer una aplicación que usa FHIR de verdad

Cualquiera puede escribir «FHIR» en una web. Las preguntas siguientes separan la palabra de la realidad.

1. ¿Puedo exportar todo mi historial como FHIR? No «un informe PDF», sino un archivo con los recursos (un Bundle) que otro sistema pueda importar. Si la respuesta es «no» o «solo bajo petición, por correo», los datos no son realmente tuyos.
2. ¿Tienen los análisis códigos LOINC y unidades UCUM? Una aplicación que solo guarda «Colesterol: 210» como texto no puede compararlo con el valor del año pasado de otro laboratorio. Una que guarda el código y la unidad, sí.
3. ¿Puedo dar acceso a otra persona, limitado y revocable? Un médico, una clínica, otra aplicación: con SMART on FHIR tú eliges qué ven y durante cuánto tiempo, y ves quién leyó qué.
4. ¿Puedo generar un resumen IPS? Es la prueba práctica de la «interoperabilidad»: si la aplicación puede producir el resumen estándar que lee cualquier hospital europeo, la estructura que hay detrás es real.
5. ¿Hay documentación pública para desarrolladores? Una API FHIR documentada, con una declaración de capacidades (CapabilityStatement) pública, significa que otros sistemas pueden conectarse de verdad. Si no existe, «interoperable» es solo un adjetivo.

Qué no resuelve FHIR

Es justo decir también los límites. FHIR describe el formato y el transporte de los datos, no su calidad: un análisis mal introducido sigue estando mal, solo que en un formato bonito. FHIR no garantiza tu privacidad; eso depende de quién aloja los datos, en qué país y con qué reglas de acceso. Y FHIR no hace que los sistemas quieran intercambiar datos: muchos hospitales tienen API FHIR y no la abren a nadie, y por eso existe la legislación (en EE. UU., y en la UE mediante el EHDS) que los obliga.

Cómo usa Anpheros FHIR

Anpheros guarda el historial de cada persona como recursos HL7 FHIR R4 (26 tipos de recursos, desde Patient y Observation hasta DocumentReference y Consent), con códigos LOINC, ICD-10, ATC y UCUM, en la Unión Europea. La aplicación Anpheros Daily es un cliente de la misma API pública que usan clínicas y desarrolladores; no existe un formato «interno» aparte. Puedes exportar en cualquier momento el historial completo o un resumen IPS, validado con el validador oficial de HL7. El acceso de otras aplicaciones se concede mediante SMART on FHIR, con consentimiento por tiempo limitado, revocable y con un registro que puedes ver. La documentación de la API y la declaración de capacidades son públicas en developers.anpheros.com.

Preguntas frecuentes

¿Necesito saber FHIR para usar mi historial?

No. FHIR está bajo el capó. Tú ves análisis, medicamentos y documentos; el estándar hace que puedan moverse, compararse y ser leídos por médicos. Conviene saber que existe solo para elegir bien dónde guardas tus datos.

¿FHIR es lo mismo que la historia clínica electrónica nacional?

No. FHIR es un formato y una forma de transporte; el historial nacional es un sistema. Muchos sistemas nacionales usan o adoptan FHIR, pero que un país tenga historia clínica electrónica no significa que puedas sacar tus datos de allí como FHIR. En la UE, el EHDS exigirá exactamente eso.

¿Qué diferencia hay entre FHIR R4 y R5?

R5 (2023) aporta refinamientos, pero aún no lo exige la legislación y pocos sistemas lo usan. R4 (2019) es la base de los requisitos de EE. UU. y la UE y de las implementaciones existentes. Una aplicación en R4 es la elección segura hoy; el paso a R5 será gradual y compatible.

Si mi exportación es FHIR, ¿de verdad puedo importarla en otra aplicación?

Si la otra aplicación acepta importación FHIR, sí, con una condición: códigos estándar. Los recursos con LOINC, ICD-10 y UCUM se mapean limpiamente; los de texto libre acaban como notas. Por eso importa que la aplicación de origen codificara los datos desde el principio.

¿Es seguro FHIR?

FHIR en sí no es seguro ni inseguro; es un formato. La seguridad viene de la implementación: cifrado, alojamiento, autenticación, consentimiento. SMART on FHIR ofrece un buen marco para el acceso controlado, pero sigues teniendo que mirar quién guarda los datos y dónde.