La respuesta corta

No se integra «con FHIR». Se integra con una versión concreta de FHIR, con un perfil concreto, de un sistema concreto. Esa frase es el 80 % de lo que hay que entender antes de estimar el proyecto.

FHIR define todo el contenido intercambiable como recursos —Paciente, Observación, Cita, Medicación—, cada uno con un formato común basado en tipos de datos reutilizables, metadatos estándar y contenido legible por humanos. Sobre esa base, cada hospital, cada región y cada país publican sus propias guías de implementación con sus perfiles, que restringen lo que el estándar deja abierto.

Y ahí está el trabajo real: dos sistemas «compatibles con FHIR» pueden no entenderse entre sí, porque el estándar es la gramática y el perfil es el idioma.

Recursos y REST

Un recurso es la unidad de intercambio. La forma habitual de leerlos y escribirlos es una API REST, con las operaciones que uno espera: leer por identificador, buscar con parámetros, crear y actualizar.

Un matiz que conviene conocer, porque aparece en integraciones hospitalarias reales: no hace falta usar REST para aprovechar los recursos. Hay implementaciones que los intercambian por mensajería o por documentos. Si el sistema del cliente es de esos, la parte «moderna» del proyecto se reduce y la de integración crece.

Las versiones: el primer problema del proyecto

FHIR tiene versiones publicadas y conviven en producción: la actual es R5, en estado de uso para ensayo (Standard for Trial-Use), y antes están R4B, R4, R3 y R2.

Eso importa mucho más de lo que parece:

  • R4 es el suelo realista de la mayoría de instalaciones hospitalarias. Mucho sistema en producción no está en la última.
  • Los recursos cambian entre versiones: campos que se añaden, cardinalidades que se ajustan, cosas que se renombran.
  • Tu app puede tener que hablar con dos hospitales en dos versiones distintas.

Pregunta número uno en la reunión técnica: ¿qué versión de FHIR sirve vuestro servidor? Si la respuesta es «FHIR», no hay respuesta todavía.

Perfiles y guías de implementación: donde está el trabajo

El estándar deja abierto mucho a propósito, y los perfiles lo cierran. Un perfil —definido con StructureDefinition— añade reglas que restringen la opcionalidad, la cardinalidad, los vocabularios asociados, los tipos de datos y las extensiones.

Traducido: el perfil te dice qué campos son obligatorios de verdad en ese sistema, qué codificaciones acepta y qué extensiones ha añadido.

Y las extensiones existen por diseño: FHIR incluye un mecanismo integrado para cubrir lo que el estándar no contempla. Es una virtud —permite que el estándar sirva en contextos muy distintos— y es también el sitio por donde entra la particularidad de cada hospital, que es lo que tu app va a tener que soportar.

Conformidad: pregunta por el CapabilityStatement

Cada implementación describe su interfaz mediante un CapabilityStatement: qué recursos soporta, qué operaciones, qué búsquedas.

Ese documento es lo primero que hay que pedir, antes de estimar nada. Un servidor puede exponer FHIR y no soportar la búsqueda que tu app necesita, y eso cambia el diseño por completo: si no puedes buscar por el parámetro que te interesa, o traes de más y filtras en el cliente —con su coste y sus implicaciones de privacidad— o pides un desarrollo del lado del hospital, con su calendario.

Lo que hay que resolver en el lado móvil

  • Identidad del paciente. Cómo se relaciona el usuario de tu app con su identificador en el sistema. Casi nunca es directo, y casi siempre hay una tabla de correspondencia de por medio.
  • Autorización. Quién puede ver qué, y con qué consentimiento. En entornos hospitalarios esto se resuelve con el marco de identidad del centro, no con tu propio sistema de usuarios.
  • Volumen. Un historial completo no cabe cómodamente en un móvil ni conviene descargarlo. Hay que decidir qué se trae, cuándo y qué se cachea.
  • Sin conexión. Si la app la usa un profesional en planta, la cobertura falla. Qué se puede consultar y qué se puede registrar sin red es una decisión de arquitectura, no un extra.
  • Terminologías. SNOMED, LOINC y compañía. Mostrar un código al usuario no es aceptable; traducirlo requiere acceso al servidor de terminología o un catálogo propio, y eso es alcance.

Los errores que se repiten

  • Estimar sin haber visto el CapabilityStatement del sistema real.
  • Asumir la última versión del estándar.
  • Modelar tu base de datos como copia de los recursos FHIR. Tu app tiene su propio dominio; FHIR es el formato de intercambio, no tu modelo interno. Acoplarlos hace que cualquier cambio del hospital te rompa.
  • Ignorar las extensiones hasta que aparece la primera y hay que rehacer el mapeo.
  • Probar solo contra un servidor público de pruebas. Es útil para empezar y no se parece a la instalación del cliente.

Antes de estimar

  1. ¿Qué versión de FHIR, y qué guía de implementación?
  2. ¿Podemos ver el CapabilityStatement y un entorno de pruebas del cliente?
  3. ¿REST, mensajería o documentos?
  4. ¿Quién resuelve la identidad del paciente y la autorización?
  5. ¿Qué terminologías y quién las sirve?

Con esas cinco contestadas, la integración es previsible. Sin ellas, cualquier número es una apuesta — y la parte que se descubre tarde en estos proyectos casi nunca está en el móvil, está al otro lado.

Cómo encaja esto con el sistema del hospital, y qué hacer cuando no hay FHIR sino un sistema heredado que nadie va a tocar, es la otra mitad de la conversación en apps para el sector salud.

Fuente primaria, consultada el 14 de agosto de 2026: FHIR Overview en la especificación de HL7.