Excepciones: cuándo intervenir manualmente (playbook)

Introducción

Excepciones en recepción clínica son inevitables: datos incompletos, conflictos de agenda o señales de fraude. Aquí verás cuándo pausar el robot y cómo intervenir sin romper la experiencia del paciente. Definimos señales concretas, pasos operativos y el registro mínimo para aprender de cada incidente y mejorar la automatización.

Este artículo te ayuda a decidir cuándo parar el robot y cómo intervenir sin romper la experiencia del paciente. Verás señales concretas, pasos operativos y el registro mínimo para aprender de cada incidente y mejorar la automatización.

Resumen accionable

• Define tipos de excepción por origen (datos, procesos, sistemas, personas) y por severidad (alta, media, baja).
• Usa umbrales objetivos (p. ej., 2 reintentos fallidos + dato crítico ausente) para pausar el robot.
• Activa rutas de escalado claras: recepción → coordinador(a) → soporte TI, con tiempos máximos.
• Implementa controles de idempotencia y logs para no duplicar citas ni mensajes.
• Registra toda excepción con campos mínimos y etiqueta la causa raíz.
• Revisa semanalmente métricas: tasa de interrupción, MTTD/MTTR, repetitividad por regla.
• Documenta procedimientos human-in-the-loop y cierra el bucle con mejoras en reglas/triggers.

Nota: respeta la privacidad y las normativas locales. Esto no es asesoría legal.

Tipos de excepciones

Clasificar bien evita decisiones impulsivas. La categoría debe indicar qué falló, qué riesgo implica y quién debe resolverlo. En recepción clínica, lo más frecuente es que un robot dependa de datos del paciente, de respuestas del EHR (historia clínica electrónica) o de integraciones de agenda. Cuando algo no cumple la regla, hablamos de una excepción. La severidad ayuda a priorizar: alta (riesgo paciente/finanzas/privacidad), media (retrabajo moderado), baja (esperar/reintentar).

Por origen (ejemplos):

• Datos: documento inválido, consentimiento faltante, contacto no verificable.
• Proceso: regla de agenda rota (doble asignación), incompatibilidad de servicio vs. profesional, ventana horaria cerrada.
• Sistemas/Integraciones: API del EHR fuera de servicio, webhook sin respuesta, timeouts repetidos.
• Personas/Excepciones clínicas: paciente vulnerable, nota médica que exige validación, sospecha de suplantación.

Por severidad (guía rápida):

• Alta: riesgo de seguridad del paciente, duplicación de citas críticas, exposición de datos.
• Media: retraso >30 min, cita no confirmada por canal crítico.
• Baja: dato accesorio faltante que puede completarse luego.

Al definir tipos, escribe 2–3 ejemplos reales de tu clínica por categoría. Eso facilita entrenar al equipo y ajustar reglas del robot.

Señales para pausar el robot

Antes de aplicar listas, cada señal debe tener un umbral y una acción asociada. Sin esto, la automatización “oscila” entre reintentar y bloquear, generando más ruido que ayuda. Considera también reintentos con backoff (espaciados crecientes) para eventos transitorios.

Primero, piensa en gatillos/triggers: ¿qué evento dispara una pausa? Segundo, en filtros: ¿se aplica a todos los pacientes o solo a ciertos servicios? Tercero, en acciones: ¿pausa parcial (solo ese flujo) o global (toda la automatización)?

Señales típicas (con umbral sugerido):

• Datos críticos nulos o inconsistentes (documento, teléfono, consentimiento): robot pausa el caso tras 1 validación fallida + 1 reintento.
• Colisión de agenda (doble booking): si fecha_hora_inicio coincide con otra cita del mismo profesional, pausa inmediata y alerta a recepción.
• Integración caída (EHR/API): 2 timeouts consecutivos → mover el caso a cola manual y activar webhook de salud del sistema.
• Validación de identidad fallida (OTP/biometría): 2 intentos fallidos → pausa y verificación humana.
• Reglas clínicas (p. ej., necesidad de orden médica previa): si falta adjunto obligatorio, no confirmar hasta revisión humana.
• Anomalías de comportamiento (picos de cancelaciones desde el mismo número/IP): tasa > umbral en 15 min → throttling y revisión.

Si una señal se repite con frecuencia, revisa la regla: quizá el umbral es demasiado rígido o falta un camino alterno (path) para casos especiales.

Procedimientos de intervención

Un procedimiento claro evita improvisación. Debe indicar quién, qué herramienta, qué valida, qué actualiza y cómo se cierra. Además, contempla idempotencia (que una acción humana no duplique lo que el robot ya hizo) y alertas.

Empieza definiendo tres rutas: (1) sólo recepción, (2) recepción + coordinador(a), (3) recepción + TI. Añade tiempos máximos (SLA) y criterios de escalado.

Diagrama de flujo (simplificado):

[Señal de excepción]
        |
        v
 [Robot pausa caso]
        |
   (auto-chequeos)
        |
¿Datos críticos completos?
     /          \
   Sí            No
   |             |
Reintento   Asignar a recepción
   |             |
¿Éxito?      Validar identidad
 /    \          |
Sí     No        |
 |      \        v
Cerrar   Escalar a coord.
             |
     ¿Requiere TI/sistemas?
          /        \
        Sí          No
        |           |
  Abrir ticket   Resolver y reanudar
        |
   Confirmar cierre

Pasos operativos (plantilla):

1. Recepción valida: identidad, consentimiento, cobertura de servicio, conflictos de agenda.
2. Acción humana única (idempotente): p. ej., crear/editar la cita una sola vez y marcar “resuelto manual”.
3. Actualizar el caso: en el sistema base y en el log de excepciones.
4. Reanudar o cancelar: si procede, cambiar estado del flujo y avisar al paciente (mensaje estandarizado).
5. Etiquetar causa raíz: datos, proceso, sistema o persona; severidad y regla asociada.
6. Cerrar con evidencia: adjunto/nota breve y responsable.

Incluye reintentos seguros: el robot debe comprobar un marcador (flag) “resuelto_manual=true” para no re-aplicar acciones. Configura alertas (email/Slack) solo para severidad alta o para backlogs > umbral, evitando fatiga de alertas.

Registro y aprendizaje continuo

Registrar bien permite mejorar reglas y reducir intervenciones. El objetivo es medir, aprender y ajustar. Minimiza datos sensibles en los logs; registra solo lo necesario para reproducir el incidente.

Campos recomendados (ejemplo para agenda):

id_cita	fecha_hora_inicio (ISO)	zona_horaria	paciente_nombre	paciente_contacto	profesional	servicio	estado	origen_lead	consentimiento
8c9f…	2025-11-04T14:30:00	America/Sao_Paulo	Juan P.	+55…	Dra. Silva	Eco Doppler	pausada	WhatsApp	sí

Añade al log de excepciones: timestamp, regla_disparada, severidad, sistema_afectado, acción_humana, responsable, resultado (reanudado/cancelado), duraciones (MTTD/MTTR). Con esto puedes construir reportes semanales: tasa de excepciones por 100 citas, reglas más “ruidosas” y porcentaje resuelto sin escalado.

Métricas mínimas

• Tasa de interrupción (IR): excepciones/total de casos automatizados.
• MTTD/MTTR: tiempo medio para detectar/resolver.
• % idempotencia fallida: duplicaciones o acciones repetidas.
• % excepciones por tipo/severidad: para priorizar mejoras.

Un buen registro permite retroalimentar el diseño del robot: ajustar triggers, añadir filtros, crear paths alternos y mejorar mensajes al paciente.

Errores comunes

• Pausar el robot sin umbrales claros, generando trabajo manual innecesario.
• No marcar acciones manuales, causando duplicidad o mensajes contradictorios.
• Alertar todo a todo el mundo: fatiga y pérdida de foco.
• No registrar causa raíz, imposibilitando mejoras.
• Depender de una sola persona para cerrar excepciones críticas.

Un cierre disciplinado, con métricas y revisión semanal, transforma excepciones en oportunidades para robustecer la automatización.

Mini-plantilla del playbook (versión resumida)

Propósito: definir cuándo pausar y cómo intervenir.
Ámbito: recepción, agenda, confirmaciones, integraciones EHR.

Criterios de pausa (marca X):

• Dato crítico faltante tras 1 reintento.
• Colisión de agenda detectada.
• 2 timeouts de API consecutivos.
• Identidad no verificada (2 intentos).
• Regla clínica previa no cumplida.

Ruta de escalado:

• Nivel 1: recepción (≤15 min).
• Nivel 2: coordinador(a) (≤30 min, si riesgo medio/alto).
• Nivel 3: TI (ticket, SLA 4 h, solo sistemas caídos).

Acciones idempotentes:

• Actualizar cita una vez y marcar resuelto_manual.
• Notificar al paciente con plantilla estándar.
• Documentar causa raíz y adjuntar evidencia.

Campos de registro obligatorio:
id_cita, fecha_hora_inicio, zona_horaria, paciente_contacto, profesional, servicio, estado, consentimiento, regla_disparada, severidad, responsable, resultado.

FAQ

1) ¿Cómo defino si una señal es de severidad alta?
Cuando involucra seguridad del paciente, privacidad o impacto financiero directo; pausa inmediata y escala.

2) ¿Cuántos reintentos debe hacer el robot?
En general 1–2 con backoff; más de 2 suele indicar problema estructural y debe pasar a humano.

3) ¿Qué es idempotencia en este contexto?
Que si ejecutas la misma acción dos veces (automática o manual), el resultado no genere duplicados ni efectos colaterales.

4) ¿Cómo evitar fatiga de alertas?
Agrupa por incidente, notifica solo severidad alta y establece ventanas silenciosas para series repetidas.

5) ¿Qué pasa si el sistema base está caído?
Desvía todos los casos nuevos a cola manual, comunica al paciente potenciales demoras y activa protocolo TI.