Cuando los implementadores de FHIR preguntan «¿Qué versión de FHIR debería utilizar?», los recién llegados suelen asumir que lo razonable es elegir la última versión disponible. A octubre de 2025, esa sería FHIR R5, lo que parece la opción obvia. Sin embargo, la decisión es más compleja, ya que requiere considerar detenidamente factores como la compatibilidad, la adopción y la estabilidad. Esta entrada ofrece una visión práctica de los aspectos clave, las ventajas e inconvenientes y las lecciones extraídas de nuestra experiencia apoyando implementaciones de FHIR, junto con una mirada a lo que podría traer R6.
Novedades de FHIR R5
En conjunto, FHIR R5 incorporó más de 4.000 cambios de distintas magnitudes respecto a la versión anterior. Consulte el siguiente enlace para ver la lista de los cambios principales introducidos en FHIR R5.
Entre ellos, dos destacan de manera especial: los nuevos tipos de recursos y la funcionalidad de suscripción basada en temas completamente rediseñada. A continuación analizamos cada uno en profundidad.
Nuevos tipos de recursos
FHIR R5 introduce más de 20 nuevos tipos de recursos, con 8 tipos en el nuevo módulo de Definición de Medicamentos. Este módulo describe los medicamentos con detalle: ingredientes, envases, formas de administración, estado regulatorio y usos clínicos. Hace que FHIR resulte más útil para catálogos de fármacos, presentaciones regulatorias y sistemas de seguridad que necesitan información completa sobre los productos.
Aunque estos nuevos recursos amplían las capacidades de FHIR, es posible que no supongan un «cambio radical» en términos de interoperabilidad. La mayoría de los servidores FHIR han abordado algunas de las carencias de la especificación mediante recursos personalizados. Quienes necesitaban estos tipos de recursos ya habían encontrado soluciones alternativas. Incluso si se adopta R5 con sus nuevos tipos de recursos, es posible que los socios de integración tengan dificultades para utilizarlos de forma inmediata, ya que la mayoría de los sistemas —incluidos los principales ecosistemas nacionales y de proveedores— siguen operando sobre R4. Esto resta valor al uso de tipos de recursos estándar de R5.
Suscripciones
FHIR R5 rediseñó por completo el marco de suscripciones, introduciendo la funcionalidad de suscripción basada en temas para estandarizar las notificaciones basadas en eventos. Esto facilita la definición y suscripción a tipos de eventos (p. ej., «nuevo resultado de laboratorio para el paciente X») y permite a los implementadores habilitar flujos de trabajo en tiempo real más eficaces, algo importante para las alertas de los sistemas de HCE, la salud pública y el CDS. Se trata de una mejora para los sistemas que necesitan alertas en tiempo real. Sin embargo, no es necesario contar con FHIR R5 para aprovechar esta funcionalidad: HL7 introdujo una versión intermedia —R4B— que es básicamente R4 con el marco SubscriptionTopic retroportado. Además, los servidores FHIR tampoco están limitados en este sentido, y es posible utilizar recursos personalizados para habilitar suscripciones en cualquier versión de FHIR (como hicimos en Aidbox).
Ahora que hemos visto las novedades de R5, sopesemos estas mejoras frente a los desafíos que implica la actualización.
Por qué los clientes dudan en adoptar FHIR R5
FHIR R5 es la versión oficial más reciente de FHIR, aunque las tasas de adopción siguen siendo bajas en todo el sector, incluidos nuestros clientes. FHIR R5 introduce cambios disruptivos y carece de compatibilidad con versiones anteriores, lo que dificulta que las organizaciones migren desde FHIR R4 sin un esfuerzo considerable. Los motivos se agrupan en dos categorías.
Problemas de compatibilidad con versiones anteriores
Uno de los principales problemas de R5 es la falta de compatibilidad con versiones anteriores. Muchas organizaciones han construido sus sistemas sobre FHIR R4, que actualmente es la versión más estable y ampliamente utilizada. Si bien algunos recursos como Patient y Observation han experimentado cambios mínimos entre R4 y R5, otros han sido refactorizados de forma quirúrgica. Veamos algunos ejemplos.
Uno de los recursos más utilizados —AllergyIntolerance— ha incorporado 3 nuevas propiedades (incluida una obligatoria), eliminado 2 propiedades y cambiado el tipo de dato del elemento type de code a CodeableConcept.
De este modo, el siguiente fragmento del recurso AllergyIntolerance de FHIR R4:
{
...
"type": "allergy",
"recorder": {
"reference": "Practitioner/example"
},
"asserter": {
"reference": "Patient/example"
}
...
}
Se convertiría en esto en FHIR R5:
{
...
"type" : {
"coding" : [{
"system" : "http://hl7.org/fhir/allergy-intolerance-type",
"code" : "allergy",
"display" : "Allergy"
}]
},
"participant" : [{
"actor" : {
"reference" : "Practitioner/example"
}
},
"actor" : {
"reference" : "Patient/example"
}
}]
}
Puede juzgar por usted mismo la magnitud de la diferencia —y esto es solo uno de los docenas de ajustes de este tipo. Puede consultar la lista completa aquí: https://hl7.org/fhir/R5/diff.html
Los principales proveedores de HCE, como Epic y Oracle Health (anteriormente Cerner), han invertido considerablemente en APIs e integraciones basadas en R4 —Epic con su plataforma «Epic on FHIR» y Oracle con las APIs FHIR R4 de la plataforma Millennium, incluido el acceso a datos masivos—. Ambas compañías no soportan oficialmente FHIR R5. Esto significa que cualquier persona que integre con esos ecosistemas estará mejor servida trabajando de forma nativa con R4 para garantizar la interoperabilidad. Al mismo tiempo, actualizar a R5 implica rediseñar modelos de datos, APIs e integraciones —además de acometer complejas migraciones de datos—, lo que convierte dicha transición en un proceso costoso y arriesgado para las organizaciones que dependen en gran medida de una interoperabilidad FHIR sin fisuras.
El estándar del sector: FHIR R4
Dado que la mayor parte del mundo opera actualmente sobre FHIR R4, es probable que siga siendo dominante durante años. En los Estados Unidos, la posición de R4 está reforzada por la regulación —a través de la Guía de Implementación US Core y su vinculación con el estándar USCDI, que ONC exige para la certificación de tecnologías de salud—. Programas similares impulsados por los gobiernos de otros países también se han estandarizado en R4, impulsando a proveedores y prestadores hacia el cumplimiento normativo. Incluso la IG del Resumen Internacional de Paciente, respaldada por la OMS y adoptada en múltiples regiones para facilitar el intercambio transfronterizo de datos de salud, está construida sobre FHIR R4.
Nuestro registro público de paquetes FHIR, que contiene todos los IG públicos, proporciona datos analíticos que respaldan estas afirmaciones.
Gracias a esta profunda integración, adherirse a FHIR R4 mejora la compatibilidad con la gran mayoría de las APIs y ecosistemas basados en FHIR existentes. Esta amplia adopción facilita la conexión con otros sistemas de salud, promoviendo un intercambio de datos y una interoperabilidad más fluidos tanto en redes sanitarias nacionales como transfronterizas.
Estos factores explican por qué algunos miembros de la comunidad FHIR debaten si migrar a R5 ahora o esperar y saltar directamente a R6.
El futuro: ¿Saltar R5 para ir a R6?
Algunos miembros de la comunidad FHIR sugieren omitir R5 por completo y pasar directamente de R4 a R6, aunque esta no es una posición oficial de HL7. Dado que FHIR R5 es una versión de uso provisional con cambios disruptivos y una adopción limitada entre proveedores e implementaciones nacionales, muchos implementadores son reacios a invertir en una versión que pronto podría quedar obsoleta.
Se espera que R6 restaure cierta compatibilidad con versiones anteriores y consolide los cambios introducidos en R5 haciendo que los recursos más utilizados sean normativos —es decir, estables, listos para producción y con garantía de no sufrir cambios disruptivos—. La comunidad FHIR también se esfuerza ahora por evitar nuevos cambios disruptivos, con el objetivo de alcanzar la estabilidad.
Como resultado, las organizaciones que priorizan la estabilidad a largo plazo y la alineación con el ecosistema pueden encontrar más estratégico mantenerse en R4 por el momento y planificar una migración directa a R6 una vez que alcance una mayor adopción y soporte de herramientas. En Health Samurai, tenemos previsto proporcionar herramientas que permitan una migración directa más fluida a FHIR R6 en Aidbox.
El calendario de R6 es deliberado: la primera votación «Normativa» está programada para enero de 2026, con otras dos votaciones adicionales ya planificadas. Se esperan más rondas antes de la versión final, por lo que el estándar no debería completarse antes de 2027. Mientras tanto, las próximas extensiones de versiones cruzadas de FHIR permitirán adoptar características seleccionadas de R5 o R6 manteniendo la operativa sobre R4. Este enfoque permite a las organizaciones obtener algunas de las ventajas de las versiones más recientes sin los riesgos y costes de una migración completa anticipada.
¿Qué versión de FHIR debería elegir?
Si bien Aidbox soporta FHIR R5, nuestras métricas muestran que solo el ~5 % de los usuarios lo han adoptado. A menos que existan requisitos específicos e irrefutables que solo FHIR R5 pueda satisfacer, recomendamos plantearse seriamente posponer su adopción por el momento. Mantenerse en FHIR R4 ofrece estabilidad, un amplio respaldo del sector y del ecosistema, y un camino de integración claro con las APIs de FHIR y las guías de implementación existentes.
FHIR R4 sigue siendo la opción más segura y práctica. Estaremos atentos a cómo evoluciona la transición hacia R6, pero para quienes contemplen una actualización, probablemente merezca la pena esperar en lugar de adoptar R5 de forma prematura —especialmente con R6 en el horizonte—.
Véase también: La guía de FHIR para CTOs.
