FHIR (Fast Healthcare Interoperability Resources) R4 es el estándar fundamental para el intercambio moderno de datos sanitarios. Publicado por HL7 International en 2019, la Release 4 alcanzó el estatus "normativo" para sus recursos principales, lo que significa que la especificación es estable y retrocompatible. Para equipos de tecnología sanitaria que integran datos de laboratorio, sistemas HCE o soporte a la decisión clínica, FHIR R4 es el protocolo sobre el que construirán.
Esta guía proporciona un recorrido completo y orientado a la implementación de FHIR R4. Cubre los recursos más relevantes para datos de laboratorio, presenta las estructuras JSON, explica los patrones de transacción, aborda la seguridad y describe estrategias de integración del mundo real. Tanto si estás construyendo una fachada FHIR sobre un sistema legado como consumiendo salida FHIR de una API de extracción como MedExtract, este artículo te da la base técnica necesaria.
Introducción a FHIR R4
FHIR fue diseñado para reemplazar los estándares más antiguos de HL7 (mensajes V2, documentos V3/CDA) con un enfoque nativo web. Los recursos son la unidad fundamental de datos en FHIR. Cada recurso tiene una estructura definida, una URL canónica y una representación en JSON o XML. Los servidores FHIR exponen endpoints RESTful donde los clientes crean, leen, actualizan y eliminan recursos usando métodos HTTP estándar.
Por qué R4 específicamente
FHIR ha pasado por múltiples releases (DSTU 1, DSTU 2, STU 3, R4, R4B, R5). La Release 4 es la versión adoptada por la inmensa mayoría de las implementaciones en producción a nivel mundial. Las razones principales incluyen:
- Estatus normativo: Los tipos de recursos principales (Patient, Observation, Bundle) son normativos en R4, lo que significa que no cambiarán de forma retroincompatible.
- Adopción regulatoria: La regulación EEDS de la UE, las normas ONC de EE.UU. (21st Century Cures Act), y los programas nacionales de Australia, Canadá y Reino Unido hacen referencia a FHIR R4.
- Madurez del ecosistema: Las aplicaciones SMART on FHIR, las APIs de datos masivos y las guías de implementación están construidas y probadas contra R4.
- Soporte de proveedores: Todos los principales fabricantes de HCE (Epic, Cerner/Oracle Health, MEDITECH, Allscripts) exponen endpoints FHIR R4.
FHIR vs. HL7 V2
Muchos sistemas sanitarios todavía usan mensajes HL7 V2 para datos de laboratorio (segmentos ORU/OBR/OBX). Aunque V2 es ubicuo, tiene limitaciones fundamentales: sin codificación estándar (delimitadores personalizados por sitio), sin modelo de seguridad integrado y sin API nativa web. FHIR R4 aborda todo esto proporcionando una ruta de migración desde V2 a través de guías de mapeo mantenidas por HL7.
Recursos FHIR clave para datos de laboratorio
Los datos de laboratorio en FHIR R4 se representan usando un pequeño conjunto de recursos interconectados.
Patient
El recurso Patient identifica al individuo cuyos resultados de laboratorio se reportan. Como mínimo, contiene un nombre y un identificador (como un número de historia clínica o DNI). En el intercambio de datos de laboratorio, el Patient es típicamente referenciado por otros recursos en lugar de transmitirse completo.
{
"resourceType": "Patient",
"id": "patient-1",
"identifier": [{
"system": "http://hospital.example.org/mrn",
"value": "MRN-12345"
}],
"name": [{
"family": "Garcia",
"given": ["Maria"]
}],
"gender": "female",
"birthDate": "1985-03-22"
}
Observation
El recurso Observation es el caballo de batalla de los datos de laboratorio. Cada resultado individual — un valor de hemoglobina, una medición de glucosa, un recuento de leucocitos — se representa como un Observation. El recurso lleva el código LOINC que identifica la prueba, el valor del resultado, la unidad de medida, el rango de referencia y un indicador de interpretación.
{
"resourceType": "Observation",
"id": "obs-hgb-1",
"status": "final",
"category": [{
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/observation-category",
"code": "laboratory",
"display": "Laboratory"
}]
}],
"code": {
"coding": [{
"system": "http://loinc.org",
"code": "718-7",
"display": "Hemoglobin [Mass/volume] in Blood"
}]
},
"subject": {
"reference": "Patient/patient-1"
},
"effectiveDateTime": "2026-03-01T08:30:00Z",
"valueQuantity": {
"value": 14.2,
"unit": "g/dL",
"system": "http://unitsofmeasure.org",
"code": "g/dL"
},
"referenceRange": [{
"low": { "value": 12.0, "unit": "g/dL" },
"high": { "value": 17.5, "unit": "g/dL" }
}],
"interpretation": [{
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/v3-ObservationInterpretation",
"code": "N",
"display": "Normal"
}]
}]
}
DiagnosticReport
El recurso DiagnosticReport representa el informe de laboratorio como un todo. Agrupa múltiples Observations, identifica el laboratorio que realizó las pruebas y rastrea el estado del ciclo de vida del informe (parcial, preliminar, final, enmendado). Es el punto de entrada para consumir un conjunto completo de resultados de laboratorio.
{
"resourceType": "DiagnosticReport",
"id": "report-1",
"status": "final",
"category": [{
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/v2-0074",
"code": "LAB",
"display": "Laboratory"
}]
}],
"code": {
"coding": [{
"system": "http://loinc.org",
"code": "58410-2",
"display": "CBC panel - Blood by Automated count"
}]
},
"subject": {
"reference": "Patient/patient-1"
},
"effectiveDateTime": "2026-03-01T08:30:00Z",
"issued": "2026-03-01T14:00:00Z",
"result": [
{ "reference": "Observation/obs-hgb-1" },
{ "reference": "Observation/obs-wbc-1" },
{ "reference": "Observation/obs-plt-1" }
]
}
Bundle
El recurso Bundle es un contenedor que alberga una colección de otros recursos. Para datos de laboratorio, los Bundles se usan tanto para búsquedas (bundles search-set) como para envíos atómicos de datos (bundles de transacción). El Bundle de Transacción es particularmente importante para la integración de datos de laboratorio, ya que asegura que un DiagnosticReport y todas sus Observations referenciadas se creen juntas.
Anatomía de un recurso FHIR
Comprender la estructura de los recursos FHIR es esencial para una implementación correcta. Todos los recursos comparten una anatomía común.
Metadatos del recurso
Todos los recursos tienen un campo resourceType (obligatorio), un id (asignado por el servidor) y opcionalmente meta conteniendo versión, marca temporal de última actualización y declaraciones de perfil:
{
"resourceType": "Observation",
"id": "obs-123",
"meta": {
"versionId": "1",
"lastUpdated": "2026-03-01T14:00:00Z",
"profile": [
"http://hl7.org/fhir/StructureDefinition/Observation"
]
}
}
Coding y CodeableConcept
Los elementos de datos clínicos en FHIR usan el tipo CodeableConcept, que puede llevar múltiples codings de diferentes sistemas. Para observaciones de laboratorio, la codificación primaria es típicamente LOINC, pero pueden incluirse códigos locales como codificaciones adicionales:
{
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "2345-7",
"display": "Glucose [Mass/volume] in Serum or Plasma"
},
{
"system": "http://hospital.example.org/local-codes",
"code": "GLU-SER",
"display": "Glucose serum"
}
],
"text": "Glucosa basal"
}
}
El campo text preserva el texto de visualización original del documento fuente, lo cual es valioso para auditoría y resolución de problemas.
Referencias
Los recursos se referencian entre sí usando el tipo Reference. Las referencias pueden ser relativas (Patient/patient-1), absolutas (http://server.example.org/fhir/Patient/patient-1) o lógicas (usando identificadores). En Bundles de Transacción, se usan UUIDs temporales (urn:uuid:...) para establecer referencias entre recursos que aún no tienen IDs asignados por el servidor.
Extensiones
FHIR proporciona un mecanismo de extensión integrado para elementos de datos no cubiertos por la especificación base. Las extensiones se identifican por una URL y llevan un valor tipado. Los perfiles definen qué extensiones son esperadas o requeridas para un caso de uso dado.
Bundles de Transacción para operaciones atómicas
Los Bundles de Transacción son el mecanismo principal para enviar un informe de laboratorio completo a un servidor FHIR. El servidor procesa todas las entradas atómicamente: o todas tienen éxito o todas fallan.
Estructura del Bundle
{
"resourceType": "Bundle",
"type": "transaction",
"entry": [
{
"fullUrl": "urn:uuid:a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"resource": {
"resourceType": "DiagnosticReport",
"status": "final",
"code": {
"coding": [{
"system": "http://loinc.org",
"code": "58410-2",
"display": "CBC panel - Blood by Automated count"
}]
},
"subject": {
"reference": "Patient/patient-1"
},
"result": [
{ "reference": "urn:uuid:obs-hgb-uuid" },
{ "reference": "urn:uuid:obs-wbc-uuid" }
]
},
"request": {
"method": "POST",
"url": "DiagnosticReport"
}
},
{
"fullUrl": "urn:uuid:obs-hgb-uuid",
"resource": {
"resourceType": "Observation",
"status": "final",
"code": {
"coding": [{
"system": "http://loinc.org",
"code": "718-7",
"display": "Hemoglobin [Mass/volume] in Blood"
}]
},
"subject": {
"reference": "Patient/patient-1"
},
"valueQuantity": {
"value": 14.2,
"unit": "g/dL",
"system": "http://unitsofmeasure.org",
"code": "g/dL"
}
},
"request": {
"method": "POST",
"url": "Observation"
}
}
]
}
Principios clave
- UUIDs temporales: Usa identificadores con prefijo
urn:uuid:en los camposfullUrlyreference. El servidor los resuelve a IDs reales de recursos después del procesamiento. - Entradas de solicitud: Cada entrada incluye un objeto
requestespecificando el método HTTP y el tipo de recurso. POST crea nuevos recursos; PUT actualiza existentes (usando referencias condicionales para idempotencia). - Ordenamiento: El servidor procesa las entradas en orden. Coloca los recursos referenciados (Observations) antes de los recursos que los referencian (DiagnosticReport), o usa referencias
urn:uuid:que el servidor resuelve independientemente del orden. - Idempotencia: Usa creaciones condicionales (
request.ifNoneExist) para prevenir la creación duplicada de recursos cuando el mismo informe se envía múltiples veces.
Batch vs. Transaction
FHIR distingue entre tipos de bundle batch y transaction. Un transaction es atómico (todo o nada), mientras que un batch procesa cada entrada independientemente. Para datos de laboratorio, siempre prefiere transaction para prevenir ingestas parciales que podrían dejar Observations huérfanas sin un DiagnosticReport padre.
Perfiles y extensiones FHIR
Los recursos base de FHIR son intencionalmente amplios. Los perfiles los restringen para casos de uso específicos definiendo campos obligatorios, limitando conjuntos de valores y declarando extensiones esperadas.
Perfiles comunes para datos de laboratorio
- US Core Laboratory Result Observation: Define requisitos mínimos de datos para observaciones de laboratorio en el contexto estadounidense.
- International Patient Summary (IPS): Perfil transjurisdiccional que incluye resultados de laboratorio como parte de un resumen del paciente.
- EU Laboratory Report: Perfil alineado con los requisitos del EEDS para el intercambio transfronterizo de datos de laboratorio.
Declaración de conformidad con perfiles
Un recurso declara a qué perfiles se ajusta en su array meta.profile:
{
"meta": {
"profile": [
"http://hl7.eu/fhir/laboratory/StructureDefinition/Observation-resultslab-eu-lab"
]
}
}
Los servidores pueden validar los recursos entrantes contra los perfiles declarados, rechazando datos no conformes.
Extensiones personalizadas para extracción de laboratorio
Al generar salida FHIR desde un pipeline de extracción, puedes necesitar extensiones para metadatos que la especificación base no cubre:
- Confianza de extracción: Una puntuación numérica indicando cuán seguro está el sistema del mapeo LOINC.
- Coordenadas de origen: Coordenadas del cuadro delimitador identificando dónde en el documento original se extrajo cada valor.
- Etapa de emparejamiento: Qué etapa de la cascada de emparejamiento produjo el código LOINC (útil para auditoría).
Estas se definen como extensiones con una URL personalizada, por ejemplo:
{
"extension": [{
"url": "http://medextract.io/fhir/StructureDefinition/extraction-confidence",
"valueDecimal": 0.97
}]
}
Autenticación y seguridad
El intercambio de datos sanitarios requiere seguridad robusta. FHIR especifica mecanismos de seguridad a múltiples niveles.
SMART on FHIR
SMART (Substitutable Medical Applications, Reusable Technologies) on FHIR es el framework de autorización dominante para servidores FHIR. Extiende OAuth 2.0 con scopes específicos de salud y contextos de lanzamiento. Un flujo típico:
- La aplicación cliente solicita scopes de autorización (p. ej.,
patient/Observation.read,system/DiagnosticReport.write). - El servidor de autorización autentica al usuario o sistema y emite un token de acceso.
- El cliente incluye el token de acceso en el header
Authorizationde las solicitudes a la API FHIR. - El servidor FHIR valida el token y aplica los scopes concedidos.
Seguridad en transporte
Todos los intercambios FHIR deben usar TLS 1.2 o posterior. Se recomienda TLS mutuo (mTLS) para integraciones servidor a servidor donde ambas partes necesitan verificar identidad.
Registro de auditoría
FHIR define el recurso AuditEvent para registrar el acceso a datos clínicos. Cada operación de lectura, creación, actualización y eliminación debe generar un AuditEvent que capture quién accedió a qué datos y cuándo. Esto es esencial para el cumplimiento del RGPD y para satisfacer los requisitos de transparencia del EEDS.
Datos en reposo
Los servidores que almacenan recursos FHIR deben cifrar los datos en reposo usando AES-256 o equivalente. El acceso a las claves de cifrado debe seguir el principio de mínimo privilegio y gestionarse a través de un servicio dedicado de gestión de claves.
Manejo de errores y validación
Un manejo robusto de errores es crítico para integraciones FHIR fiables.
OperationOutcome
Los servidores FHIR devuelven errores usando el recurso OperationOutcome. Cada issue incluye una severidad (fatal, error, warning, information), un código (invalid, required, not-supported, etc.) y un mensaje de diagnóstico legible:
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "required",
"diagnostics": "Observation.code is required",
"location": ["Observation.code"]
}]
}
Estrategias de validación
- Validación de esquema: Verificar que la estructura JSON coincide con la definición del recurso FHIR.
- Validación de perfil: Comprobar conformidad con los perfiles declarados, incluyendo campos obligatorios y bindings de conjuntos de valores.
- Validación de reglas de negocio: Aplicar reglas específicas del dominio (p. ej., valor del resultado dentro del rango de plausibilidad para el código LOINC dado).
- Validación de terminología: Verificar que los valores codificados existen en los sistemas de códigos referenciados (LOINC, SNOMED CT, UCUM).
El FHIR Validator de HL7 (basado en Java) es la implementación de referencia para validación. Puede ejecutarse como herramienta CLI, embeberse en un pipeline de servidor o accederse a través de servicios alojados.
Manejo de fallos parciales
Cuando un Bundle de Transacción falla, el servidor rechaza el bundle completo y devuelve un OperationOutcome explicando qué entrada causó el fallo. El cliente debe analizar esta respuesta, corregir la entrada ofensora y reenviar. Registrar el OperationOutcome completo es esencial para depurar problemas de integración.
Patrones de integración del mundo real
Los despliegues de FHIR R4 siguen varios patrones arquitectónicos comunes.
Patrón 1: Fachada FHIR
Una fachada FHIR se sitúa delante de un sistema legado (p. ej., un SIL usando protocolos propietarios) y expone sus datos a través de endpoints FHIR. La fachada traduce las solicitudes FHIR entrantes al protocolo legado y traduce las respuestas de vuelta a recursos FHIR. Este patrón es común durante la migración desde sistemas HL7 V2.
Patrón 2: Integración orientada a eventos
Los resultados de laboratorio disparan eventos que se publican en un broker de mensajes (p. ej., Kafka, NATS). Los suscriptores consumen estos eventos y procesan los Bundles FHIR — almacenándolos en un data warehouse, enviándolos a un HCE o activando reglas de soporte a la decisión clínica. Esta arquitectura desacoplada escala bien y maneja rendimiento variable.
Patrón 3: Exportación masiva de datos
FHIR Bulk Data Access (operación $export) permite la extracción de datos a gran escala desde servidores FHIR. El servidor genera archivos NDJSON conteniendo recursos que coinciden con los criterios solicitados. Este patrón es esencial para analítica, informes de calidad y gestión de salud poblacional.
Patrón 4: Integración con API de extracción
Para organizaciones que procesan informes de laboratorio en papel o PDF, el flujo de trabajo comienza con una API de extracción. La API recibe imágenes de documentos, realiza OCR y mapeo LOINC, y devuelve un Bundle de Transacción FHIR. El sistema receptor envía este bundle a su servidor FHIR, donde pasa a formar parte del expediente electrónico del paciente. Este es el patrón que MedExtract soporta.
PDF/Imagen → API MedExtract → Bundle FHIR → Servidor FHIR → HCE
Patrón 5: Notificaciones por suscripción
FHIR R4 incluye un mecanismo de Subscription donde los clientes registran interés en cambios específicos de recursos (p. ej., "notifícame cuando se cree un nuevo DiagnosticReport para el paciente X"). El servidor envía notificaciones vía webhooks o canales WebSocket. R5 introduce un modelo mejorado de suscripción basado en temas, pero las suscripciones R4 siguen ampliamente desplegadas.
FHIR y el Espacio Europeo de Datos Sanitarios (EEDS)
La regulación del Espacio Europeo de Datos Sanitarios, adoptada por el Parlamento Europeo, exige el intercambio estandarizado de datos de salud entre los estados miembros de la UE. Los datos de laboratorio son una de las categorías prioritarias.
Requisitos del EEDS para datos de laboratorio
- Formato estandarizado: Los resultados de laboratorio deben ser intercambiables en un formato electrónico estandarizado. FHIR R4 es la elección de implementación de facto.
- Vocabulario codificado: Las observaciones deben usar códigos LOINC. La regulación referencia el sistema LOINC explícitamente.
- Intercambio transfronterizo: Los sistemas deben soportar la infraestructura MyHealth@EU para el intercambio transfronterizo de datos.
- Acceso del paciente: Los individuos tienen derecho a acceder a sus datos de salud en formato electrónico.
Perfil EU Lab Report
HL7 Europe ha publicado la Guía de Implementación EU Laboratory Report, que define perfiles FHIR específicos para el intercambio europeo de datos de laboratorio. Los perfiles clave incluyen:
- EU Lab Observation: Extiende la Observation base con bindings de conjuntos de valores específicos de la UE y resultados codificados obligatorios.
- EU Lab DiagnosticReport: Añade requisitos para la organización ejecutante, el intérprete de resultados e información del espécimen.
- EU Lab Bundle: Define la estructura para transmitir informes de laboratorio completos a través de fronteras.
Las organizaciones que construyen sistemas de datos de laboratorio para el mercado europeo deben implementar estos perfiles para asegurar el cumplimiento del EEDS.
Cronograma e implicaciones prácticas
La implementación del EEDS es por fases entre los estados miembros, con requisitos operativos completos esperados entre 2028 y 2031. Sin embargo, los adoptantes tempranos ya están construyendo infraestructura basada en FHIR, y los entornos sandbox nacionales están disponibles para probar el intercambio transfronterizo. Empezar con FHIR R4 ahora posiciona a las organizaciones para cumplir los plazos regulatorios sin rehacer trabajo importante.
Construcción de un pipeline de datos de laboratorio conforme con FHIR
Construir un pipeline completo de datos de laboratorio desde la entrada de documentos hasta la salida FHIR involucra varias etapas, cada una con consideraciones FHIR específicas.
Etapa 1: Procesamiento de documentos
Aceptar informes de laboratorio en formato PDF, imagen o electrónico. Para informes en papel, aplicar OCR con detección de tablas y extracción de entidades. La salida es datos estructurados conteniendo nombres de pruebas, valores, unidades y rangos de referencia.
Etapa 2: Mapeo LOINC
Mapear los nombres de pruebas extraídos a códigos LOINC usando la cascada de emparejamiento multietapa descrita en nuestro artículo complementario. Cada emparejamiento incluye una puntuación de confianza que puede exponerse en la salida FHIR mediante una extensión.
Etapa 3: Generación de recursos FHIR
Ensamblar los datos mapeados en recursos FHIR:
- Crear un Observation para cada resultado de prueba, rellenando
code(LOINC),valueQuantity(resultado + unidad),referenceRangeeinterpretation. - Crear un DiagnosticReport referenciando todas las Observations, con
status,codey marcas temporalesissuedapropiadas. - Envolver todo en un Bundle de Transacción con referencias
urn:uuid:.
Etapa 4: Validación
Ejecutar el Bundle generado a través de un validador FHIR configurado con los perfiles objetivo (R4 base, EU Lab, o perfiles organizativos personalizados). Corregir cualquier error de validación antes del envío.
Etapa 5: Envío
POST del Bundle de Transacción al endpoint del servidor FHIR objetivo ([base]/). Analizar la respuesta para extraer los IDs de recursos asignados por el servidor. Manejar errores examinando el OperationOutcome en la respuesta.
Etapa 6: Monitorización
Rastrear tasas de éxito de envío, frecuencias de errores de validación y tiempos de respuesta del servidor. Configurar alertas para patrones de fallo. Mantener un registro de auditoría de cada bundle enviado y cada respuesta recibida.
Usando la API de MedExtract
MedExtract maneja las etapas 1 a 3 en una sola llamada a la API. Envías un documento de informe de laboratorio y recibes un Bundle de Transacción FHIR R4 validado. La API soporta tanto la especificación R4 base como los perfiles EU Lab, haciéndola adecuada para despliegues en todo el Espacio Europeo de Datos Sanitarios.
Para empezar:
- Revisa la documentación de la API para especificaciones de endpoints
- Prueba con informes de laboratorio de muestra de tu red
- Solicita una demo para un recorrido guiado
FHIR R4 proporciona la base estable e interoperable que el intercambio de datos sanitarios requiere. Combinado con la extracción automatizada de LOINC, permite un pipeline completamente digital desde el informe de laboratorio en papel hasta los datos clínicos estructurados y conformes a estándares.
Artículos relacionados
Guía de integración FHIR R4 para sistemas HCE
Una visión práctica de la integración de recursos FHIR R4 en sistemas HCE, centrada en bundles DiagnosticReport y Observation de datos de laboratorio.
Guía completa de extracción de códigos LOINC
Todo sobre la extracción automatizada de códigos LOINC desde informes de laboratorio: proceso, desafíos, diccionarios y mejores prácticas.
El recurso FHIR DiagnosticReport explicado
Todo sobre el recurso DiagnosticReport de FHIR R4: estructura, campos, perfiles y cómo representa informes de laboratorio.