Cada solicitud pendiente se agenda eligiendo un cupo disponible. Al agendar se crea la cita en el HIS
(FHIR Appointment), se registra el consentimiento y arranca la contactabilidad
(recordatorio multicanal) para esa cita.
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).