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. Es 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 e IVR, escalando por TTL cuando no hay contacto efectivo.
Cómo está hecho — Atria Salud
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).