Confirmación de citas y rescate de lista de espera, multicanal con cascada WhatsApp → SMS → IVR.
Integrado al HIS por el riel FHIR R4 (NID + TEI). Consentimiento Ley 21.719 y cobro por
contacto efectivo (entregado + leído/respondido/atendido).
HIS · mockWhatsApp utility templatecascada con TTLcontacto efectivoconsentimiento 21.719
Citas de hoy y estado de la contactabilidad — en vivo, sobre la base de datos real.
iniciando campaña…
0
Citas de hoy
10 intentos de contacto
4
Contactos efectivos
0% de efectividad
0/0
Con consentimiento
gate Ley 21.719
●
Estado de la campaña
completada
Citas de hoy · cascada de contacto
Hora
Paciente
Canales
Resultado
Acciones
Lista de espera · rescate de cupos
Prioridad
Paciente
Especialidad
P1
tok-101
ESP-PED
P2
tok-102
ESP-PED
Al cancelarse una cita, el cupo se ofrece al primero de la lista por la misma
cascada multicanal.
Contactos efectivos por canal
whatsapp · 2sms · 1voice · 1
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).