# SALUD 365

## Módulo 14 · Notificaciones por WhatsApp

**Última actualización:** 14 de noviembre de 2026.

Documento funcional para validación con usuarios. Se presentan comportamientos esperados y reglas en lenguaje claro, sin códigos de trazabilidad técnica.

### Contexto funcional vigente

- El MVP se desarrolla en plataforma web. Salud 365 presenta la experiencia del usuario y coordina las operaciones; Elite Global Doctors (EGD) es el core clínico. Las capacidades concretas de sus servicios e interfaces aún requieren validación técnica.

- El titular que contrata y paga puede ser distinto del paciente; los pacientes dependientes deben estar vinculados y autorizados. Los usuarios, pacientes y médicos requieren registro y correspondencia de identidad entre Salud 365 y EGD.

- EGD entrega la solución de videoconsulta para integrarla en Salud 365 y envía por WhatsApp el enlace al paciente y al médico. Terminar la llamada no significa cerrar el acto médico: el profesional puede retomar una atención pendiente.

### Descripción funcional y procesos

Especificación Funcional Detallada

### Objetivo y alcance

Definir las notificaciones relacionadas con las citas y videoconsultas, sus destinatarios, eventos, contenidos mínimos, responsabilidades, seguridad y manejo de incidencias. Para el MVP, está confirmado que EGD enviará por WhatsApp al paciente y al médico asignado la notificación de la cita con el enlace de videoconsulta. Otros eventos y canales son propuestas pendientes de aprobación.

### Decisiones y límites del alcance

- CONFIRMADO: EGD notifica por WhatsApp al paciente y al médico asignado la cita, incluyendo el enlace de videoconsulta.

- CONFIRMADO: la videoconsulta de EGD estará embebida en el frontend web de Salud 365 cuando el acceso se realice desde la plataforma.

- CONFIRMADO: el TITULAR puede seleccionar un paciente asociado y acceder a su cita/videoconsulta desde su propia sesión de Salud 365.

- CONFIRMADO: el pago por Izipay precede al agendamiento en EGD; una aprobación de pago no equivale a cita confirmada.

### Actores y responsabilidades

### Flujo confirmado de referencia

1. El TITULAR selecciona servicio y paciente, acepta el consentimiento y paga mediante Izipay.

2. Salud 365 confirma el pago y solicita a EGD el agendamiento o asignación médica.

3. EGD confirma la cita y proporciona su identificador y enlace de videoconsulta.

4. EGD envía por WhatsApp al paciente y al médico asignado la notificación de la cita con el enlace.

5. Desde Salud 365, el TITULAR consulta las citas del paciente asociado y abre la videoconsulta de EGD embebida en el frontend.

6. El paciente y el médico pueden recibir el enlace por WhatsApp; las reglas de autenticación y apertura externa deben precisarse con EGD.

### Notificación de confirmación de cita por EGD

**Estado** Confirmado funcionalmente

**Objetivo** Garantizar que, tras la confirmación de una cita en EGD, se envíe una notificación WhatsApp al paciente y al médico asignado:

**Actores** EGD, Salud 365, PACIENTE, MÉDICO; TITULAR y ADMINISTRADOR cuando aplique:

**Precondiciones** Cita identificada y operación autorizada; datos de contacto disponibles según evento:

**Flujo principal** EGD confirma la cita, identifica destinatarios y envía los mensajes con fecha, hora y enlace de videoconsulta:

**Ejemplo práctico** Una cita programada queda confirmada y EGD envía el enlace a ambos participantes:

**Diferencia respecto a otros requerimientos** Es el evento principal confirmado; los recordatorios y cambios posteriores son otros eventos por definir:

**Validaciones y reglas** No enviar confirmación de cita únicamente porque Izipay aprobó el pago; debe existir confirmación real de EGD:

**Alternativas y excepciones** Si el envío falla, conservar la cita y registrar el resultado si EGD lo expone:

**Integraciones y datos** EGD, identificadores de paciente/médico/cita, teléfonos, enlace, evento y estados de envío disponibles:

**Criterios de aceptación** Paciente y médico reciben mensajes asociados a la cita confirmada, según la capacidad de entrega del canal:

### Determinación de destinatarios y teléfonos

**Estado** Confirmado funcionalmente

**Objetivo** Establecer cómo EGD obtiene el teléfono WhatsApp del paciente y del médico de cada cita:

**Actores** EGD, Salud 365, PACIENTE, MÉDICO; TITULAR y ADMINISTRADOR cuando aplique:

**Precondiciones** Cita identificada y operación autorizada; datos de contacto disponibles según evento:

**Flujo principal** Salud 365 sincroniza los datos requeridos; EGD identifica el paciente y el médico asignado y utiliza sus teléfonos registrados:

**Ejemplo práctico** Un TITULAR paga por su dependiente; el WhatsApp del paciente es el destinatario confirmado, no necesariamente el del TITULAR:

**Diferencia respecto a otros requerimientos** Distingue destinatarios de contenido; no presupone que el TITULAR reciba copia:

**Validaciones y reglas** Validar correspondencia paciente–teléfono y médico–teléfono; no divulgar enlaces a números de terceros:

**Alternativas y excepciones** Número faltante, inválido o no apto para WhatsApp: registrar incidencia según mecanismo disponible.

**Integraciones y datos** EGD, identificadores de paciente/médico/cita, teléfonos, enlace, evento y estados de envío disponibles:

**Criterios de aceptación** Cada mensaje se dirige al destinatario correcto de la cita:

### Contenido mínimo y enlace de videoconsulta

**Estado** Confirmado funcionalmente

**Objetivo** Definir los datos de la cita que se incluirán en los mensajes WhatsApp:

**Actores** EGD, Salud 365, PACIENTE, MÉDICO; TITULAR y ADMINISTRADOR cuando aplique:

**Precondiciones** Cita identificada y operación autorizada; datos de contacto disponibles según evento:

**Flujo principal** EGD construye el mensaje con identificación apropiada, fecha/hora, referencia de cita y enlace individual o autorizado, según su mecanismo:

**Ejemplo práctico** El paciente recibe un mensaje con la fecha de su consulta y un enlace para ingresar:

**Diferencia respecto a otros requerimientos** Define el contenido; define cuándo se envía:

**Validaciones y reglas** Evitar diagnósticos y otra información clínica sensible en mensajes; proteger enlaces y tokens:

**Alternativas y excepciones** Enlace ausente o inválido: no informar una sala utilizable sin respaldo; registrar incidencia.

**Integraciones y datos** EGD, identificadores de paciente/médico/cita, teléfonos, enlace, evento y estados de envío disponibles:

**Criterios de aceptación** Los mensajes incluyen enlace correspondiente a la cita y no revelan información clínica innecesaria:

### Acceso desde WhatsApp y desde Salud 365

**Estado** Confirmado funcionalmente

**Objetivo** Asegurar coherencia entre el enlace comunicado y la videoconsulta embebida:

**Actores** EGD, Salud 365, PACIENTE, MÉDICO; TITULAR y ADMINISTRADOR cuando aplique:

**Precondiciones** Cita identificada y operación autorizada; datos de contacto disponibles según evento:

**Flujo principal** Salud 365 presenta el acceso embebido al TITULAR autorizado; EGD controla el comportamiento de apertura del enlace desde WhatsApp:

**Ejemplo práctico** El TITULAR abre la sala desde Mis citas, mientras el médico usa el enlace recibido por WhatsApp:

**Diferencia respecto a otros requerimientos** No confundir el enlace de notificación con el componente embebido del frontend:

**Validaciones y reglas** El acceso desde Salud 365 valida la asociación paciente–TITULAR; el enlace externo requiere controles técnicos de EGD:

**Alternativas y excepciones** Sesión vencida, enlace revocado o error de autenticación: mostrar incidencia y vía de soporte.

**Integraciones y datos** EGD, identificadores de paciente/médico/cita, teléfonos, enlace, evento y estados de envío disponibles:

**Criterios de aceptación** Ambas vías apuntan a la cita correcta sin conceder acceso a personas ajenas:

### Recordatorios previos a la cita

**Estado** Propuesto para validación funcional y técnica

**Objetivo** Definir posibles avisos adicionales antes de la atención, sin asumir su inclusión automática en el MVP:

**Actores** EGD, Salud 365, PACIENTE, MÉDICO; TITULAR y ADMINISTRADOR cuando aplique:

**Precondiciones** Cita identificada y operación autorizada; datos de contacto disponibles según evento:

**Flujo principal** Si se aprueba, el sistema responsable programa recordatorios según fecha y hora de cita y evita mensajes después de una cancelación:

**Ejemplo práctico** Un recordatorio se envía antes de la cita, si Salud 365 aprueba ese evento:

**Diferencia respecto a otros requerimientos** Es una propuesta distinta de la confirmación inicial, que sí está acordada:

**Validaciones y reglas** Frecuencia, anticipación y destinatarios deben aprobarse para evitar mensajes excesivos o duplicados:

**Alternativas y excepciones** Cita reagendada: recalcular el recordatorio conforme a la fecha vigente.

**Integraciones y datos** EGD, identificadores de paciente/médico/cita, teléfonos, enlace, evento y estados de envío disponibles:

**Criterios de aceptación** Si se aprueba, el recordatorio corresponde a la cita vigente y al destinatario correcto:

### Avisos por cancelación o reagendamiento

**Estado** Propuesto para validación funcional y técnica

**Objetivo** Definir el tratamiento de cambios de cita y de enlaces anteriores:

**Actores** EGD, Salud 365, PACIENTE, MÉDICO; TITULAR y ADMINISTRADOR cuando aplique:

**Precondiciones** Cita identificada y operación autorizada; datos de contacto disponibles según evento:

**Flujo principal** Si se aprueba el evento, EGD o el componente acordado emite un aviso después de confirmar el cambio; se comunica la información vigente:

**Ejemplo práctico** Una cita cambia de horario y se notifica la nueva fecha con el enlace válido:

**Diferencia respecto a otros requerimientos** Difiere del registro de cancelación/reagendamiento del Módulo 04: aquí solo se comunica el resultado.

**Validaciones y reglas** No avisar un cambio antes de la confirmación confiable de EGD; invalidar enlaces antiguos según capacidad técnica:

**Alternativas y excepciones** Cambio rechazado por EGD: no enviar mensaje de éxito.

**Integraciones y datos** EGD, identificadores de paciente/médico/cita, teléfonos, enlace, evento y estados de envío disponibles:

**Criterios de aceptación** Si el evento se aprueba, no se comunica una fecha o sala desactualizada:

### Seguimiento del estado de notificación

**Estado** Propuesto para validación funcional y técnica

**Objetivo** Permitir conocer si EGD intentó enviar un mensaje y qué resultado reporta, cuando exista capacidad técnica:

**Actores** EGD, Salud 365, PACIENTE, MÉDICO; TITULAR y ADMINISTRADOR cuando aplique:

**Precondiciones** Cita identificada y operación autorizada; datos de contacto disponibles según evento:

**Flujo principal** Salud 365 recibe o consulta el estado disponible de envío y lo vincula con el ID de cita y destinatario:

**Ejemplo práctico** Un administrador verifica si el mensaje al médico fue enviado o falló:

**Diferencia respecto a otros requerimientos** Es observabilidad; no modifica la cita ni garantiza lectura del mensaje:

**Validaciones y reglas** Diferenciar generado, enviado, entregado, leído y fallido solo si el proveedor informa esos estados:

**Alternativas y excepciones** Sin API de seguimiento: registrar limitación sin inventar un estado Entregado.

**Integraciones y datos** EGD, identificadores de paciente/médico/cita, teléfonos, enlace, evento y estados de envío disponibles:

**Criterios de aceptación** Los estados mostrados reflejan evidencias efectivas de EGD:

### Gestión de fallos y reintentos

**Estado** Propuesto para validación funcional y técnica

**Objetivo** Definir qué hacer cuando una notificación no se entrega o su resultado es incierto:

**Actores** EGD, Salud 365, PACIENTE, MÉDICO; TITULAR y ADMINISTRADOR cuando aplique:

**Precondiciones** Cita identificada y operación autorizada; datos de contacto disponibles según evento:

**Flujo principal** Se identifica la incidencia, se consulta el resultado previo y se reintenta únicamente conforme a la política y capacidades aprobadas:

**Ejemplo práctico** EGD confirma la cita pero falla el WhatsApp; la cita permanece confirmada y se gestiona el aviso:

**Diferencia respecto a otros requerimientos** Es contingencia del mensaje, no reversión automática de pago o agendamiento:

**Validaciones y reglas** Evitar reenvíos duplicados, reintentos infinitos y exposición de datos en logs:

**Alternativas y excepciones** Timeout de envío: verificar antes de reenviar si el mecanismo lo permite.

**Integraciones y datos** EGD, identificadores de paciente/médico/cita, teléfonos, enlace, evento y estados de envío disponibles:

**Criterios de aceptación** Una falla de WhatsApp no cambia indebidamente el estado de la cita:

### Configuración de plantillas y parámetros

**Estado** Propuesto para validación funcional y técnica

**Objetivo** Definir quién mantiene mensajes, variables, remitente y políticas del canal:

**Actores** EGD, Salud 365, PACIENTE, MÉDICO; TITULAR y ADMINISTRADOR cuando aplique:

**Precondiciones** Cita identificada y operación autorizada; datos de contacto disponibles según evento:

**Flujo principal** El administrador autorizado consulta o gestiona los parámetros que Salud 365 controle; lo administrado por EGD queda bajo sus procedimientos:

**Ejemplo práctico** Se modifica una plantilla para corregir el texto del enlace o la zona horaria:

**Diferencia respecto a otros requerimientos** Es configuración operativa; no es envío de mensajes ni gestión de citas:

**Validaciones y reglas** Cambios sujetos a permisos, revisión y registro de auditoría:

**Alternativas y excepciones** Plantilla no aprobada o parámetro inválido: impedir publicación según controles acordados.

**Integraciones y datos** EGD, identificadores de paciente/médico/cita, teléfonos, enlace, evento y estados de envío disponibles:

**Criterios de aceptación** Las plantillas vigentes son identificables y no exponen información clínica innecesaria:

### Auditoría, privacidad y reportes básicos

**Estado** Propuesto para validación funcional y técnica

**Objetivo** Definir trazabilidad de eventos de notificación y métricas operativas sin exponer datos clínicos:

**Actores** EGD, Salud 365, PACIENTE, MÉDICO; TITULAR y ADMINISTRADOR cuando aplique:

**Precondiciones** Cita identificada y operación autorizada; datos de contacto disponibles según evento:

**Flujo principal** Se registran identificadores de cita, evento, destinatario referencial, fechas y resultados disponibles; se consultan reportes autorizados:

**Ejemplo práctico** El administrador identifica cuántas confirmaciones tuvieron errores en un periodo:

**Diferencia respecto a otros requerimientos** Es control transversal de seguridad y supervisión, no un nuevo canal:

**Validaciones y reglas** Restringir acceso, minimizar datos personales y proteger números y enlaces:

**Alternativas y excepciones** Sin métricas EGD: mostrar únicamente información verificada por Salud 365.

**Integraciones y datos** EGD, identificadores de paciente/médico/cita, teléfonos, enlace, evento y estados de envío disponibles:

**Criterios de aceptación** Las incidencias pueden rastrearse por cita y evento sin exponer el contenido clínico:

La notificación de confirmación por EGD al paciente y médico, con enlace de videoconsulta, está confirmada como requisito funcional. El resto de eventos y las operaciones técnicas permanecerán pendientes hasta acordar con Salud 365 y EGD su alcance, interfaces, seguridad, responsables y pruebas. No debe interpretarse que una capacidad de API existe hasta que EGD la documente o demuestre.