Presentación Técnica DKV

# 🧑‍💻 DKV PET Flows
## Evaluación Técnica MVP: Dinamización

*Presentación de Viabilidad para Equipo de Arquitectura y Core*
<!-- slide -->
### 🧪 Diagnóstico del Core Actual (Spike Result)

Tras investigar el código en `netcomp` (Erlang) y `pet-cloud` (Java), analizamos el ciclo de vida de inactividad de un paciente en una cola hoy:

1. **`max_inactive_patient_warning_time` (TMIPW)**: Dispara en `dkv_telemed_dtm.erl` un Push notification hardcodeado de tipo `encounter_inactive` (Un único aviso rígido).
2. **`max_inactive_patient_time` (TMIP)**: Dispara el cierre incondicional inyectando un mensaje de sistema.

Ambos eventos generan mensajes en la conversación, **lo que inherentemente acciona el `webhook_new_message_recipients`** en formato JSON puro enviando la foto de la entidad en ambos lenguajes.
<!-- slide -->
### 🤔 El dilema: "¿Y si metemos otro timeout en el Admin/Netcomp?"

Alguien podría proponer la vía tradicional: *Añadamos campos en la tabla Queue (`inactive_reminder_1`, `inactive_reminder_2`) y que el backend de PET (Erlang/Java) se encargue.*

**¿Por qué es una mala idea en este momento del proyecto?**
1. **Doble Esfuerzo (Leader/Follower)**: Implica modificar la BD y el backend no solo en Erlang, sino replicar el modelo en Java para que la sincronización vía RabbitMQ no falle.
2. **Deuda Técnica de UI**: Modificar React (`dkv-pet-admin`) para soportar *enésimos* campos de timeout no escalables.
3. **Peligro en Vuelo**: Tocar `dkv_telemed_dtm.erl` a tan solo 2 meses del GoLive de `pet-cloud` introduce un riesgo brutal en la pieza más crítica de estado del sistema.
<!-- slide -->
### 🛡️ La Solución Arquitectónica "Zero-Erlang-Touch"

Dado que:
A) Pet-cloud ya implementa `webhook_new_message_recipients` (lo verificamos en `TelemedExtCallback.java`).
B) El payload del webhook incluye siempre la instantánea viva: `{"encounter": {...}}`.

**Nuestra propuesta invierte el modelo de control:**
1. Desactivar los timers nativos en el Admin (`close_inactive_encounters` a `false`, tiempos a `0`) para las colas de Continuidad seleccionadas.
2. Dejar que **Pet Flows (Quarkus/Dapr)** consuma el torrente de webhooks puros.
3. El uso de **Dapr Timers** dentro de Pet Flows creará relojes distribuidos. 
<!-- slide -->
### ⏱️ El Ciclo de Dapr (Pet Flows)

```mermaid
sequenceDiagram
    participant PC as PET Cloud (Core)
    participant PF as Pet Flows (Dapr)
    participant N as dkv-notifications

    PC->>PF: POST Webhook (Nuevo Mensaje de Doctor)
    Note over PF: Despierta: Resetea Timer Inactividad
    PF->>PF: Programa Dapr Timer (T+24h)

    alt Paciente Responde (T+1h)
        PC->>PF: POST Webhook (Nuevo Mensaje Paciente)
        Note over PF: Despierta: Resetea Timer
    else Pasa el tiempo (T+24h)
        Note over PF: Timer Expira
        PF->>N: Enviar PUSH "Tu doctor te espera"
        PF->>PF: Programa Dapr Timer (T+48h)
    end

    Note over PF: Timer (T+48h) Expira
    PF->>PC: REST POST /encounters/{id}/close
```
<!-- slide -->
### ✅ Viabilidad 100% Confirmada

- **Cero cambios** de esquema en Postgres/Elasticsearch.
- **Cero cambios** en Erlang / Java Core.
- Despliegue de lógica de negocio transferible y orquestada por Dapr (que implementa mecanismos nativos de resiliencia, State Store, y Pub/Sub).
- Reutilización al 90% de la infraestructura que ya estamos montando para el **MVP Backlog (Encuestas)**.

**Conclusión:** Podemos cumplir el requerimiento funcional íntegramente delegando la orquestación en la plataforma que estamos construyendo expresamente para este propósito.