Confirmación de citas y rescate de lista de espera, multicanal con cascada WhatsApp, SMS e 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
0 intentos de contacto
0
Contactos efectivos
0% de efectividad
0/0
Con consentimiento
gate Ley 21.719
lista para iniciar
Estado de la campaña
pulsa iniciar campaña
Citas de hoy · cascada de contacto
Hora
Paciente
Canales
Resultado
Acciones
Lista de espera · rescate de cupos
Prioridad
Paciente
Especialidad
P1
tok-101
Pediatría
P2
tok-102
Pediatría
Al cancelarse una cita, el cupo se ofrece al primero de la lista por la misma
cascada multicanal.
Contactos efectivos por canal
Aún sin contactos efectivos.
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).