Cómo integrar tu sistema de salud con FHIR
FHIR es el estándar de intercambio de datos de salud. Esta guía explica qué es, cuándo conviene integrarse con él y cómo hacerlo paso a paso, con los errores más comunes.
Hablemos de tu proyectoQué es FHIR
FHIR (Fast Healthcare Interoperability Resources) es el estándar de HL7 para el intercambio de datos de salud. Frente a los formatos legados, FHIR es moderno: recursos JSON, API REST y un modelo de datos pensado para la web. En la práctica, un sistema FHIR expone recursos como Patient, Observation, Condition, Encounter o MedicationRequest, y cualquier otro sistema que hable FHIR puede consultarlos o publicarlos con las mismas reglas.
- API REST + JSON: las mismas mecánicas que cualquier API web moderna, con versionado (R4, R5) y cabeceras estándar.
- Recursos tipados: el dato no es un blob sino un recurso con semántica definida, lo que permite interoperar sin acoplarse a una plataforma concreta.
- Acceso autorizado: SMART on FHIR define cómo conceder acceso a los recursos (OAuth 2, consentimiento del paciente, scopes por recurso).
¿Cuándo tiene sentido integrar con FHIR?
Cuando tu sistema necesita intercambiar información clínica con otros sistemas: la historia clínica del hospital, la receta electrónica, plataformas de seguimiento o dispositivos que alimentan una plataforma.
- Si solo vas a hablar con un sistema concreto y por tiempo limitado, a veces basta una integración puntual. El problema aparece cuando son varios: sin FHIR, cada integración es un canal propio para cada par de sistemas.
- Si vas a hablar con varios sistemas —o a estar en un ecosistema que lo exija (historial clínico, interoperabilidad regional, proyectos europeos)—, FHIR es el mecanismo común: cualquier sistema que hable FHIR se conecta al mismo mecanismo.
- Si tu proyecto está en investigación o en el sector público, FHIR suele ser la vía para participar sin construir una integración privada por cada socio.
Paso a paso: cómo integrar
Así lo llevamos en un proyecto real, del alcance a la puesta en producción.
Define el alcance de los datos
Qué recursos necesitas exponer y cuáles consumir: pacientes, observaciones, diagnósticos, citas, medicación. Empezar con un subconjunto pequeño es lo que permite que la integración se apruebe.
Elige la arquitectura
¿Un servidor FHIR propio (por ejemplo, HAPI FHIR o un motor open source equivalente), una capa de integración entre tus sistemas, o exponer FHIR desde tu plataforma actual? Depende de qué sistemas ya existen y de quién es dueño de cada dato.
Mapea tu modelo de datos a recursos FHIR
Cada campo de tu sistema se mapea a un recurso y a sus campos definidos. Es el paso donde más vive la integración: hacerlo bien al principio ahorra meses de parches.
Exponde la API REST con las reglas FHIR
Endpoints por recurso, versionado, manejo de errores estándar y búsquedas. Tu sistema pasa a ser una parte más del ecosistema FHIR, no una isla.
Resuelve la autorización
SMART on FHIR: OAuth 2, scopes por recurso y consentimiento del paciente. Quién puede leer qué, y con qué permiso, es parte de la integración, no un extra.
Seguridad y privacidad
Transporte cifrado (TLS), control de acceso por recurso, registro de auditoría de cada lectura y escritura, y pseudonimización cuando el flujo lo permita.
Prueba con casos reales
Interoperabilidad con el servidor FHIR de la otra parte, casos de uso clínicos de verdad y un test de conformidad antes de producción.
Errores comunes al integrar con FHIR
- Tratar FHIR como si fuera solo una base de datos: FHIR es un servicio (API, semántica, acceso), no un volcado de tablas. Si lo implementas como un dump, pierdes el valor de la interoperabilidad.
- Omitir la autorización: exponer recursos sin SMART on FHIR o sin control de acceso por recurso es el error de seguridad más frecuente en despliegues.
- Empezar con todo el alcance: intentar exponer todos los recursos de la historia clínica a la vez suele frenar el proyecto. Un piloto con pocos recursos y casos de uso reales es mucho más rápido de aprobar.
- Versión desalineada entre las partes: un sistema en R4 y otro en R5 generan incompatibilidades silenciosas. Fijar la versión y testearla es parte del alcance.
- No dejar rastro de auditoría: en salud, cada acceso a un recurso debe quedar registrado. Si la integración no lo deja, el despliegue no es auditable.
Un caso real
En un proyecto con GMV desarrollamos un sistema basado en el estándar FHIR para que el historial clínico se comunique entre sistemas de salud de forma estándar, sin acoplarse a una sola plataforma. El caso completo, con el problema y la solución, está aquí.
Guía y servicios relacionados
Empieza por una conversación de treinta minutos
Cuéntanos qué necesitas y te decimos honestamente si podemos ayudarte.