FHIR es la respuesta de HL7 a la web. En lugar de mensajes de texto con delimitadores, define recursos (paciente, episodio, observación…) con dirección propia, que se leen, crean y buscan por una API como cualquier servicio web, en JSON o XML. Su núcleo es deliberadamente pequeño: cada país, región o hospital lo adapta con perfiles y guías de implementación. No sustituye de golpe a HL7 v2: conviven, y existen mapas oficiales entre ambos.

Qué es FHIR y de dónde viene

HL7 lo presenta como un marco de estándares de nueva generación que combina lo mejor de HL7 v2, HL7 v3 y CDA ¹. Se apoya en estándares web comunes: XML, JSON, HTTP y OAuth, entre otros ¹. Las soluciones FHIR se construyen con componentes modulares llamados recursos ¹.

La versión publicada en hl7.org a fecha de consulta es la Release 5 (v5.0.0) ¹. La Release 6 está en proceso de votación; su primer borrador es de diciembre de 2023 ⁵. Muchas implementaciones y guías siguen basadas en la Release 4: por ejemplo, la guía oficial de traducción de v2 a FHIR y la del resumen internacional de paciente ^{6 7}. Fecha de publicación final de la Release 6: [PENDIENTE: no publicada por HL7 a 26-oct-2026].

Recursos: piezas pequeñas y enlazadas

FHIR tiene recursos para conceptos administrativos, como paciente, profesional, organización y dispositivo, y para muchos conceptos clínicos ¹. Cada recurso es una pieza con sentido propio, que referencia a otras. Los segmentos de HL7 v2 corresponden, más o menos, a la idea de recurso de FHIR ⁴. La guía oficial de traducción lo concreta ⁶:

Una diferencia de fondo: el núcleo de los recursos FHIR es mucho más limitado que los segmentos de v2, que incluyen muchos elementos de uso raro ⁴. Lo que falta se añade con extensiones, que, a diferencia de los segmentos Z de v2, llevan una definición pública ³. Otra diferencia: los recursos llevan una parte legible por personas, algo que en general las instancias v2 no tienen ⁴.

Un resultado de laboratorio, inventado y simplificado, como recurso Observation en JSON:

{
  "resourceType": "Observation",
  "id": "obs-001",
  "status": "final",
  "code": {"coding": [{"system": "http://loinc.org", "code": "2951-2",
            "display": "Sodium [Moles/volume] in Serum or Plasma"}]},
  "subject": {"reference": "Patient/pac-123"},
  "effectiveDateTime": "2026-10-26T09:00:00+01:00",
  "valueQuantity": {"value": 139, "unit": "mmol/L",
                    "system": "http://unitsofmeasure.org", "code": "mmol/L"}
}

La prueba se identifica con el código LOINC 2951-2, sodio en suero o plasma ⁹, y la unidad, con un sistema de unidades estándar. El paciente no se copia dentro: se referencia.

La API: leer, buscar y crear por la web

FHIR se describe como una especificación RESTful ². Cada recurso tiene una dirección con el patrón [base]/[tipo]/[id] ², y las operaciones son las del protocolo web ²:

Los formatos oficiales son application/fhir+json y application/fhir+xml ². La seguridad (quién puede leer qué) no la resuelve el núcleo del estándar: se apoya en mecanismos web como OAuth ¹.

Además de la API, FHIR admite mensajería por eventos, parecida a la de v2, y documentos ^{1 4}. Un mismo recurso Observation puede viajar dentro de un mensaje, formar parte de un documento o servirse por la API.

Perfiles y guías de implementación

El estándar base casi nunca se usa tal cual: HL7 advierte que suele requerir más adaptación a cada contexto ³. Para eso hay tres herramientas ³:

• Perfil: un conjunto de restricciones sobre un recurso. Por ejemplo, que el paciente lleve obligatoriamente el identificador sanitario autonómico y que el sexo use un conjunto de códigos concreto.
• Extensión: un elemento nuevo, identificado por una dirección web que define su significado y dónde puede usarse.
• Guía de implementación: «a coherent and bounded set of adaptations that are published as a single unit».

Las guías forman una jerarquía: de los acuerdos internacionales a los de una sola institución, cada nivel añade acuerdos «with an ever smaller community» ³. Que dos sistemas «hablen FHIR» no basta. Hay que preguntar qué guía cumplen.

Un ejemplo de guía: el resumen de paciente

La guía International Patient Summary (IPS) define un conjunto de datos «minimal and non-exhaustive; specialty-agnostic and condition-independent; but still clinically relevant» ⁷. Está pensada para la atención no planificada y transfronteriza, aunque no se limita a ella, y la especifica la norma ISO 27269 ⁷. Su versión publicada es la 2.0.1, de uso a prueba, basada en FHIR Release 4 ⁷.

Encaja con lo que exige Europa. Las historias clínicas resumidas son la primera categoría prioritaria del Espacio Europeo de Datos de Salud (art. 14.1.a) ⁸. El formato europeo de intercambio deberá incluir conjuntos de datos armonizados, sistemas de codificación y especificaciones técnicas, con «normas y perfiles» (art. 15.1) ⁸. Si ese formato se apoyará en FHIR, en otro estándar o en varios: [PENDIENTE: actos de ejecución del art. 15 del Reglamento (UE) 2025/327, no publicados a 26-oct-2026].

Caso práctico

Un servicio de salud quiere que una aplicación móvil muestre al paciente sus últimos resultados de analítica. El laboratorio y la historia clínica del hospital solo hablan HL7 v2.

La solución habitual es una capa de traducción: el motor de integración recibe cada ORU^R01, convierte los OBX en recursos Observation siguiendo la guía oficial de v2 a FHIR ⁶ y los guarda en un servidor FHIR. La aplicación consulta ese servidor con búsquedas como GET [base]/Observation?patient=… ².

El punto débil no es técnico. Si el laboratorio usa códigos locales, la aplicación mostrará GLU sin explicar qué es ni podrá agrupar la misma prueba hecha en dos centros. La conversión de formato funciona; la interoperabilidad semántica requiere además un código estándar.

Qué implica para los sistemas

Elemento	Qué hay que decidir o mantener	Con quién
Servidor FHIR	Qué recursos expone, con qué perfiles y para qué usuarios	Aplicaciones de profesionales y de pacientes, otros centros
Guías de implementación	Qué guía nacional o regional se cumple y en qué versión de FHIR	Servicio de salud, Ministerio, proyectos europeos
Conversión v2 a FHIR	Mapas de segmentos a recursos y de códigos locales a estándar	Motor de integración y sistemas departamentales
Seguridad de la API	Autenticación, permisos por recurso, registro de accesos	Identidad corporativa, protección de datos