FHIR vs HL7v2: cuál usar y cuándo

Si vas a conectar un sistema con un hospital, te toparás pronto con los dos estándares: HL7v2 y FHIR. Suelen describirse como competidores, pero en la práctica resuelven problemas distintos y casi siempre conviven. Así pensamos la elección entre ellos — y por qué la respuesta real suele ser "ambos".

Qué es realmente HL7v2

HL7 versión 2 es un estándar de mensajería que ha movido la integración hospitalaria desde finales de los años 80. Los sistemas emiten mensajes delimitados por barras cuando ocurre un evento — se admite a un paciente, hay un resultado de laboratorio, se coloca una orden:

MSH|^~\&|LAB|HOSPITAL|EHR|HOSPITAL|20260624143000||ORU^R01|MSG001|P|2.6
PID|1||12345^^^HOSPITAL^MR||DOE^JANE
OBR|1|||CBC^Biometría Hemática
OBX|1|NM|718-7^Hemoglobina^LN||11.2|g/dL|12-16|L|||F

Cada tipo de mensaje cubre un flujo — ADT para admisiones, ORU para resultados, ORM/OMG para órdenes, SIU para agenda. Los mensajes viajan sobre MLLP (una capa delgada sobre TCP) y cada receptor responde con un acuse de recibo (ACK).

Es viejo, escueto y peculiar — pero está en todas partes. Prácticamente todo EHR y sistema de laboratorio habla HL7v2, y sigue siendo la columna vertebral de la mensajería clínica en tiempo real dentro del hospital.

Qué es realmente FHIR

FHIR (Fast Healthcare Interoperability Resources, R4) es un estándar moderno y orientado a API. En vez de mensajes de eventos, modela la salud como recursos — Patient, Observation, Encounter, MedicationRequest — expuestos sobre una API REST normal en JSON:

{
  "resourceType": "Observation",
  "status": "final",
  "code": { "coding": [{ "system": "http://loinc.org", "code": "718-7" }] },
  "subject": { "reference": "Patient/12345" },
  "valueQuantity": { "value": 11.2, "unit": "g/dL" }
}

Como es REST + JSON, FHIR es lo que usas cuando una app, un portal de pacientes o un asistente de IA necesita leer o escribir datos discretos bajo demanda. También sustenta SMART on FHIR, el marco OAuth 2.0 que permite a apps de terceros abrirse de forma segura dentro de Epic, Cerner y otros.

Cuándo usar cada uno

Una regla simple: HL7v2 para mensajería de eventos entre sistemas dentro del hospital; FHIR para apps y APIs que leen y escriben datos específicos.

En la realidad, usarás ambos

No son excluyentes — la mayoría de las integraciones en producción los conectan. Un patrón típico que construimos se ve así:

1. Un dispositivo o app escribe datos discretos como FHIR en un almacén canónico (p. ej., un servidor HAPI FHIR R4).
2. Una Suscripción FHIR dispara un webhook cuando llegan datos nuevos.
3. Un motor de integración (usamos Mirth Connect) traduce el recurso FHIR a un mensaje de resultado HL7v2 ORU^R01.
4. Ese mensaje se entrega sobre MLLP al motor de interfaces del hospital y aterriza en el EHR.

Esta es exactamente la forma de nuestra plataforma Vysio: un wearable transmite lecturas como FHIR, y la misma lectura sale como HL7v2 hacia Epic, Oracle Health (Cerner) o cualquier EMR que espere v2 — además de una escritura directa en FHIR donde el EHR lo soporta.

Consejos prácticos

• No elijas un estándar en abstracto — pregunta al sistema receptor. El EHR o motor de interfaces del otro lado suele dictar la respuesta.
• Mapea tus códigos una vez. LOINC, SNOMED y los códigos locales deben alinearse entre FHIR y HL7v2, o los resultados aterrizan en el lugar equivocado. Define bien la terminología desde el inicio.
• Mantén una fuente de verdad canónica. Guardar los datos como FHIR y traducir hacia afuera te mantiene flexible: puedes agregar un nuevo EMR destino sin reconstruir el origen.
• Planea acuses y reintentos. Los ACK de HL7v2 y las fallas de webhook de FHIR necesitan manejo — los descartes silenciosos son como se pierden los datos.

La interoperabilidad rara vez se reduce a "FHIR o HL7v2". Se reduce a saber cuál espera cada sistema del otro lado, y a construir la capa de traducción que los hace funcionar como uno solo.

¿Trabajas en un dispositivo, app o integración con EHR? Cuéntanos — la interoperabilidad es de las cosas que más hacemos.