Cada tarjeta es el dispositivo de un paciente. Al iniciar la campaña verás la cascada desplegarse en
tiempo real: el recordatorio por WhatsApp, el escalamiento a SMS si no hay respuesta, y la llamada IVR
como último recurso — exactamente el mismo motor que corre en producción (mismos handlers que los
webhooks reales). Los bordes adaptados son solo el proveedor (sin cuenta WhatsApp aún) y el HIS
(servidor FHIR R4 embebido).
Pulsa iniciar y observa la conversación de cada paciente actualizarse sola.
iniciando…
✓✓ leído / respondido✓✓ entregado✓ enviadoCascada: WhatsApp → SMS → IVR, escalando por TTL cuando no hay contacto efectivo.
Cómo está hecho — contactlab
Sistema de agendamiento + contactabilidad · prueba de que es real, no un demo (ADR-0025)
Sistema real de agendamiento de citas + contactabilidad de pacientes para salud pública
(caso HLCM). Cubre toda la cadena: una hora nace (web del paciente, recepción por
teléfono/presencial, o inbound WhatsApp), se agenda en un cupo (crea la cita en el HIS por
FHIR R4), se gestiona (reagendar/cancelar/asistió/no-show) y se contacta al paciente
por una cascada multicanal que cobra por contacto efectivo. Todo sobre ports/adapters reales.
Hexagonal (ports/adapters): el dominio nunca conoce FHIR/Meta/Twilio. Corte por capa —
web (request/UI),
cómputo (servicios síncronos),
offline/background (scheduler, seed) y
datos (fuente de verdad). Activar un canal o un HIS real es config,
no código (ADR-0004).
El flujo de negocio end-to-end: de dónde nace una solicitud hasta el contacto efectivo
facturable. La agenda es la bisagra: convierte una solicitud en una cita real del HIS y dispara la
contactabilidad.
Las pantallas y el flujo de datos de la web: cada request arma el estado desde la DB real
(build_state) y lo renderiza; las vistas en
vivo se auto-refrescan con HTMX mientras la cascada corre (sin recargar la página).
La contactabilidad es event-driven, no un loop de demo. Los eventos del proveedor son
durables en scheduled_event; el scheduler
los drena con tick() por los MISMOS
handlers que los webhooks reales; el escalamiento es un scan por TTL. Idempotente y
restart-safe (estado en DB).
El flujo de diseño: un design system por tokens (variables CSS en
base.html) → componentes reutilizables →
las pantallas. Tema oscuro consistente; este mismo panel ⓘ usa los tokens (por eso los diagramas
siguen el tema).