Configuración de DHIS2 Tracker para la vigilancia de brotes

DHIS2 Tracker es una de las herramientas de seguimiento de casos individuales más capaces disponibles para los sistemas de salud nacionales. Implementado correctamente, cierra la brecha entre un caso sospechoso en un establecimiento de atención primaria de salud y una respuesta coordinada a nivel estatal o nacional. Implementado incorrectamente, se convierte en otro sistema que genera informes que nadie lee.

¿Por qué hacer seguimiento y no agregación?

Antes de configurar nada, vale la pena preguntarse si DHIS2 Tracker es siquiera el módulo correcto. DHIS2 tiene dos modelos de datos principales: agregado (datos resumidos periódicos) y tracker (datos longitudinales a nivel individual de casos). Para la notificación rutinaria de vigilancia de enfermedades, el agregado de recuentos semanales de casos por establecimiento es suficiente y mucho más sencillo de gestionar.

Tracker se vuelve necesario cuando necesita:

• Seguir un caso individual a través de múltiples encuentros clínicos

• Registrar los vínculos de rastreo de contactos (caso fuente a contactos)

• Activar alertas automáticas cuando se superan los umbrales de casos

• Desagregar resultados por atributos a nivel individual (edad, sexo, estado de vacunación, historial de viajes)

• Rastrear el estado de investigación y el cierre de cada caso confirmado

Para la vigilancia de brotes específicamente, la capacidad de Tracker para vincular casos con contactos, registrar los cronogramas de investigación y generar informes de casos individuales que alimentan los sistemas nacionales de notificación justifica la inversión adicional en configuración.

Paso 1: Diseño del programa antes de la configuración

El error más común en la implementación de Tracker es abrir DHIS2 y comenzar a construir antes de que el diseño del programa esté completo. Antes de crear un solo elemento de datos, aclare:

• ¿Quién captura qué, y cuándo? Mapee el ciclo de vida del caso desde la identificación del caso sospechoso hasta el cierre del caso. Cada etapa en el flujo de trabajo de investigación se corresponde con una etapa del programa Tracker.

• ¿Qué decisiones deben impulsar los datos? Trabaje hacia atrás desde las decisiones que importan. Si el umbral de alerta es de tres casos en una sola semana en un solo establecimiento, ese umbral debe estar integrado en la lógica del programa, no reportado a un supervisor que decide manualmente.

• ¿Cuál es el conjunto de datos mínimo viable? Las implementaciones de Tracker frecuentemente colapsan bajo la carga de recopilación de datos. Defina el conjunto mínimo de elementos de datos que permite las decisiones requeridas, y resista la tentación de añadir más simplemente porque el sistema lo permite.

Paso 2: Configuración de las etapas del programa

Para la vigilancia de brotes, un programa Tracker bien diseñado normalmente utiliza cuatro etapas:

Etapa 1: Registro de casos y notificación inicial

Captura la información disponible en el primer contacto. Los elementos de datos requeridos incluyen fecha de inicio, fecha de la primera consulta, establecimiento notificante, identificadores del paciente, constelación de síntomas principal y clasificación inicial del caso. Mantenga esta etapa breve: los equipos de campo deberían completarla en menos de cinco minutos. El objetivo es la detección temprana de señales, no la documentación clínica.

Etapa 2: Investigación del caso

La investigación epidemiológica detallada, completada por un funcionario capacitado. Captura el cronograma completo de síntomas, historial de exposición, estado de vacunación, lista de contactos, detalles de la recolección de muestras y resultado clínico al momento de la investigación.

Etapa 3: Resultados de laboratorio

Diseñada para recibir resultados directamente del sistema de información de laboratorio cuando existe integración, o mediante entrada manual cuando no existe. El campo clave es el estado de la muestra (pendiente, recibida, analizada, con resultado), que impulsa la actualización de la clasificación del caso.

Etapa 4: Cierre del caso

Registra la clasificación final, el desenlace (recuperado, fallecido, perdido en el seguimiento) y un resumen narrativo de la investigación. Esta etapa activa la eliminación del caso del panel de vigilancia activa. Ningún caso debería permanecer abierto indefinidamente.

Paso 3: Configuración de elementos de datos

Tres propiedades son las más importantes para la vigilancia: tipo de valor, conjunto de opciones y tipo de agregación.

• Tipos de valor: Use TEXT solo cuando el texto libre sea genuinamente necesario. Prefiera INTEGER, DATE, BOOLEAN u OPTION_SET para todos los datos estructurados. Los campos de texto libre no pueden agregarse, filtrarse ni utilizarse en reglas de programa.

• Conjuntos de opciones: Construya los conjuntos de opciones cuidadosamente y reutilícelos entre programas. Un conjunto de opciones de Clasificación de casos utilizado de manera consistente en cada programa de enfermedades permite el análisis entre enfermedades. Los conjuntos de opciones inconsistentes lo hacen imposible.

• Tipo de agregación: Configure la mayoría de los elementos de datos como COUNT o SUM. Configure NONE para los campos de identificadores que no deberían agregarse.

Paso 4: Reglas de programa para la calidad de datos en el punto de entrada

Las reglas de programa son el mecanismo de DHIS2 para aplicar lógica a nivel de formulario. Para la vigilancia de brotes, no son opcionales. Las reglas de programa esenciales incluyen:

• Lógica de fechas: Evitar que la fecha de inicio se registre después de la fecha de cierre del caso. Evitar que la fecha de investigación se registre antes de la fecha de registro.

• Validación de la definición de caso: Calcular si los síntomas ingresados cumplen con la definición de caso epidemiológico y mostrar el resultado al funcionario que ingresa los datos.

• Cumplimiento de campos obligatorios: Hacer obligatoria la fecha de recolección de la muestra cuando se ingresa el tipo de muestra. Hacer obligatoria la fecha del resultado de laboratorio cuando se ingresa el resultado.

• Alerta de duplicados: Habilitar la detección de duplicados integrada de DHIS2 según coincidencia de nombre, fecha de nacimiento y establecimiento.

Paso 5: Paneles diseñados para la toma de decisiones

Una implementación de DHIS2 sin un panel funcional es un almacén de datos. Para la vigilancia de brotes, el panel principal debería mostrar en tiempo real:

• Recuento de casos activos por distrito: Un mapa temático con casos codificados por colores según densidad

• Flujo del estado de casos: Cuántos casos se encuentran en cada etapa de investigación

• Tiempo hasta la investigación: Promedio de días entre el registro del caso y la finalización de la investigación, por LGA

• Curva epidémica: Casos por fecha de inicio, mostrando la trayectoria de la epidemia

• Indicador de alerta: Distritos que cumplen el umbral de sospecha de brote

Diseñe los paneles para la persona que necesita tomar una decisión a las 7 de la mañana de un lunes, no para la persona que construyó el sistema. Para conocer el marco completo de diseño de paneles, consulte DHIS2 Dashboard Best Practices.

Paso 6: Control de acceso y asignación de unidades organizativas

Los datos de Tracker son identificables individualmente. El acceso debe estar restringido por unidad organizativa y rol de usuario. La estructura recomendada:

• Usuarios a nivel de establecimiento: Pueden registrar casos e ingresar datos de la Etapa 1 únicamente para su propio establecimiento

• Funcionarios de vigilancia de la LGA: Pueden ver todos los casos en su LGA e ingresar datos de la Etapa 2

• Epidemiólogos estatales: Pueden ver todos los casos en todo el estado y acceder a los paneles de curva epidémica

• Funcionarios del programa nacional: Pueden ver datos agregados, pero no pueden acceder a los registros de casos individuales por debajo del nivel estatal.

Paso 7: Consideraciones de implementación en el mundo real

Baja conectividad: Configure y pruebe el modo PWA de DHIS2 Tracker para la captura de datos sin conexión antes de la implementación, no después del primer brote.

Capacitación: Diseñe la capacitación en torno al flujo de trabajo mínimo viable, desde el registro hasta el cierre, y desarrolle competencia en ello antes de introducir mayor complejidad.

Bucles de retroalimentación sobre calidad de datos: Incorpore una revisión mensual de la calidad de los datos en el calendario del programa, que abarque integridad, oportunidad y precisión. Sin un bucle de retroalimentación, la calidad de los datos se deteriora silenciosamente.

Integración con sistemas nacionales: Asegúrese de que los elementos de datos de su programa estatal estén alineados con la jerarquía de la instancia nacional de DHIS2. La desalineación interrumpe el flujo de datos nacional.

La arquitectura es la intervención

La mejora del 40% en la sensibilidad de la vigilancia de la poliomielitis en los programas de la OMS en Nigeria no provino de mejores formularios de recopilación de datos. Provino de rediseñar la arquitectura: el flujo de los datos, los disparadores de acción, los paneles que hicieron visible la información correcta a la persona correcta en el momento correcto. Eso es lo que hace posible DHIS2 Tracker, bien configurado.

Continuar leyendo

• ¿Qué es DHIS2? Una guía en lenguaje sencillo para profesionales de sistemas de salud

• DHIS2 Dashboard Best Practices

• Calidad de datos en DHIS2: Cómo construir sistemas que produzcan datos confiables

• Vigilancia y respuesta integradas de enfermedades: una perspectiva sistémica

Preguntas frecuentes

¿Para qué se utiliza DHIS2 Tracker?

DHIS2 Tracker se utiliza para el seguimiento de casos a nivel individual, el rastreo de contactos y el seguimiento longitudinal en los programas de salud. A diferencia de la notificación agregada de DHIS2, que recopila recuentos resumidos periódicos por establecimiento, Tracker registra datos de cada paciente individual a través de múltiples encuentros clínicos. Se utiliza para la vigilancia de brotes, el seguimiento de la inmunización, el manejo de casos de VIH y cualquier programa donde los datos a nivel individual impulsen decisiones clínicas o de salud pública.

¿Cuál es la diferencia entre DHIS2 agregado y Tracker?

DHIS2 agregado recopila datos resumidos: cuántos casos se notificaron en un establecimiento en una semana determinada. DHIS2 Tracker recopila datos de casos individuales: el paciente específico, su cronograma de investigación, resultados de laboratorio, contactos y desenlace. El agregado es más sencillo de configurar y suficiente para la notificación rutinaria de vigilancia. Tracker es apropiado cuando necesita seguir un caso a través de múltiples encuentros, vincular casos con contactos o desagregar resultados por atributos a nivel individual.

¿Cómo se configuran las etapas del programa en DHIS2 Tracker?

Las etapas del programa representan pasos en el ciclo de vida del caso. Para la vigilancia de brotes, una configuración estándar utiliza cuatro etapas: registro de casos y notificación inicial, investigación del caso, resultados de laboratorio y cierre del caso. Cada etapa contiene los elementos de datos mínimos necesarios para ese paso, reglas de programa que garantizan la calidad de los datos en el ingreso, y controles de acceso que restringen quién puede ingresar o ver datos en cada etapa.

¿Qué son las reglas de programa de DHIS2?

Las reglas de programa de DHIS2 aplican lógica en el punto de ingreso de datos. Pueden mostrar u ocultar campos según valores previamente ingresados, calcular resultados automáticamente, exigir campos obligatorios de manera condicional, mostrar advertencias cuando las entradas parecen inconsistentes, y activar alertas cuando se cumplen las definiciones de caso. Para la vigilancia de brotes, las reglas de programa aplican la lógica de fechas, validan las definiciones de casos y previenen los problemas de calidad de datos que se acumulan cuando los datos se recopilan bajo presión operativa.