Cuando empieza un brote, la primera pregunta no es “¿qué tan grave es?”. Es “¿con qué lo vamos a seguir?”.

En una jurisdicción sanitaria de la Ciudad de México, la respuesta suele ser: con lo que haya. Excel, WhatsApp, hojas impresas que alguien captura después. Herramientas pensadas para reportar, no para vigilar en tiempo real. Y un brote nunca espera a que el reporte mensual esté listo.

Esa es la pregunta que resolví construyendo, desde cero, un sistema para apoyar la vigilancia epidemiológica. No cuento aquí cómo va el brote, porque sigue en curso y esos datos son operativos, no de portafolio. Cuento cómo se construyó la herramienta, porque esa parte sí puedo compartirla.

El problema no fue solo técnico, también fue de diseño. Se requiere una herramienta que actualizara casos casi en tiempo real, que mostrara riesgo por zona sin que alguien tuviera que interpretar una tabla dinámica cada mañana, y que protegiera la identidad de cada persona registrada aunque el sistema viviera, en parte, en internet público. Tres necesidades que normalmente requieren presupuesto institucional. Yo tenía Supabase (una base de datos en la nube con capa gratuita, que además permite definir permisos fila por fila) y Cloudflare Pages (hosting gratuito para sitios estáticos, con despliegue automático cuando subes cambios a GitHub).

La primera decisión de fondo fue el AGEB como unidad de análisis. El AGEB (Área Geoestadística Básica, la unidad territorial que usa el INEGI para dividir el país en polígonos manejables) permite hablar de riesgo por zona sin señalar una calle o una casa específica. En vez de mostrar “aquí hay un caso”, el sistema muestra “esta zona tiene riesgo alto”, que es la pregunta que realmente le importa a un equipo de territorio. Detrás de esos datos está el trabajo diario del equipo de campo que levanta la información casa por casa, sin ellos el modelo no tendría con qué alimentarse.

Ese riesgo no es una sola cifra, es un puntaje compuesto: pondera casos confirmados, días transcurridos sin barrido de vacunación, cobertura de vacunación (invertida, para que menos cobertura sume más riesgo), concordancia entre lo aplicado y lo esperado, y dosis por vivienda (invertida, mismo criterio: menos dosis por vivienda, más riesgo). Cada variable importa distinto, y ese peso relativo fue una decisión metodológica, no solo una fórmula. Se documentó formalmente, con referencias de organismos como la OMS y los CDC, porque un modelo de riesgo que nadie puede auditar no sirve para tomar decisiones, solo para verse sofisticado.

La segunda decisión de fondo fue qué mostrar y a quién. El sistema completo vive detrás de una capa de acceso (Cloudflare Zero Trust, que restringe la entrada a cuentas de correo específicas), y los nombres de las personas nunca llegan al frontend: una vista de la base de datos expone solo iniciales, mientras la tabla original con datos completos queda protegida por RLS (Row Level Security, permisos que Postgres aplica directamente sobre las filas, no solo sobre quién entra a la aplicación). Acá aprendí, construyendo esto, que la clave pública de una base de datos siempre es visible en el código de cualquier sitio: no importa qué tan bien la escondas, un navegador la descarga junto con todo lo demás. La protección real no está en ocultar la llave, está en que esa llave, aunque alguien la copie, no pueda leer lo que no debe.

Nada de esto salió perfecto a la primera. Un ejemplo pequeño pero típico: la línea de tiempo del mapa dejaba de funcionar porque calculaba las fechas antes de que los datos terminaran de cargar desde la base. La solución no fue optimizar la carga, fue cambiar el orden: calcular las fechas después de que los datos llegaran, no antes. Ese tipo de error, donde el código es correcto pero el momento en que se ejecuta no lo es, es de los más difíciles de detectar y de los más fáciles de evitar una vez que sabes buscarlo.

Lo que me deja este proceso no es la herramienta en sí, sino la evidencia de que se puede construir vigilancia epidemiológica seria sin esperar un presupuesto extraordinario ni una licitación. Se necesita entender el problema de salud pública tan bien como el problema técnico, y no tratarlos como cosas separadas. El dato sin ese entendimiento es solo una tabla más. Con él, es una herramienta que ayuda a decidir dónde tocar la puerta primero.