Error 1: Definiciones de caso que no se pueden aplicar sobre el terreno
Una definición de caso solo es útil si un trabajador de salud con cinco minutos por paciente puede aplicarla de manera consistente. La mayoría están redactadas para epidemiólogos que revisan registros, no para agentes comunitarios de salud que hacen triaje de pacientes. El resultado es una clasificación errónea sistemática en el punto de primer contacto.
La solución: Traduzca cada definición de caso a un algoritmo de un máximo de tres preguntas, aplicable en menos de 60 segundos. Pruebe el algoritmo sobre el terreno con trabajadores de salud reales antes de su implementación.
Error 2: Datos de vigilancia que reportan productos, no señales
La vigilancia centrada en los productos pregunta: «¿Cuántos casos se reportaron esta semana?». La vigilancia centrada en las señales pregunta: «¿El patrón de casos de esta semana se desvía de la línea de base esperada de forma que requiera investigación?». La mayoría de las implementaciones de DHIS2 están configuradas para reportar productos sin calcular si ese recuento supera el umbral de alerta para esa enfermedad, en esa localidad, en esa época del año.
La solución: Incorpore umbrales de alerta explícitos al sistema de vigilancia, ya sean recuentos fijos (tres o más casos sospechosos de cólera en un único centro en siete días) o umbrales estadísticos (dos desviaciones estándar por encima de la media estacional). Configure el sistema para que señale automáticamente los cruces de umbral. Consulte DHIS2 Dashboard Best Practices para saber cómo hacer visibles estos umbrales en tiempo real.
Error 3: Notificación cero que no se hace cumplir
Un centro que no reporta no proporciona ninguna información, lo cual, en el agregado, resulta idéntico a cero casos. Un panel estatal que muestra recuentos bajos de casos puede reflejar una transmisión genuinamente baja o un 40% de reportes faltantes. He visto programas declarar una reducción de la carga de enfermedad cuando lo que realmente ocurrió fue que disminuyó la exhaustividad de la notificación.
La solución: Haga cumplir la notificación cero a nivel de centro. Todo centro debe enviar un reporte semanal aunque registre cero en todos los indicadores. Incorpore el seguimiento de la exhaustividad al panel de vigilancia y trate una exhaustividad inferior al 85% como una condición de alerta que exige la misma respuesta que el cruce de un umbral de enfermedad.
Error 4: Capacidad de investigación que no corresponde al volumen de alertas
Un sistema de vigilancia que detecta señales de brote más rápido de lo que el sistema de salud puede responder no acelera el control del brote: acelera el agotamiento del personal. Cuando el volumen de alertas supera la capacidad de investigación, el triaje ocurre de manera informal; con el tiempo, las alertas se reconocen pero no se atienden.
La solución: Mapee la capacidad de investigación antes de implementar o reconfigurar un sistema de vigilancia. Establezca umbrales de alerta que generen un volumen al que el sistema realmente pueda responder. Un sistema con un 95% de especificidad de alerta que genera dos alertas procesables por semana es más útil que uno que genera veinte y desborda al equipo.
Error 5: Vínculos de laboratorio que rompen la cadena de la señal
Las muestras se recolectan durante la investigación. El transporte tarda días. Los resultados tardan días o semanas adicionales. Para cuando llega la confirmación, la ventana de rastreo de contactos ya se ha cerrado y los datos han perdido vigencia operativa. La consecuencia práctica: la mayoría de los casos confirmados en contextos de brote se confirman cuando la respuesta ya está en marcha o ya ha terminado.
La solución: Separe la cadena de la señal de la cadena de confirmación. Diseñe el protocolo de respuesta de manera que un conglomerado de casos sospechosos epidemiológicamente vinculados con una presentación clínica coherente desencadene una respuesta de investigación sin esperar la confirmación de laboratorio. La confirmación de laboratorio valida o revisa la respuesta después; no la inicia.
Error 6: Datos de vigilancia que no se utilizan en la planificación de la respuesta
Las decisiones sobre dónde desplegar recursos y qué distritos priorizar se toman según la intuición del equipo de campo y consideraciones políticas, en lugar de los datos de vigilancia. El panel está abierto en otra pestaña del navegador. Nadie lo consulta.
La solución: Incorpore el panel de vigilancia al proceso de toma de decisiones de forma institucional. Toda reunión de revisión del programa debería comenzar con cinco minutos de revisión del panel. Los documentos de planificación de la respuesta deberían estar obligados a citar los datos de vigilancia específicos que justifican las decisiones de priorización. Este es un cambio de gobernanza, no técnico.
Error 7: Ausencia de un mecanismo de revisión posterior a la acción
Los sistemas de vigilancia que no se revisan después de los brotes no pueden mejorar. La mayoría de los programas realizan revisiones posteriores a la acción (AAR) cuando concluyen brotes importantes; casi ninguno las realiza cuando el sistema de vigilancia no detectó un brote en absoluto, precisamente el escenario donde más aprendizaje se puede obtener.
La solución: Incorpore la revisión posterior a la acción al calendario de vigilancia como una actividad programada y recurrente. Para cada brote o conglomerado que desencadenó una investigación, documente la línea de tiempo completa: primer caso, alerta activada, investigación completada, respuesta iniciada. Haga visible la latencia entre cada etapa. Luego, trabaje sistemáticamente para reducirla.
El hilo conductor común
Cada error de esta lista refleja una versión del mismo problema: un sistema de vigilancia diseñado en torno a la recolección de datos en lugar del apoyo a la toma de decisiones. La pregunta que un sistema de vigilancia debe responder no es «¿cuántos datos recolectamos?». Es «¿con qué rapidez pasamos del primer caso a una respuesta coordinada?». Para un enfoque a nivel de sistemas sobre el diseño de la vigilancia, consulte Integrated Disease Surveillance and Response: A Systems Perspective.
Para la configuración de sistemas digitales de seguimiento de casos que abordan varios de estos errores a nivel de infraestructura, consulte DHIS2 Tracker Configuration for Outbreak Surveillance.