Una consulta no tan sencilla

Lo primero que notó es que los datos le llegaban de dos fuentes en distinto formato: un laboratorio y la red de clínicas. El laboratorio trabajaba con HL7®, un formato de mensajes que la industria usa desde los años ochenta. La red de clínicas tenía un JSON con una estructura propia.

PID|||22145678^^^RENAPER^DNI||FERNANDEZ^GRACIELA||19680314|F|||Av. Corrientes 1200^^CABA||11-4000-0001
OBR|1|||HBA1C^^L||||||||||||7^PEREZ^^^^Dr.
OBX|1|NM|HBA1C^^L||8.1|%||H|||F|||20260412

{
  "dni": "22145678",
  "pasaporte": "AAB123456",
  "nombre": "Graciela Fernández",
  "nac": "14/04/1968",
  "tel": "11-5000-0002",
  "direccion": "Av. Rivadavia 4520, CABA",
  "estudio": "7734",
  "res": "7,6",
  "fecha": "01/03/2026"
}

Con estructuras tan distintas no había forma de escribir una consulta sobre las dos. Cada pregunta había que hacerla dos veces, una por formato, y juntar las respuestas a mano. Y cada fuente nueva iba a traer un formato más.

Entonces decidió adoptar un estándar: una única forma de representar un paciente o un análisis, para que la consulta se escribiera una sola vez sobre todos los datos, vinieran de donde vinieran. Y una aplicación que transformara cada fuente a ese estándar, de modo que agregar una fuente nueva fuera cuestión de días y no de meses.

Para este caso se decidió por FHIR®. En salud existen estándares para intercambiar información clínica desde hace décadas, y FHIR® es el que la industria adoptó en los últimos años: define cómo se representa un paciente, un análisis o una receta, de modo que dos sistemas que lo implementan hablan en el mismo lenguaje. Un paciente es un Patient y un análisis es un Observation, vengan de donde vengan.

Aplicada la transformación al mensaje del laboratorio, el análisis quedó con esta forma:

{
  "resourceType": "Observation",
  "status": "final",
  "code": { "coding": [{
    "system": "http://lab.example/codigos",
    "code": "HBA1C" }] },
  "subject": { "reference": "Patient/1" },
  "effectiveDateTime": "2026-04-12",
  "performer": [{ "reference": "Practitioner/7" }],
  "valueQuantity": { "value": 8.1, "unit": "%" }
}

Con las dos fuentes en la misma estructura, pasó a mirar los códigos.

Cada fuente identificaba la hemoglobina glicosilada a su manera. El laboratorio la llamaba HBA1C. La red de clínicas la llamaba 7734 (un código de su propia tabla).

Era obviamente el mismo análisis; sin embargo, para cualquier consulta iban a ser dos cosas que no tenían nada que ver: buscar una encontraría la mitad de lo que debía. Estaría comparando peras con manzanas. No bastaba con un estándar de estructura; hacía falta también una terminología, un vocabulario común para nombrar las cosas.

Por eso se decidió por LOINC, el catálogo internacional de códigos para análisis clínicos y observaciones. La hemoglobina glicosilada informada en porcentaje es 4548-4 en cualquier laboratorio del mundo que use LOINC. Armó un mapeo, una lista que llevaba el código de cada fuente al código común. Con eso, la hemoglobina que en el laboratorio era HBA1C y en la red de clínicas era 7734 pasó a ser 4548-4 en las dos.

Lo mismo ocurrió en otros campos. En el paciente, el género femenino un sistema lo identificaba como M y otro como 1. Ambos pasaron a ser female.

Al final del proceso, terminó con un diccionario que indicaba en qué se transformaba cada valor de cada fuente.

Y con la estructura y los códigos unificados, siguió mirando los datos.

Entre los datos aparecieron valores que no cerraban.

Una hemoglobina glicosilada de 530. Luego, un número de documento con diez dígitos. También vio una paciente nacida en 1800.

Errores de carga como estos eran, y son, muy comunes. Alguien perdió una coma, alguien tipeó de más. Y bastaban para que una persona sana entrara a un programa de diabéticos, o para que cualquier análisis sobre esos datos llevara a decisiones equivocadas.

La próxima pieza que necesitaba era un control de calidad. Un conjunto de reglas comunes que se aplican a todas las fuentes y definen qué es un dato aceptable: que el valor esté en un rango posible, que el documento tenga la cantidad de dígitos correcta, que la fecha de nacimiento sea de alguien que puede estar vivo. Lo que no cumple se marca inválido y queda apartado, con el motivo.

Con los datos limpios, miró cuántos pacientes tenía.

La cantidad era demasiado grande para ser verdad. Miró un caso cualquiera, Graciela Fernández, y lo entendió. Graciela se había atendido en ambas fuentes. Ambos sistemas habían entregado sus datos médicos, pero ninguna aplicación los asoció. Graciela quedó como dos registros de paciente, cada uno con sus observaciones, estudios y recetas.

Sus historias clínicas quedaron desconectadas, y el número de pacientes, duplicado. Quien mirara la historia de Graciela desde cualquiera de los dos registros iba a ver la mitad: los estudios que le hizo el laboratorio o las consultas que tuvo en la clínica, pero no ambas cosas juntas.

Eran la misma persona, y eso no se sabía por un identificador que las dos fuentes compartieran, sino por el significado de los datos. Ese razonamiento, que una persona hace en dos segundos mirando la tabla, es el que había que hacer para cada registro que entraba, de forma automática y a escala.

Lo que necesitaba era un sistema que determinara si lo que llegaba ya existía. Que comparara por significado: dos pacientes son el mismo si comparten documento, o nombre y fecha de nacimiento; dos análisis son el mismo si tienen el mismo código, la misma fecha y el mismo paciente. Cuando la evidencia es concluyente lo resuelve solo; cuando hay duda deja el caso para que alguien lo mire, porque unir a dos personas distintas es peor que dejarlas separadas. Con eso, las dos filas quedaron asociadas: el sistema supo que referían a la misma paciente, y toda su historia clínica volvió a estar junta.

Pero asociarlas no es mezclarlas. Ahora había dos versiones de Graciela, con datos que no coincidían, y había que decidir qué hacer con cada campo.

La última solución trajo un último problema. Si la paciente ya existía y llegaba una versión nueva con datos distintos, ¿con cuál se quedaba? ¿Con qué teléfono? ¿Con qué fecha de nacimiento? ¿Con el documento o con el pasaporte, o con los dos? ¿Con qué dirección?

El sistema que evita duplicados trae consigo el problema de cómo armonizar lo que entra con lo que ya está.

Por eso, como último componente, necesitó reglas que definieran qué se conserva, qué se pisa y qué se agrega, campo por campo y por cada tipo de recurso. Con eso tuvo un único registro actualizado, que acumula toda la información que trajo cada fuente sin perder nada.

Los datos estaban desde el inicio.

Sin embargo, no se podían consultar porque llegaban con distinta estructura y distintos códigos, y porque una vez unificados había datos que exageraban el resultado: por mala calidad, o porque no existía nada que reconociera lo que ya estaba y lo que las fuentes compartían.

Y vale la pena notar algo. Adoptar FHIR® resolvió la primera de las cinco etapas. Las otras cuatro siguieron ahí. Dos sistemas perfectamente estandarizados siguen mandando códigos distintos, valores imposibles, el mismo paciente dos veces y versiones que hay que consolidar.

Estandarizar no fue suficiente.

Después de un tiempo, Jorge por fin pudo responder la consulta.