PRD — TBS: Sistema de Adherencia al Tratamiento de Tuberculosis

Versión: 1.0
Fecha: 2026-04-05
Estado: En desarrollo (piloto Varela)

1. Contexto y Problema

La tuberculosis (TBC) requiere un tratamiento de 6 meses con medicación diaria. El abandono es frecuente por efectos adversos, estigma social y dificultades de acceso. Cada abandono aumenta el riesgo de contagio, genera resistencia bacteriana y causa daño pulmonar irreversible.

El partido de Varela (Buenos Aires) tiene aproximadamente 4.000 casos bajo seguimiento. El sistema actual de control es manual, lo que dificulta la detección temprana de pacientes en riesgo de abandono.

Hipótesis central: Un sistema de recordatorios automatizados + escalado inteligente ante faltas + evidencia de toma reducirá la tasa de abandono y mejorará los tiempos de intervención de los equipos de salud.

2. Objetivos del Producto

3. Actores (Roles)

3.1 Paciente

• Recibe recordatorio diario por WhatsApp/Telegram
• Confirma la toma con botón, foto o video corto
• Puede ver su racha de adherencia

3.2 Promotor / Agente comunitario

• Supervisa una cartera de pacientes (≤ 50)
• Recibe alertas cuando un paciente falla
• Registra visitas domiciliarias y llamadas
• Usa dashboard para priorizar su trabajo

3.3 Profesional de salud (médico / enfermero)

• Accede al historial de adherencia de sus pacientes
• Ve alertas activas y el historial de intervenciones
• Exporta datos para reportes clínicos

3.4 Administrador del CAPS

• Gestiona el alta de pacientes y promotores
• Configura parámetros del sistema (horarios, tolerancias)
• Accede a métricas agregadas del establecimiento

3.5 Autoridades provinciales

• Vista de métricas agregadas por CAPS / partido
• Exportes CSV para informes oficiales

4. Canales de Comunicación

5. Flujos Principales

5.1 Alta de paciente

1. Médico o admin registra al paciente (nombre, teléfono, fecha de inicio, promotor asignado)
2. El sistema crea el registro de dosis diarias desde la fecha de inicio
3. El paciente recibe mensaje de bienvenida con instrucciones

5.2 Recordatorio y confirmación diaria

1. El scheduler envía recordatorio al horario configurado por paciente (default: 08:00)
2. El paciente responde con:
3. Botón "Tomé" (mínimo, sin evidencia)
4. Video corto subido via link personalizado con token de un solo uso
5. El sistema registra la toma con timestamp, calcula si fue a tiempo o tardía (tolerancia configurable, default: 120 min)
6. Si confirma, se resuelven alertas activas y se actualiza el semáforo a verde

5.3 Escalado ante faltas

Día 0 (sin confirmar)
   └─ Recordatorio al paciente (ya enviado a su hora)

Día 1 sin confirmar
   └─ Alerta tipo "falta_1" → notificación al promotor

Día 3 sin confirmar
   └─ Alerta tipo "falta_3" → escala a médico responsable

Día 7 sin confirmar
   └─ Alerta tipo "abandono_riesgo" → intervención urgente

(Los umbrales son configurables por el admin)

5.4 Verificación de evidencia (video)

1. El sistema genera un token único por dosis con tiempo de expiración
2. El paciente abre el link en el celular y graba un video corto (≥ 3 seg)
3. El backend valida:
4. Duración mínima del video
5. Hash SHA-256 (detecta video duplicado / reutilizado)
6. Timestamp de creación del archivo (no anterior a hoy)
7. GPS (opcional, si el paciente lo autoriza)
8. El sistema asigna un score: ok / sospechoso / fraude
9. Scores sospechosos quedan en cola de revisión manual

6. Dashboard Web

6.1 Vista principal — Lista de pacientes

• Semáforo de estado por paciente:
• 🟢 Verde: tomó hoy
• 🟡 Amarillo: no confirmó aún (dentro de tolerancia)
• 🔴 Rojo: falta confirmada
• Filtros: por promotor, por estado, por semana
• Columnas: nombre, teléfono, promotor, racha actual, última toma, estado

6.2 Vista de paciente individual

• Historial de dosis (calendario con colores)
• Racha actual y mejor racha
• Listado de evidencias con score
• Alertas históricas y su resolución
• Campo de notas clínicas

6.3 Vista de promotores

• Cartera de pacientes por promotor
• Tasa de adherencia promedio de su cartera
• Alertas activas a resolver
• Historial de intervenciones registradas

6.4 Métricas globales (admin / autoridades)

• Tasa de adherencia global del día / semana / mes
• Tiempo promedio de intervención ante alerta
• Costo estimado por mensaje enviado
• Exportación CSV de cualquier reporte

7. Anti-fraude en evidencias

El sistema implementa múltiples capas para detectar intentos de eludir la verificación:

Los pacientes con score sospechoso son marcados en el dashboard para revisión por el promotor. Los de score fraude generan alerta automática.

8. Modelo de Datos

promotores
  id, nombre, telefono, email, telegram_chat_id

pacientes
  id, nombre, telefono, fecha_inicio, promotor_id, activo
  hora_toma, tolerancia_min, notas, telegram_chat_id

dosis
  id, paciente_id, fecha
  recordatorio_enviado, tomada, tomada_at, tomada_tarde
  evidencia

alertas
  id, paciente_id, tipo, creado, resuelta, resuelta_at

tokens_confirmacion
  id, paciente_id, dosis_id, token, fecha, usado, expira_at

evidencias
  id, dosis_id, paciente_id, token
  video_path, duracion_seg, hash_sha256, creation_time_video
  gps_lat, gps_lon, user_agent, ip
  alerta_duplicado, alerta_duracion, alerta_tiempo, alerta_creation_time
  score

9. Pila Tecnológica (actual)

10. MVP — Alcance del Piloto Varela

Incluido en MVP

• [x] Alta y gestión de pacientes y promotores
• [x] Recordatorio diario por WhatsApp/Telegram
• [x] Confirmación con botón "Tomé"
• [x] Confirmación con video + validaciones anti-fraude
• [x] Sistema de alertas con escalado a promotor
• [x] Dashboard con semáforos por paciente
• [x] Vista por promotor con cartera y adherencia
• [x] Autenticación del dashboard (token)

Fuera del MVP (próximas versiones)

• [ ] Gamificación: rachas, metas, recompensas
• [ ] SMS / IVR como fallback
• [ ] Integración con SISA / CAT (notificaciones oficiales)
• [ ] Historia clínica electrónica
• [ ] App móvil nativa (actualmente PWA)
• [ ] Multi-tenant (múltiples CAPS / municipios)
• [ ] Roles diferenciados en el dashboard (admin vs promotor vs médico)
• [ ] Modelo de costos integrado (seguimiento del gasto en mensajes)

11. Riesgos y Mitigaciones

12. Privacidad y Seguridad

• Consentimiento informado obligatorio antes del onboarding
• Videos almacenados localmente en el servidor (no en terceros sin acuerdo)
• GPS solo con consentimiento explícito del paciente
• Autenticación por token HMAC en el dashboard
• HTTPS obligatorio en producción
• Roles de acceso a definir en v2 (actualmente acceso único por contraseña)

13. Criterios de Éxito del Piloto

Al finalizar los primeros 3 meses del piloto:

1. Adherencia ≥ 85% en los pacientes activos del sistema
2. Tiempo a primera alerta ≤ 24h desde la primera falta
3. Adopción ≥ 70% de los pacientes usan el canal digital (no requieren contacto manual)
4. Costo por paciente/mes ≤ umbral acordado con el Ministerio
5. NPS de promotores ≥ 7/10 (el sistema les ahorra trabajo, no se lo suma)

14. Roadmap

Q2 2026 — Piloto Varela
  - Estabilización del MVP
  - Onboarding de primeros 50 pacientes
  - Ajuste de umbrales de alerta y anti-fraude

Q3 2026 — Iteración
  - Gamificación básica (rachas, metas)
  - Roles diferenciados en dashboard
  - SMS como fallback

Q4 2026 — Escala
  - Migración a PostgreSQL
  - Multi-tenant (otros CAPS)
  - Integración SISA/CAT