Nueva versión de Cesar AI (v2)

Cesar AI es una aplicación web que transforma información de un paciente (en cualquier formato) a un recurso Patient de HL7 FHIR.

Es un experimento que construí el año 2023, con la idea de que podría ayudar a acelerar procesos de integración entre distintos sistemas informáticos en salud.

Ahora año 2026, aprovechando la Connectathon 2026, actualizamos la herramienta para que funcione (no lo estaba 😭) y para que use los últimos perfiles de HL7 Chile.

A continuación te explico sobre los cambios que hicimos.

Contexto - de dónde viene Cesar AI

Luego del evento de la Emprendethon año 2023, comencé a pensar en qué tipo de soluciones podrían ayudar a acelerar los proyectos de interoperabilidad en salud.

Si bien aprender a usar los estándares de interoperabilidad como FHIR es importante, a veces no es tan sencillo hacerlo.

Imagina un Centro Médico que quiere interoperar y que tiene su propia base de datos. En esta, tendrá información bajo un cierto esquema, que probablemente es muy diferente al formato de datos en FHIR. Así que para lograrlo, tenemos que escribir código que transforme desde el formato del Centro Médico a FHIR, lo cual toma tiempo y puede ser costoso.

¿Qué pasa si esa transformación se hace automáticamente? ¿Es posible crear un algoritmo que pase de un formato a otro de manera automática?

Ahora sí… Los cambios que hicimos

La herramienta tenía 2 problemas:

No funcionaba debido a la depreciación de la API de OpenAI.
No usaba los últimos perfiles de HL7 Chile.

Cambio #1: Actualización de la API de OpenAI

Cuando construí Cesar AI el Q1 del 2023, usé el modelo text-davinci-003 de OpenAI, que fue dado de baja, al parecer, en enero de 2024. Espero que la herramienta haya estado funcionando bien… pero al parecer llevaba mucho tiempo sin hacerlo 😭

Cuento corto, ahora la actualicé para que use gpt-4o-mini, que si bien no es lo último, me permitió no tener que hacer tantos cambios en el prompt. Posiblemente lo actualizaré a 5.1 en unas semanas.

Cambio #2: Actualización de la forma en que el LLM procesa los datos

En la primera versión de Cesar AI, el trabajo del LLM era procesar la información del paciente y te entregaba un CSV estructurado. Luego, el código de la aplicación misma se encargaba de convertir el CSV a FHIR:

Input de usuario (csv, txt, json) → LLM → CSV → Código de la aplicación → FHIR

Esto fue porque en esos tiempos no existía la posibilidad de que los modelos entregaran respuestas de tipo JSON de forma nativa, y no había una manera de forzar que el texto generado fuera un JSON válido (de manera simple). Además, generar un JSON consume más tokens que generar un CSV, es decir, es más costoso (por eso herramientas como Toon están siendo tan populares).

Luego, OpenAI introdujo soporte de respuestas tipo JSON (“JSON Mode”), pero esto no estaba libre de problemas. Una cosa es que te respondiera un JSON, pero otra muy distinta es que ese JSON tuviera la estructura correcta. Recién en Agosto del 2024 comenzaron a soportar “output” estructurado, donde puedes especificar cómo debe ser la respuesta del LLM.

Así que ahora, cuando solicitamos que el LLM genere un JSON, le decimos que debe tener la siguiente estructura:

rut: string | null - RUT del paciente
nombres: string - Nombres de pila (sin apellidos)
apellido_paterno: string - Apellido paterno
apellido_materno: string | null - Apellido materno (opcional)
genero: enum["male", "female", "other", "unknown"] - Género
telefono: string | null - Número de teléfono
email: string | null - Correo electrónico
address: string | null - Dirección
birthday: string - Fecha de nacimiento (formato YYYY-MM-DD)

Y el código de la aplicación se encarga de convertir eso a FHIR válido:

Input de usuario (csv, txt, json) → LLM → JSON (formato propio) → Código de la aplicación → FHIR

Si bien generar este JSON requiere más tokens que generar un CSV, es decir, es más costoso, ahora nos aseguramos de que tenga la estructura correcta, lo cual es mucho más fácil de lograr que al pedir un CSV.

¿Por qué no generar el JSON FHIR directamente? Bueno, si has escrito un recurso FHIR a mano, te darás cuenta de que es bastante verboso. Esta simplificación es para reducir el costo de generación (tokens!), y para reducir la posibilidad de errores al momento de que el LLM genere el JSON.

Cambio #3: Actualización de los perfiles de HL7 Chile

Una vez arreglé el problema de la API de OpenAI, me di cuenta de que el LLM no cumplía con los perfiles de HL7 Chile actuales. Así que lo primero que hice fue lograr que el resultado fuera compatible con CL Paciente.

Algunos problemas que tuve estaban relacionados con códigos que se usan en la dirección. Por ejemplo, los datos que tenía antes usaba “Región Metropolitana” como display, pero el perfil de HL7 Chile te pide “Metropolitana de Santiago”.

El nombre de display para CSCodRegionCL#13 debe ser 'Metropolitana de Santiago',no 'Región Metropolitana'

Luego me puse ambicioso y quise que el resultado cumpliera con MINSAL Paciente, que es el que usamos durante la Connectathon 2026.

Aquí tuve que hacer más cambios, ya que este pide más información que CL Paciente. Por ejemplo, birthDate y isDeceased son obligatorios en Minsal Paciente, pero no en CL Paciente. Agregué estos campos, y por supuesto que isDeceased es false por defecto.

Cambio #4: Visualización del JSON

Esto es más un detalle que una mejora, pero pensé que sería útil tener un formateador de JSON más bonito en la interfaz. Así que, le pedí a Claude Code que mejorara ese aspecto e instaló json-viewer.

Resultado

Ahora la herramienta funciona y cumple con los perfiles de HL7 Chile actuales. Está disponible en cesar.codeness.io.

Si pillas algún problema o tienes alguna sugerencia, puedes escribirme a mi LinkedIn.