AS-IS · Agendamiento

AS-IS — Agendamiento

1. Resumen ejecutivo

Agendamiento es el intake clínico de Workmed: convierte una solicitud externa del cliente (correo + Excel, carga directa o autoagenda) en una Orden de Servicio (OS) confirmada en FlowMed, con correos automáticos al solicitante y al trabajador, y el ticket en HubSpot pasado a "agenda confirmada" [Agendamiento-20260413 2:00, 35:01, 37:53]. La frontera de salida es estricta: OS confirmada en FlowMed; lo que ocurra desde la admisión presencial en adelante es Operaciones de campo [Operaciones-20260407 23:58, 35:42]. El proceso lo dirige Patricia Maturana, única autorizada a modificar el módulo Agendamiento en FlowMed [Flowmed-20260409 10:51, 11:15]. Dolores principales: el 98% del trabajo se hace copiando y pegando a mano porque FlowMed sólo lee bien ~2% de los formularios [Agendamiento-20260413 16:08, 29:52]; HubSpot y FlowMed no están integrados desde 2024 [Agendamiento-20260413 47:19, 47:48]; soporte FlowMed (Secall) responde entre 2 semanas y "nunca" [Agendamiento-20260413 27:58]; un error de RUT, sucursal o cargo viaja hasta facturación, y allí el ciclo EDP de 5 días por iteración con el cliente multiplica el daño [Agendamiento-20260413 1:09:21, 1:09:45].

2. Lógica de Negocio

2.1 Propósito y resultado esperado

Recibir solicitudes de evaluación preocupacional de empresas cliente y dejarlas como OS confirmada en FlowMed, con datos limpios (RUT válido, sucursal, fecha, batería, nómina, faena, centro de costo, cargo) y con notificación automática al solicitante (resumen) y al trabajador (día/hora/dirección + link de admisión + credenciales) [Agendamiento-20260413 6:45, 35:01, 35:58, 36:57]. Esa salida cierra el intake; toda actividad clínica posterior es Operaciones [Operaciones-20260407 23:30, 35:42].

2.2 Actores y responsabilidades

• Patricia Maturana ("Paty"), jefa de Agendamiento. Conduce el equipo, agenda casos directamente, escala a soporte FlowMed y es la única autorizada a modificar el módulo Agendamiento en FlowMed (formularios, prestaciones, masificación) [Agendamiento-20260413 0:04, 39:49, 49:35; Flowmed-20260409 10:51, 11:15].
• Equipo de Agendamiento (3 titulares + 2 a honorarios por hora). Se autoasignan tickets en HubSpot, validan campos del Excel y cargan en FlowMed; una persona a honorarios cubre turno hasta las 22:00 [Agendamiento-20260413 39:49].
• Eduardo González, Subgerente de Proyectos y Transformación Digital. Dueño funcional/de Gobierno TI del FlowMed completo; coordina los requerimientos al partner Secall; mide el % de admisión digital [Flowmed-20260409 7:03, 8:32, 12:13; Agendamiento-20260413 37:26]. (Ver §2.5 sobre el matiz "dueño funcional FlowMed" vs "dueña del módulo Agendamiento".)
• Soporte interno Workmed. Carga los nuevos formularios al lector automático de FlowMed [Agendamiento-20260413 27:02].
• Ejecutivos comerciales. Comunican a clientes la versión actualizada del formulario [Agendamiento-20260413 29:00].
• Equipo de admisión en sucursales. Actúa como segundo filtro de errores en el día de atención; no usa HubSpot [Agendamiento-20260413 1:03:42, 1:06:05, 1:06:33].
• Contraloría Médica. Tercer filtro; cuando un error llega acá ya no se puede corregir porque el paciente fue atendido [Agendamiento-20260413 1:03:15, 1:03:42].
• Soporte FlowMed (proveedor Secall). Incorpora nuevos formularios al motor de lectura automática; los tiempos de respuesta van de 2 semanas a "nunca" [Agendamiento-20260413 27:30, 27:58].
• Cliente (con autoagenda). Un cliente designado entra a FlowMed con su propio usuario y crea solicitudes directamente; uno lo tiene operativo, otro lleva 8 meses en standby [Agendamiento-20260413 49:35, 52:57].

2.3 Sistemas e integraciones involucrados

• FlowMed (módulo Agendamiento). SaaS core de Workmed donde se crea la solicitud, se carga la nómina, se asigna la hora y se gatillan los correos al solicitante y al trabajador [Agendamiento-20260413 14:55, 35:01; Flowmed-20260409 4:48, 5:15].
• HubSpot (CRM). Cola "agenda por confirmar"; cada correo del cliente entra como ticket [Agendamiento-20260413 2:00, 2:29].
• Excel (formulario del cliente). Formulario global más formularios especiales por cliente (varios con listas desplegables de centros de costo; ASAP con baterías acotadas; un cliente con baterías numeradas 1-60); muchas veces trae una hoja resumen que el equipo aprovecha como atajo [Agendamiento-20260413 4:11, 15:25, 30:19, 30:48, 57:35].
• Outlook / correo (agendamiento@workmed). Canal de entrada que aterriza en HubSpot; Patricia trabaja con dos pantallas (formulario en una, sistema en la otra) [Agendamiento-20260413 24:18; Flowmed-20260409 25:08].
• Rectificador del Servicio de Registro Civil (Chile). Herramienta web para validar o rectificar RUT por nombre; tiene acceso bloqueado desde Workmed; el equipo usa páginas alternativas que también se bloquean por uso intensivo [Agendamiento-20260413 8:26, 8:56, 9:24].
• Sin integración HubSpot ↔ FlowMed. El intento 2024 fracasó ("las dos partes técnicas no llegaron a acuerdo") y quedó manual de forma indefinida [Agendamiento-20260413 47:19, 47:48].
• Aguas abajo (fuera de la frontera, citado para trazabilidad): SACMed (HIS) [Flowmed-20260409 5:15], SharePoint (centros acreditados) [Agendamiento-20260413 1:07:27, 1:07:57], Defontana (ERP/EDP) [Agendamiento-20260413 1:10:14].

2.4 Reglas de negocio críticas (RN-01..RN-09)

• RN-01 — Una sola autoridad funcional para el módulo Agendamiento. Sólo Patricia Maturana puede modificar el módulo de Agendamiento en FlowMed (formularios, prestaciones, masificación) [Flowmed-20260409 10:51, 11:15].
• RN-02 — Campos obligatorios en la solicitud. Una solicitud no se carga sin: empresa identificada, baterías marcadas, nombre, RUT, centro de costo, faena y responsable de la solicitud [Agendamiento-20260413 5:03, 6:45].
• RN-03 — El cargo del trabajador es legalmente obligatorio. Sin cargo, Contraloría no puede emitir el informe; si Agendamiento no lo capturó, ya no se recupera en admisión porque el propio trabajador no lo sabe [Agendamiento-20260413 1:12:30].
• RN-04 — Asignación de hora según batería. Si la solicitud incluye exámenes de sangre, se asigna la primera hora disponible [Agendamiento-20260413 19:24, 19:53].
• RN-05 — Trazabilidad del ticket en HubSpot. Tras confirmar la OS en FlowMed, la ejecutiva vuelve a HubSpot, cambia el estado a "agenda confirmada" y agrega el número de solicitud al asunto del ticket [Agendamiento-20260413 20:23, 37:53].
• RN-06 — Notificación automática post-confirmación. Al confirmar la solicitud, FlowMed envía automáticamente un correo al solicitante (con resumen) y otro al trabajador (con día/hora/dirección + link de admisión + usuario y contraseña) [Agendamiento-20260413 35:01, 35:58, 36:57].
• RN-07 — Restricción de 3 correos por solicitud. FlowMed acepta como máximo 3 correos por solicitud, separados por coma; si el cliente envía 4, la ejecutiva debe borrar uno antes de cargar [Agendamiento-20260413 4:34, 8:08, 8:26].
• RN-08 — Carga masiva "todo o nada". Si un registro de la nómina falla, ninguno se carga [Agendamiento-20260413 22:25].
• RN-09 — Auto-asignación de tickets. Cada correo entrante en HubSpot genera un ticket en la columna "agenda por confirmar"; una ejecutiva se auto-asigna colocando su nombre antes de operar [Agendamiento-20260413 2:00, 2:29, 2:50].

2.5 Excepciones y casos borde

• Persona postulando a múltiples empresas (sin MPI): un mismo trabajador llega a hacerse exámenes por 2-3 empresas en paralelo; Agendamiento evalúa por cada empresa por separado y no detecta duplicado [Agendamiento-20260413 10:50, 11:20].
• Mismo RUT pero nombres distintos en sistema: el cliente envía un RUT con nombre "Juanito Pérez", FlowMed lo tiene como "Juan Mendoza" porque ya se atendió antes; se asume que el cliente "traspapeló los números" — resolución manual [Agendamiento-20260413 12:39, 13:04].
• Cliente envía 4 correos cuando el sistema acepta 3: la ejecutiva elimina el último antes de cargar [Agendamiento-20260413 4:34].
• Sistema asigna sucursal al azar cuando hay muchos centros de atención mezclados en una sola solicitud [Agendamiento-20260413 22:52, 23:22].
• Carga simultánea por dos ejecutivas para la misma empresa: FlowMed mezcla las solicitudes [Agendamiento-20260413 42:07].
• Lectura automática falla con formularios antiguos: versiones viejas tienen sustancias agrupadas; las versiones nuevas separan saliva/orina por sustancia y sí se leen [Agendamiento-20260413 25:49, 26:08, 26:35].
• RUTs con cero adelante (ej. cliente IST): Excel los acepta y FlowMed no quita el cero, generando informe con RUT mal digitado [Operaciones-20260407 26:12, 26:38].
• Versionado de formularios fuera de control: clientes "porfiados" siguen usando versiones antiguas; no hay documentación oficial publicada en web [Agendamiento-20260413 29:00, 29:21, 31:41].
• Validación de RUT inexistente en carga masiva: "si vienen con los RUT malos, los carga igual, porque nadie revisa"; no se aplican reglas estrictas porque hay DNI y pasaportes mezclados [Flowmed-20260409 6:41, 7:03].
• Cambio de versión por el cliente sin aviso: Syncore mandó con otra versión del formulario y se perdió centro de costo y faena de todas las prestaciones [Flowmed-20260409 15:51].
• Bug histórico (resuelto hace ~4 meses): modificar la sucursal en cabecera del Excel hacía que FlowMed cambiara todas las sucursales internas a la sucursal de cabecera [Agendamiento-20260413 43:04, 44:00].

Contradicción 6.4 — Integración HubSpot ↔ FlowMed (registro explícito): Patricia Maturana reporta que el intento 2024 de integrar HubSpot ↔ FlowMed fracasó por falta de acuerdo técnico y quedó manual de forma indefinida [Agendamiento-20260413 47:19, 47:48]; en otras sesiones se menciona un proyecto activo HubSpot ↔ Defontana (no es la misma integración) [Recaudacion-20260423 7:00, 11:23]. Son proyectos distintos sobre el mismo CRM; la pieza que afecta a Agendamiento sigue sin integración.

Contradicción 6.7 — Disponibilidad histórica de FlowMed: Rodrigo Llancao reporta indisponibilidad histórica muy baja [Plataformas-20260420 54:04]; Patricia Maturana reporta lentitud creciente y tiempos degradados a 20-25 min para nóminas grandes [Agendamiento-20260413 41:08, 40:40]. No es contradicción dura (uno habla de uptime, la otra de latencia), pero las dos cosas conviven y conviene dejarlas anotadas.

Contradicción 6.11 — Dueño funcional de FlowMed: Eduardo González es el dueño funcional/de Gobierno de TI del sistema completo [Flowmed-20260409 7:03, 8:32, 12:13]; Patricia Maturana es la única autorizada a modificar el módulo de Agendamiento [Flowmed-20260409 10:51, 11:15; Agendamiento-20260413 todo el finding]. Ambas afirmaciones son complementarias; conviene tenerlas explícitas para no confundir "dueño de FlowMed" con "dueña del módulo Agendamiento".

2.6 KPIs y SLAs declarados

• % de personas que completan la admisión digital — medido por Eduardo González; Patricia desconoce el valor concreto [Agendamiento-20260413 37:26].
• Errores que llegan a Contraloría / EDP — medición ad-hoc: 2-6 casos sobre ~300 informes diarios (~1%); no instrumentado [Agendamiento-20260413 1:09:45].
• Tiempo de procesamiento por persona en FlowMed: ~5 min en ingreso normal; 20-25 min para nóminas grandes; ~10 min subir + ~10 min procesar nómina con plantilla [Agendamiento-20260413 40:19, 40:40, 41:08].
• % de solicitudes en modo automático ("cargar solicitud"): ~2%; el restante 98% se hace manual [Agendamiento-20260413 16:08, 29:52].
• Cobertura del autoagendamiento por cliente: 1 cliente operativo, 1 en standby hace 8 meses; primera implementación tomó ~1 año [Agendamiento-20260413 52:57, 53:26].
• % de solicitudes para el día siguiente: 70-80% se ingresan el día anterior al examen; pico tras las 16:00 [Agendamiento-20260413 39:19].
• Cola HubSpot referencial: 18 correos pendientes en el momento de la sesión [Agendamiento-20260413 45:52].
• Tiempo de respuesta soporte FlowMed (Secall) para nuevos formularios: 2 semanas a 1 mes; "a veces nunca" [Agendamiento-20260413 27:58].
• Ciclo EDP downstream: 5 días por iteración cliente; un error de agendamiento puede atrasar pagos varias semanas [Agendamiento-20260413 1:09:21].

2.7 Dolores y workarounds

Dolores principales:

• 98% del trabajo es copiar/pegar manual porque FlowMed sólo lee correctamente ~2% de los formularios [Agendamiento-20260413 16:08, 29:52].
• Soporte FlowMed errático e impredecible: "Depende. La luna, no sé. A veces lo hacen, a veces no lo hacen nunca" [Agendamiento-20260413 27:58].
• Sin integración HubSpot ↔ FlowMed; intento 2024 fracasó [Agendamiento-20260413 47:19, 47:48].
• Lentitud creciente del sistema en últimos meses [Agendamiento-20260413 41:08].
• Carga "todo o nada": un registro malo bota la nómina completa [Agendamiento-20260413 22:25].
• FlowMed mezcla solicitudes cuando dos ejecutivas suben simultáneamente para la misma empresa [Agendamiento-20260413 42:07].
• FlowMed asigna centro al azar en algunas solicitudes con muchos centros distintos [Agendamiento-20260413 22:52, 23:22].
• Sin telemetría / botón de reporte de errores; Patricia debe reproducir y caracterizar el bug para que soporte le crea (que por defecto responde "está todo bien") [Agendamiento-20260413 44:28, 44:58, 45:26].
• Validación manual "por criterio" de baterías incoherentes con el rubro del cliente; no hay procedimiento estándar [Agendamiento-20260413 5:31, 6:22].
• Errores de RUT son la principal fuente de fallo: "El RUT de los trabajadores [es lo más común que falla]" [Agendamiento-20260413 8:26].
• Sin detección de duplicados ni MPI: un mismo trabajador puede ser evaluado 3-4 veces por distintas empresas [Agendamiento-20260413 10:50, 11:20].
• Versionado de formularios fuera de control [Agendamiento-20260413 29:00, 29:21, 31:41].
• Pico operativo después de las 16:00: "Ahí me lleno de correos para poder ingresar para el día siguiente" [Agendamiento-20260413 39:19].
• Cadena de impacto del error: un error de agendamiento se propaga hasta facturación [Agendamiento-20260413 1:09:21, 1:09:45].
• Restricción arbitraria de 3 correos por solicitud [Agendamiento-20260413 4:34, 8:08].
• Confusión drogas saliva/orina en modo automático: el modo automático fuerza un único método para todas las sustancias [Agendamiento-20260413 25:13, 25:49].

Workarounds:

• Validación de RUT en páginas externas: equipo usa páginas alternativas porque les bloquearon el Rectificador del Registro Civil [Agendamiento-20260413 8:26, 8:56, 10:21].
• Ingresar el RUT como pasaporte cuando falta el RUT pero llega el resto de los datos, para que el sistema acepte la nómina [Agendamiento-20260413 14:02, 14:29].
• Borrar el cuarto correo del cliente recurrente antes de cargar (FlowMed sólo soporta 3) [Agendamiento-20260413 4:34, 8:08].
• Categorización manual de la cola HubSpot por urgencia: abrir cada solicitud para ver si es para mañana, pasado mañana, etc. [Agendamiento-20260413 45:52, 46:21].
• Reproducir y caracterizar errores antes de reportar a soporte [Agendamiento-20260413 44:28, 45:26].
• Cargar manualmente las sustancias de drogas en modo automático para preservar alcohol-saliva + sustancias-orina [Agendamiento-20260413 25:13].
• Aprovechar la hoja resumen del Excel del cliente para copiar más rápido al sistema [Agendamiento-20260413 4:11, 15:25, 15:44].
• Agendamiento "previo aviso": ingresar la solicitud aunque falte un dato; pedir corrección al cliente y enviar luego [Agendamiento-20260413 7:12, 8:08].
• Búsqueda inversa de RUT por nombre completo en página externa cuando viene mal el dígito verificador [Agendamiento-20260413 9:24, 9:52].
• Verificación interna previa: buscar primero si el paciente ya existe en FlowMed; si existe, eso valida; si es nuevo, recurre al externo [Agendamiento-20260413 13:35, 14:02].
• Trabajo con dos pantallas: formulario en una, sistema en otra [Agendamiento-20260413 24:18].
• Turno extendido hasta las 22:00 para absorber solicitudes que llegan tarde [Agendamiento-20260413 39:49].
• Notificación al cliente de errores corregidos: Patricia cambia el RUT por su cuenta y avisa al cliente [Agendamiento-20260413 8:56].

3. Historias de Usuario

HU-01 Validación temprana de RUT en intake

Como ejecutiva de Agendamiento quiero que el sistema valide automáticamente cada RUT del Excel del cliente al subir la nómina (formato + dígito verificador + match contra el maestro de pacientes interno) para dejar de validar a mano contra páginas externas y dejar de ingresar el RUT como pasaporte cuando viene mal [Agendamiento-20260413 8:26, 14:02, 14:29].

Criterios de aceptación (Gherkin):

• Given una nómina con un RUT inválido (dígito verificador erróneo) When la ejecutiva intenta cargar la nómina Then el sistema marca el RUT como inválido, sugiere el RUT correcto si el nombre coincide con un paciente existente, y permite cargar el resto de la nómina sin abortar.
• Given un RUT que ya existe en FlowMed con un nombre distinto al del Excel When se carga la nómina Then el sistema levanta una alerta de "posible MPI duplicado" y pide confirmación humana antes de crear un nuevo registro [Agendamiento-20260413 11:48, 12:12, 12:39].

HU-02 Carga masiva tolerante a fallos puntuales

Como ejecutiva de Agendamiento quiero que la carga de la nómina procese los registros válidos y aísle los inválidos en una bandeja de errores para dejar de perder la nómina completa cuando un solo registro falla (regla actual: "todo o nada", RN-08) [Agendamiento-20260413 22:25].

Criterios de aceptación (Gherkin):

• Given una nómina de 50 trabajadores con 3 registros con error de RUT When se procesa la carga Then los 47 válidos se cargan y los 3 inválidos quedan en una bandeja con la causa específica y un botón para reenviarlos tras corrección.

HU-03 Reconciliación inteligente de versiones de formulario

Como Patricia (jefa de Agendamiento) quiero que el sistema reconozca cuando un cliente envía una versión antigua del formulario y me alerte sólo cuando hay un cambio sustantivo (ej. una batería que ya no se soporta) para dejar de depender de los ejecutivos comerciales propagando manualmente la última versión y de clientes "porfiados" que siguen usando la antigua [Agendamiento-20260413 29:00, 29:21, 31:41, 32:11, 33:04].

Criterios de aceptación (Gherkin):

• Given un cliente envía un Excel con una versión de formulario distinta a la oficial When Agendamiento sube el archivo Then el sistema detecta el match al 99% con la versión anterior y procesa sin alerta.
• Given el cliente envía una versión que pide una batería que ya no existe When se sube el archivo Then el sistema bloquea la carga y emite alerta específica indicando qué batería falta o está renombrada.

HU-04 Eliminar la restricción de 3 correos por solicitud

Como ejecutiva de Agendamiento quiero que FlowMed acepte 4 o más correos por solicitud para dejar de borrar manualmente el cuarto correo del cliente recurrente que envía 4 (RN-07 actual) [Agendamiento-20260413 4:34, 8:08].

Criterios de aceptación (Gherkin):

• Given un cliente envía una solicitud con 5 correos en el campo notificación When la ejecutiva carga la solicitud Then FlowMed acepta los 5 y manda la confirmación a todos.

HU-05 Detección de baterías incoherentes con el rubro del cliente

Como ejecutiva de Agendamiento quiero que el sistema marque automáticamente baterías incoherentes con el rubro del cliente (ej. "Marina Mercante" pedida para operadores mineros) para dejar de depender del criterio personal de cada ejecutiva [Agendamiento-20260413 5:31, 6:22].

Criterios de aceptación (Gherkin):

• Given un cliente minero pide la batería "Marina Mercante" para un trabajador When se carga la solicitud Then el sistema levanta una alerta "batería poco común para el rubro del cliente" y pide confirmación.

HU-06 Botón de reporte de error con telemetría

Como Patricia quiero un botón "reportar este error" que capture el contexto (usuario, pantalla, datos, captura) y lo envíe a soporte FlowMed para dejar de tener que reproducir y caracterizar manualmente cada bug antes de que el soporte me crea (hoy: "está todo bien" por defecto) [Agendamiento-20260413 44:28, 44:58, 45:26].

Criterios de aceptación (Gherkin):

• Given la ejecutiva detecta que FlowMed mezcló solicitudes de dos empresas When presiona "reportar error" Then el sistema envía a soporte un ticket con captura, sesión, datos involucrados y log, sin que la ejecutiva tenga que escribir nada.

HU-07 Bloqueo de carga concurrente para la misma empresa

Como Patricia quiero que FlowMed bloquee (o serialice) la carga simultánea de dos ejecutivas para la misma empresa para dejar de tener solicitudes mezcladas (ej. caso Ingeniería Alto Sur) [Agendamiento-20260413 42:07].

Criterios de aceptación (Gherkin):

• Given dos ejecutivas inician carga de solicitud para la misma empresa al mismo tiempo When la segunda intenta procesar Then el sistema bloquea con un mensaje "otra ejecutiva está cargando esta empresa, espera o coordina" hasta que la primera confirme.

HU-08 Asignación de centro determinística

Como ejecutiva de Agendamiento quiero que cuando una solicitud tenga muchos centros de atención mezclados, el sistema asigne el centro más frecuente (no uno al azar) para dejar de re-trabajar solicitudes con centro mal asignado [Agendamiento-20260413 22:52, 23:22].

Criterios de aceptación (Gherkin):

• Given una nómina con 80% de trabajadores en centro A y 20% en centro B When se carga Then el sistema asigna centro A como cabecera y deja una alerta para revisar los del centro B.

HU-09 Notificación al cliente al confirmar la OS

Como solicitante (cliente) quiero recibir el correo automático con el resumen de la solicitud confirmada al instante de cargar la OS para confirmar que mi nómina entró bien y poder reaccionar si algo falta (RN-06 ya está, pero la HU pide consolidar el resumen al solicitante con número de OS y centros asignados) [Agendamiento-20260413 35:01, 35:58].

Criterios de aceptación (Gherkin):

• Given la ejecutiva confirma una solicitud en FlowMed When se procesa Then el sistema envía dentro de 1 minuto un correo al solicitante con número de OS, centro asignado, fecha y batería.
• Given la solicitud tiene un trabajador con correo válido When se confirma Then el sistema envía dentro de 1 minuto al trabajador un correo con día, hora, dirección, link de admisión, usuario y contraseña.

HU-10 Cierre automático del ticket HubSpot tras OS confirmada

Como ejecutiva de Agendamiento quiero que al confirmar una OS en FlowMed, el ticket asociado en HubSpot pase automáticamente a "agenda confirmada" con el número de OS en el asunto para eliminar el paso manual actual (RN-05) y la dependencia de que la ejecutiva no se olvide [Agendamiento-20260413 20:23, 37:53, 47:19, 47:48].

Criterios de aceptación (Gherkin):

• Given una OS confirmada en FlowMed When se procesa Then el ticket en HubSpot pasa a "agenda confirmada" sin intervención humana, y el número de OS aparece en el asunto.
• Given la integración HubSpot ↔ FlowMed sigue rota (escenario actual) When la ejecutiva confirma Then el sistema le muestra un recordatorio explícito para hacerlo a mano (mitigación temporal).

HU-11 Maestro de Pacientes (MPI) interno

Como Workmed quiero que cada trabajador exista como persona única (RUT como llave principal, empresa como llave secundaria) en un Maestro de Pacientes común a todos los sistemas para dejar de evaluar a la misma persona 3-4 veces "como si fuera nueva" cuando la mandan distintas empresas [Agendamiento-20260413 10:50, 11:20, 11:48, 12:12].

Criterios de aceptación (Gherkin):

• Given un trabajador con RUT X ya existe en el MPI When un cliente nuevo envía a esa persona en una nómina Then el sistema reconoce al paciente, mantiene su historial y crea sólo un nuevo evento clínico asociado a la empresa cliente actual.
• Given dos registros con el mismo RUT pero nombres distintos When Agendamiento carga Then el sistema levanta alerta y pide confirmación humana antes de unificar o crear nuevo.

HU-12 Autoagenda multi-tenant para clientes

Como Workmed quiero ofrecer una autoagenda configurable en días, no en un año para que más clientes la adopten y reducir la carga manual del equipo (hoy: 1 cliente operativo, 1 cliente 8 meses en standby, primera implementación tomó ~1 año) [Agendamiento-20260413 49:35, 50:31, 51:01, 52:57, 53:26, 55:38, 56:07].

Criterios de aceptación (Gherkin):

• Given un cliente nuevo se da de alta en autoagenda When Workmed configura cargos, baterías y centros de costo Then el cliente puede crear solicitudes en menos de 5 días desde la solicitud.
• Given el cliente crea una solicitud por autoagenda When ingresa sucursal, fecha, centro de costo, cargos y nómina Then el sistema crea la OS en FlowMed sin intervención del equipo de Agendamiento, y los errores son responsabilidad del cliente [Agendamiento-20260413 52:26, 52:57].

4. Diagrama BPMN (Mermaid)

flowchart TD
  inicio(["Inicio: cliente envía solicitud"])

  subgraph "Rol_Cliente"
    correo["Correo + Excel a agendamiento@workmed"]
    autoagenda["Autoagenda en FlowMed (1 cliente)"]
  end

  subgraph "Rol_HubSpot"
    cola["HubSpot — cola 'agenda por confirmar' (ticket creado)"]
  end

  subgraph "Rol_Patricia_Maturana_Equipo_Agendamiento"
    asignar["Ejecutiva se auto-asigna ticket"]
    descargar["Descarga Excel adjunto"]
    valida_campos{{"¿Campos obligatorios OK? (empresa, RUT, batería, faena, CC, cargo)"}}
    pedir_cliente["Pide al cliente dato faltante"]
    valida_rut{{"¿RUT válido?"}}
    rect_civil["Valida en página externa (Rectificador bloqueado)"]
    modo{{"¿Carga automática (cargar solicitud)?"}}
    auto_load["FlowMed lee Excel (~2% de los casos)"]
    manual_load["Copia/pega manual desde Excel a FlowMed (~98%)"]
    cargar_nomina["Carga nómina (manual o pegada)"]
    procesar["Procesa solicitud y asigna hora"]
    confirmar["Confirma solicitud en FlowMed"]
    actualizar_ticket["Actualiza ticket HubSpot a 'agenda confirmada' + número OS"]
  end

  subgraph "Rol_FlowMed"
    correos_auto["Envía correos automáticos: solicitante (resumen) + trabajador (día/hora/dirección + link admisión)"]
    os_confirmada(["Fin: OS confirmada en FlowMed"])
  end

  inicio --> correo
  inicio --> autoagenda
  correo --> cola
  cola --> asignar
  asignar --> descargar
  descargar --> valida_campos
  valida_campos -->|"no"| pedir_cliente
  pedir_cliente --> valida_campos
  valida_campos -->|"sí"| valida_rut
  valida_rut -->|"no"| rect_civil
  rect_civil --> valida_rut
  valida_rut -->|"sí"| modo
  modo -->|"sí"| auto_load
  modo -->|"no"| manual_load
  auto_load --> cargar_nomina
  manual_load --> cargar_nomina
  cargar_nomina --> procesar
  procesar --> confirmar
  confirmar --> correos_auto
  correos_auto --> actualizar_ticket
  actualizar_ticket --> os_confirmada
  autoagenda --> cargar_nomina

5. Trazabilidad