HL7 y FHIR son los idiomas con los que los sistemas de salud se entienden entre sí. La pregunta práctica no es cuál usar, sino qué se gana el primer día y qué exige cada uno de la institución.
En un hospital conviven muchos sistemas: admisión, laboratorio, imágenes, farmacia, historia clínica, facturación. Cada uno guarda su parte de la historia del paciente. Si no comparten un lenguaje común, esa historia queda partida en pedazos que no se hablan.
Qué es HL7
HL7 —Health Level Seven— es el estándar clásico para que los sistemas de salud intercambien información. Su versión más difundida, la v2, funciona con mensajes: cuando algo pasa —ingresa un paciente, sale un resultado de laboratorio— un sistema le manda a otro un mensaje con esa novedad, estructurado en un formato acordado.
Es una tecnología madura, muy extendida, presente en buena parte de los sistemas hospitalarios que hoy funcionan. También es de una época anterior a la web tal como la usamos ahora: sus mensajes no se parecen a lo que un desarrollador moderno espera consumir.
Qué es FHIR
FHIR —Fast Healthcare Interoperability Resources— es la propuesta moderna, y su enfoque es distinto. En vez de mensajes, trabaja con recursos expuestos por una API REST, como cualquier servicio web actual.
Cada concepto clínico es un recurso con nombre propio:
- Patient: la persona atendida y sus datos de identificación.
- Encounter: un episodio de atención —una consulta, una hospitalización.
- Observation: un dato observado —un resultado de laboratorio, un signo vital.
Y hay muchos más: citas, medicamentos, diagnósticos, procedimientos. La gracia es que se consultan y se crean con las mismas operaciones REST que ya usa cualquier sistema web, lo que baja muchísimo la barrera para conectarse.
HL7 v2 le pregunta a tu sistema si sabe leer mensajes de salud. FHIR le pregunta si sabe hacer una llamada a una API. Casi cualquier sistema moderno sabe lo segundo.
Para qué sirve, en concreto
La interoperabilidad no es un fin en sí mismo. Sirve para que la información del paciente esté donde tiene que estar, sin que alguien la copie a mano de un sistema a otro:
- Historia clínica. Que lo registrado en un servicio esté disponible en otro, sin volver a preguntar ni volver a digitar.
- Citas. Que agendar en un sistema se refleje en los demás.
- Laboratorio. Que un resultado emitido en el laboratorio llegue solo a la historia del paciente y a quien lo pidió.
En todos los casos, el enemigo es el mismo: el dato que existe en un sistema pero que otro no ve, y que termina reescribiéndose a mano o directamente perdiéndose.
Por dónde empezar si la historia clínica todavía es de papel
Aquí está la parte que más angustia y que menos debería. No hay que digitalizar todo el hospital para empezar a interoperar. Hay que empezar por lo que sirve, y crecer por casos.
Identificar los datos. Antes que tecnología, claridad: qué datos se quieren compartir y para qué. No “todo”; los concretos que hoy alguien copia de un lado a otro o que hoy se pierden. La identificación del paciente casi siempre es el primer bloque, porque ata todo lo demás.
Exponerlos por API. Una vez claros los datos, se exponen a través de una API —FHIR encaja bien aquí porque sus recursos ya están pensados para esto—. No hace falta reemplazar los sistemas que funcionan; hace falta darles una puerta por la que hablar.
Ir por casos. No se aborda la interoperabilidad entera de golpe. Se elige un caso con valor claro —por ejemplo, que los resultados de laboratorio lleguen a la historia—, se resuelve de punta a punta, y recién entonces se toma el siguiente. Cada caso resuelto deja infraestructura y aprendizaje para el que sigue.
Este enfoque pragmático tiene una ventaja sobre el gran proyecto de digitalización total: entrega valor desde temprano y no exige apagar lo que hoy funciona para empezar. El papel no se elimina de un día para otro; se va reemplazando donde ya hay un dato que vale la pena compartir.
HL7 o FHIR, en la práctica
Rara vez es “uno u otro”. Los sistemas hospitalarios existentes muchas veces ya hablan HL7 v2, y eso hay que respetarlo. FHIR es por dónde conviene construir lo nuevo y por dónde conectar con lo moderno. Un proyecto real suele tender puentes entre ambos: aprovechar el HL7 que ya está y exponer FHIR hacia lo que viene.
Lo importante es no confundir el estándar con el objetivo. El objetivo es que la información del paciente circule; HL7 y FHIR son los medios.
Empezar por identificar los datos que importan, exponerlos por API e ir caso por caso convierte la interoperabilidad de un proyecto enorme y postergable en una serie de pasos concretos que rinden desde el primero.