HL7 FHIR es un estándar de interoperabilidad sanitaria que estructura el intercambio de datos clínicos mediante APIs. Organiza la información en recursos como Patient, Observation, Encounter o MedicationRequest, que representan pacientes, observaciones clínicas, episodios asistenciales y solicitudes de medicación dentro de un modelo común. Esta arquitectura facilita que diferentes sistemas sanitarios compartan información con mayor coherencia semántica.
HL7 FHIR conecta la historia clínica electrónica con sistemas HIS, LIS, PACS y nuevas aplicaciones HealthTech mediante una capa de interoperabilidad basada en recursos, perfiles y terminologías clínicas. Este modelo también facilita el desarrollo de APIs sanitarias para analítica, automatización e Inteligencia Artificial, ya que mantiene el contexto, la trazabilidad y las relaciones necesarias para interpretar correctamente los datos clínicos.
Cómo funciona HL7 FHIR en la ingeniería de APIs sanitarias
HL7 FHIR estructura la información clínica en recursos normalizados que los sistemas sanitarios intercambian mediante APIs definidas. Cada recurso representa una entidad concreta del entorno asistencial, como un paciente, una observación clínica, una medicación o un episodio. Además, FHIR establece relaciones entre esos recursos para conservar el contexto clínico y evitar que los datos circulen como elementos aislados. Este modelo facilita una interoperabilidad sanitaria más modular y reutilizable entre aplicaciones, plataformas y sistemas hospitalarios.
La ingeniería de APIs con HL7 FHIR añade una capa de control sobre ese modelo mediante perfiles, terminologías y reglas de implementación. Los perfiles delimitan cardinalidades, extensiones y códigos admitidos, mientras que CapabilityStatement declara las capacidades que ofrece un servidor FHIR. Sobre esa base, las APIs ejecutan operaciones mediante HTTP para consultar, crear, actualizar o buscar recursos clínicos con un comportamiento predecible. FHIR incorpora también parámetros de búsqueda, paginación, historial de versiones y mecanismos de extensión que ayudan a mantener contratos interoperables entre productores y consumidores de datos sanitarios.
El resultado es una arquitectura donde la API actúa como contrato clínico y técnico, no como un simple canal para trasladar información.
HL7 FHIR estandariza APIs sanitarias, conecta sistemas clínicos, refuerza seguridad e interoperabilidad y facilita integrar Inteligencia Artificial con trazabilidad clínica
Cómo se integra HL7 FHIR con HCE, HIS, LIS y PACS
La integración de HL7 FHIR en un hospital suele apoyarse en una capa de interoperabilidad situada entre los sistemas clínicos existentes y las nuevas aplicaciones digitales. Este enfoque evita sustituir de manera inmediata plataformas críticas y permite normalizar el intercambio de datos mediante un modelo FHIR común. La organización define así un modelo canónico que desacopla los sistemas de origen de los consumidores de información clínica.
El FHIR Server o FHIR Gateway funciona como punto de acceso a esa arquitectura. Actúa como repositorio clínico o como fachada que consulta los sistemas internos cuando una aplicación solicita información. Además, suele convivir con motores de integración que siguen procesando mensajería HL7 v2, documentos CDA y otros formatos heredados. De este modo, el hospital moderniza sus APIs sanitarias sin interrumpir los flujos que sostienen la actividad asistencial.
Dentro de esta arquitectura, cada componente mantiene una responsabilidad diferenciada:
- HCE o EHR concentra información clínica longitudinal como problemas de salud, alergias, medicación, episodios y documentación asistencial.
- HIS gestiona principalmente procesos administrativos relacionados con admisiones, altas, traslados y actividad hospitalaria.
- LIS controla el circuito del laboratorio, desde las peticiones y muestras hasta los resultados y su validación.
- PACS almacena las imágenes médicas y los metadatos asociados a los estudios de diagnóstico por imagen.
- FHIR Server o Gateway normaliza el acceso a estos dominios y expone recursos clínicos mediante APIs gobernadas.
La interoperabilidad clínica exige además conservar el significado del dato. LOINC identifica pruebas de laboratorio, SNOMED CT representa problemas y hallazgos clínicos, ICD facilita determinadas codificaciones, UCUM normaliza unidades y DICOM estructura el ecosistema de imagen médica. Sin esta capa semántica, una integración consigue transportar información, pero no garantiza que todos los sistemas la interpreten de la misma forma.
Cómo intercambia HL7 FHIR datos con HL7 v2 y CDA
HL7 FHIR convive con HL7 v2 y CDA porque cada estándar responde a una necesidad distinta dentro del intercambio de datos clínicos. HL7 v2 mantiene un papel esencial en la mensajería operacional de muchos hospitales, donde transporta eventos como admisiones, altas, traslados, órdenes o resultados. CDA, en cambio, estructura documentos clínicos completos y combina información codificada con contenido narrativo. HL7 FHIR adopta otro enfoque mediante recursos clínicos reutilizables que las aplicaciones consultan e intercambian a través de APIs.
La interoperabilidad entre estos modelos depende de los mapeos semánticos. Transformar un mensaje HL7 v2 en recursos FHIR exige identificar qué representa cada elemento antes de trasladarlo. Un mensaje ORU^R01 con resultados de laboratorio, por ejemplo, genera recursos Observation vinculados con Patient y Encounter. Para mantener el significado clínico también deben conservarse códigos, unidades, fechas y procedencia del dato. Cuando corresponde, LOINC normaliza la prueba y UCUM mantiene una representación coherente de las unidades.
Con CDA aparece un reto diferente. El documento se conserva mediante DocumentReference y, al mismo tiempo, sus elementos estructurados se transforman en recursos como Condition, MedicationStatement o AllergyIntolerance. Este modelo permite preservar el documento original mientras habilita búsquedas, analítica y procesamiento granular de la información clínica.
La diferencia funcional entre los tres estándares queda resumida en este cuadro.
| Estándar | Modelo | Uso principal | Papel en una arquitectura actual |
|---|---|---|---|
| HL7 v2 | Mensajes | Eventos clínicos y administrativos | Integración interna |
| CDA | Documentos | Informes y continuidad asistencial | Documento clínico estructurado |
| HL7 FHIR | Recursos y APIs | Acceso e intercambio granular | Capa moderna de interoperabilidad |
Cómo se protegen y validan las APIs con HL7 FHIR
La seguridad de una API basada en HL7 FHIR depende tanto del control de acceso como de la validez clínica de los datos que intercambia. Una implementación técnicamente correcta pierde fiabilidad si concede permisos excesivos, no registra los accesos o acepta recursos que incumplen los perfiles definidos. Por eso, la protección de las APIs sanitarias debe integrarse con su gobernanza y con los mecanismos que verifican el contrato FHIR.
En este contexto, la seguridad y la interoperabilidad de una API sanitaria dependen de varios controles técnicos:
- Autenticación: OAuth2 y OpenID Connect permiten identificar aplicaciones y usuarios antes de acceder a los recursos clínicos. SMART on FHIR adapta estos mecanismos al entorno sanitario y facilita la integración segura con la historia clínica electrónica.
- Autorización: Los scopes delimitan qué recursos y operaciones admite cada token. Los modelos RBAC y ABAC añaden restricciones relacionadas con el rol profesional, el episodio asistencial, la organización o el contexto desde el que se solicita información.
- Auditoría: AuditEvent registra quién accedió a los datos, qué acción realizó, cuándo ocurrió y sobre qué recursos. Esta trazabilidad es esencial para investigar accesos y reconstruir operaciones sobre información clínica.
- Cifrado: TLS protege las comunicaciones en tránsito, mientras que el cifrado de bases de datos, copias de seguridad y almacenamiento protege los datos en reposo.
- Validación de perfiles: StructureDefinition, ValueSet y otros artefactos permiten comprobar cardinalidades, terminologías, extensiones y reglas específicas. CapabilityStatement declara qué recursos, búsquedas y operaciones admite cada servidor FHIR.
- Pruebas de contrato: Los tests automatizados verifican endpoints, códigos HTTP, paginación, perfiles, compatibilidad y comportamiento ante cambios. Integrarlos en CI/CD permite detectar modificaciones incompatibles antes de que alcancen sistemas clínicos en producción.
Así, HL7 FHIR convierte la seguridad y la validación en partes del propio contrato de interoperabilidad. No basta con proteger el acceso al dato. También hay que garantizar que cada recurso conserve una estructura, una semántica y un comportamiento coherentes durante todo su ciclo de intercambio.
Cómo conecta HL7 FHIR las APIs sanitarias con la Inteligencia Artificial
HL7 FHIR facilita que los sistemas de Inteligencia Artificial accedan a datos clínicos estructurados sin depender de integraciones específicas para cada historia clínica electrónica. Un modelo consume recursos como Observation, Condition, MedicationRequest, DiagnosticReport o DocumentReference para combinar resultados de laboratorio, diagnósticos, tratamientos, informes y otros elementos del contexto asistencial. Esta normalización reduce la dependencia de formatos propietarios y permite construir pipelines de datos más reproducibles.
La inferencia se integra de manera síncrona o asíncrona según el flujo clínico. En un proceso síncrono, una aplicación solicita una predicción mientras el profesional trabaja con el paciente y recibe el resultado dentro del mismo flujo asistencial. En cambio, una arquitectura asíncrona permite ejecutar modelos cuando aparece un nuevo resultado, se cierra un episodio o se produce otro evento clínico relevante. El resultado vuelve después al ecosistema FHIR mediante recursos como Observation, RiskAssessment, DetectedIssue o Task, según el significado y la función que tenga esa información.
Una arquitectura más avanzada incorpora una FHIR façade que normaliza el acceso a los recursos antes de transformarlos en variables utilizadas por el modelo. Esta capa permite registrar qué información alimentó cada inferencia y conservar referencias como meta.versionId para reconstruir el estado exacto de los datos clínicos utilizados. Así, los procesos de MLOps mantienen trazabilidad entre los recursos originales, las variables generadas, la versión del modelo y el resultado producido.
Este enfoque evita que la Inteligencia Artificial genere un nuevo silo desconectado de la arquitectura hospitalaria. HL7 FHIR permite integrar las inferencias dentro del mismo marco de interoperabilidad, seguridad y gobernanza que utiliza el resto de los datos clínicos. Trabajar con este tipo de arquitecturas exige comprender tanto la gestión del dato sanitario como los modelos de Inteligencia Artificial que lo procesan, dos ámbitos que convergen en la formación del Máster en Big Data Sanitario de Campus Health Tech.