# Recomendación estratégica para Workmed

> Audiencia: comité ejecutivo Workmed + equipo Emercom.
> Fuentes: AS-IS consolidado (`diagnostico/as-is/00-resumen-ejecutivo-as-is.md`, `00-mapa-cruzado.md`, `01..08`).
> Cita doble: cada afirmación factual sobre la operación actual lleva §AS-IS + finding [mm:ss].
> Tono: el documento **sugiere**, no impone. La tesis maestra TI Sovereignty es la conclusión lógica de los hallazgos AS-IS, no una imposición externa.

---

## §1 Recomendaciones priorizadas (matriz impacto vs esfuerzo)

Las 6 candidatos del §1 son tesis macro. Esta sección desciende al plano de las acciones concretas derivadas del AS-IS. La matriz organiza ~18 recomendaciones priorizadas en 4 cuadrantes según el binomio impacto operativo × esfuerzo de implementación.

### Cuadrante A — Quick wins (alto impacto, bajo esfuerzo, <90 días con recursos actuales)

**Orden de ejecución sugerido**: el roadmap prioriza la acción de **prioridad cero que recupera soberanía sobre la BD clínica** (A.4 contrato encargo Secall + acceso administrativo paralelo + individualizar credenciales) — sin esto, las demás corren sobre soberanía cedida. En paralelo: el **ambiente de desarrollo ya en marcha** (A.1), la palanca de **mayor impacto upstream + diferenciador estratégico** (A.2 Portal del Cliente fase 1, primer entregable del canal directo con la mandante que B.7 expande en Fase 2), y la acción **mediana que descarga operación diaria** (A.3 pipeline). El bloqueo formal de doble contraloría en FlowMed que en versiones anteriores aparecía como Quick Win independiente queda subsumido en B.4 (Secall ya tiene compromiso de entrega).

**A.1 Onboarding de EMERCOM + Ambiente de desarrollo Workmed-Tech (en marcha).** Workmed ya está construyendo el ambiente sobre el que se ejecuta toda la sovereignty: cuenta AWS Workmed propia operativa [Plataformas-20260420 18:14, 42:10, 1:03:20]; **GitHub de Workmed** como organización corporativa activa con la migración del script Python (~2.553 líneas) en proceso con Christian Urbina [Recaudacion-20260423 1:15:49, 1:30:35]; **Eduardo González (líder técnico) + Rodrigo Llancao** con responsabilidad operativa compartida sobre el Identity Service [§6.3 mapa-cruzado; Recaudacion-20260423 1:25:32]; mail de acceso AWS RDS a **Roberto y Barbarita** pendiente de cerrar [Recaudacion-20260423 1:25:32, 1:40:40]; **tooling AI-augmented** (OpenCode + Claude) operativo para acelerar el desarrollo del equipo TI Workmed; **Power Platform + Microsoft 365** ya en uso como capa colaborativa; **EMERCOM** onboarded como partner de transformación digital. Agrupa los hitos de continuidad y de infraestructura de desarrollo en un solo paquete que en su mayor parte ya está ejecutado; los pendientes (mail RDS + finalizar migración script) son trabajo administrativo en curso. **Esfuerzo: en marcha.** **No toca FlowMed.** **Owner: Carolina Araya + Eduardo + Rodrigo + Christian Urbina + EMERCOM.**

**A.2 Portal del Cliente — fase 1 (pre-agendamiento como servicio + plantillas canónicas).** Es el **primer entregable del canal directo Workmed↔mandante** (fase 1 de 2 · B.7 lo expande en Fase 2) y la palanca con mayor impacto upstream del Cuadrante A. Hoy FlowMed sí valida formato RUT (rechaza inválidos), pero el rechazo bloquea el agendamiento porque el operador no tiene herramienta para subsanar antes de cargar — los lunes "explosivos" se quedan hasta las 20:00 corrigiendo errores [Operaciones-20260407 21:23, 21:39, 44:03] y la regla "todo o nada" bota la nómina entera por un registro malo [Agendamiento-20260413 22:25]; en paralelo, el formulario Excel del cliente cambia silenciosamente [§5.1 Agendamiento sub-flujo automático; §3 dolor 9 mapa-cruzado]. La solución no es duplicar validaciones dentro de FlowMed legacy (no se puede sin Secall) ni esperar al Identity Service: es un **portal Workmed** donde la empresa mandante (a) descarga la **plantilla canónica versionada** (sustituye la circulación informal de Excel), (b) **sube su nómina** y la herramienta valida en línea (RUT formato + dígito + cruce con Rectificador del Registro Civil [01-agendamiento §6], centros de costo, baterías del catálogo, fechas, conformidad con la plantilla), y (c) corrige y reenvía hasta tener nómina limpia. Sólo entonces se carga a FlowMed. **Doble beneficio inmediato**: saneamiento upstream + plantilla oficial centralizada. **Por qué prioridad alta**: A.2 es **fase 1 del Portal del Cliente · B.7 lo expande en Fase 2** a a panel de deudas, costos, entrega de informes, trazabilidad y alertas de aptitud — delivery channel natural de modelos contractuales avanzados y foundation del compliance Ley 21.719. Esfuerzo: medio (1-2 meses). No toca FlowMed. Owner: Patricia Maturana + comercial + dev interno Workmed.

**A.3 Módulo de Producción — fase 1.** Es la fase 1 de un Módulo de Producción propio que vive sobre el ambiente Workmed-Tech (A.1) y **no depende de FlowMed legacy** para subsanar dolores en Comercial (valorización) y Contraloría (designación de médicos). Dos componentes: **(A.3.1) Valorización automatizada para Comercial** — job programado nocturno que descarga producción + corre el script Python + carga el dataset, lista al inicio del día hábil sin Ignacio manual [Finanzas-20260416 7:03, 43:32; Recaudacion-20260423 1:14:55; ComercialBI-20260422 1:25, 5:12]; deseable a futuro: valorización en tiempo real, lo que se materializa con **B.2 FlowMed 2.0** (APIs + modelo queryable habilitan el servicio de datos operativos sucesor de Power BI); precondición A.1 con migración del script al GitHub de Workmed cerrada. **(A.3.2) Módulo de Contraloría — acceso unificado a exámenes y designación de médicos contralores** — Vicente trabaja hoy con dos orígenes según sucursal (SACMed/FlowMed para los 6 propios, SharePoint con digitación manual para los 6 acreditados [Contraloria-20260421 12:46, 14:58]) y la designación es conteo casuístico mental [Contraloria-20260421 25:43, 26:12]; el módulo Workmed propio accede a ambos orígenes, unifica la vista de exámenes entregados, permite designar médicos contralores y hace seguimiento del informe final, incluyendo segmentación por tipo de espera (cultivos 3-4 días, metales 15 días, resto bajo SLA 8h/24h [Contraloria-20260421 23:25, 24:15; RN-12 17:13, 17:38]); es **prerequisito directo de B.4** (cola dirigida + pre-informe IA). La **auditoría de cuentas paralelas Power BI** se resuelve en **B.6 marco de gobernanza de datos**, no en A.3. Esfuerzo: 1-2 sprints (A.3.1) + 1-2 meses (A.3.2). No toca FlowMed. Owner: Rodrigo Llancao + Ignacio Ahumada + Vicente Rivano + dev interno Workmed.

**A.4 Recuperación de soberanía sobre la BD clínica de FlowMed (Mes 1 · prioridad cero).** La acción crítica del Mes 1 con tres componentes simultáneos: (1) **contrato de encargo de tratamiento de datos con Secall** con cláusulas mínimas exigibles bajo Ley 19.628 vigente y Ley 21.719 (vigencia 1-dic-2026): finalidades autorizadas, medidas de seguridad, prohibición de subencargados, plazo de conservación, devolución/destrucción al término, derecho de auditoría por Workmed; (2) **acceso administrativo paralelo Workmed sobre la AWS RDS** — Workmed deja de depender de Secall para cualquier cambio de IAM, configuración de red o auditoría sobre la BD productiva; (3) **individualización de credenciales con MFA + cierre de la cuenta genérica compartida** (Eduardo + Rodrigo + Ignacio + ¿otros? + posiblemente personal de Secall) — cada persona con cuenta nominativa y log auditable. **Cierra simultáneamente** S1 (BD clon expuesta a internet), S2 (conexiones MySQL/Postgres sin cifrado), S4 (cuenta única compartida en RDS), I1 (Secall gatekeeper técnico real con soporte errático), C3 (réplica caliente con detalle clínico) y C4 (Secall procesa datos sensibles sin contrato formal de encargo). **Sin esto, A.1, B.1 y B.2 corren sobre soberanía cedida — son aspiracionales.** Esfuerzo: medio-alto (30 días, paralelo entre tracks técnico y contractual). Owner: Juan Pablo Coustasse (CFO · contractual) + Eduardo González (técnico) + Christian Urbina + Asesoría Legal + DPO por designar.

> *Nota — bloqueo formal de doble contraloría en FlowMed*: la conversión del control humano de doble contraloría en bloqueo del sistema (campo obligatorio + firma médica como única autoridad legal) seguía siendo una acción de Cuadrante A en versiones anteriores. Tras revisión, queda subsumida en **B.4** (cola dirigida + pre-informe IA · doble contraloría humana) como sub-componente de la integración con FlowMed; Secall ya tiene fecha de entrega comprometida [Contraloria-20260421 16:44] y no requiere track propio en el roadmap. Owner operacional: Vicente Rivano + Eduardo González coordinando con Secall.

### Cuadrante B — Big bets (alto impacto, alto esfuerzo, palancas estratégicas)

**B.1 Workmed Identity Service como primer microservicio de FlowMed 2.0.** Microservicio acotado (`worker` + `client` + APIs de lectura) sobre la cuenta AWS Workmed propia ya decidida [§Decisiones 08-plataformas-ti; Plataformas-20260420 18:14, 42:10, 1:03:20]. **Elimina la necesidad** del script Python de depuración de RUTs (~50% del script de Rodrigo) [Recaudacion-20260423 1:30:35, 1:31:02]: Workmed Identity Service + FlowMed 2.0 subsanan la problemática en origen — la identidad se valida y normaliza al ingreso, no se depura aguas abajo. Cierra simultáneamente: identidad fragmentada en 4 sistemas [§3 dolor 1 mapa-cruzado], lunes correctivos [§3 dolor 6 mapa-cruzado], frontera de la nueva Ley de Datos Personales [§5.3 mapa-cruzado; Flowmed-20260409 30:02; EcosistemaTI-20260415 42:12]. Es el primer entregable concreto de TI Sovereignty.

**B.2 FlowMed 2.0 sobre AWS Workmed propia, control end-to-end del equipo TI Workmed.** Reemplazo del FlowMed legacy administrado por Secall (sin API genérica [§5 08 dolor 6; Plataformas-20260420 35:00, 35:23], "lentitud creciente" [Agendamiento-20260413 41:08], soporte errático [Agendamiento-20260413 27:58]). Decisión arquitectónica ya tomada por Carolina Araya ("acelerador máximo" [Plataformas-20260420 1:01:32, 1:04:16]). El equipo TI Workmed (8-10 personas, área <3 años [EcosistemaTI-20260415 36:49]) deja de ser cliente de Secall y pasa a ser dueño de la plataforma. Permite mitigar el "todo o nada" de carga de nómina [Agendamiento-20260413 22:25] modificando el módulo sin pasar por el partner.

**B.3 Pipeline de digitalización y procesamiento automatizado de exámenes acreditados en la frontera Workmed.** Hoy 40% de las atenciones provienen de **6 centros acreditados operativamente independientes** (BestMed y otros [Operaciones-20260407 56:32, 1:02:08]) — no usan Megafy ni SACMed porque son operaciones autónomas; cada uno entrega resultados vía OneDrive/SharePoint con sus propios formatos [§3 dolor 7 mapa-cruzado; Contraloria-20260421 12:46, 14:58]. **Imponerles Megafy o SACMed no es viable**: Workmed no controla su flujo interno. La promesa "FlowMed = 100%" se rompe acá [§5 08 dolor 5; EcosistemaTI-20260415 23:55, 24:25], pero el bottleneck está en la **frontera Workmed**, no en el acreditado. Solución: pipeline de **ingestión + extracción estructurada (OCR + parsing) del lado Workmed → carga a FlowMed/SACMed como única fuente de verdad**, validando contra Identity Service (B.1) y catálogo. La regla arquitectónica es estricta: B.3 es ingestión, no analítica — entrega a FlowMed (legacy primero, luego 2.0) y cada downstream consume desde ahí con su lógica; bifurcar (canal directo B.3 → finanzas o B.3 → portal) reproduciría el patrón "anexo que vive afuera" de NetSuite, módulo valorización y HubSpot↔FlowMed 2024. **B.3 es palanca multi-proceso**, los 4 downstream que se desbloquean simultáneamente cuando los exámenes acreditados llegan estructurados a FlowMed: **(1) Contraloría → B.4** (cola dirigida + pre-informe IA sobre el 100% del volumen, no sólo el 60% propio); **(2) Finanzas / EDP → A.3.1 + B.8** — A.3.1 valoriza los 12 sin lógica especial, B.8 cierre contractual deja de esperar transcripción manual ("atenciones de marzo aparecen en abril" [§3 dolor 5; Finanzas-20260416 7:34]); el flujo es **B.3 → FlowMed → A.3.1 → cierre**, no B.3 → finanzas directo; **(3) Comercial / Portal Cliente → B.7** (aptitud vigente del 100% en panel cliente + Ley 21.719); **(4) Agendamiento → A.2** (historial canónico completo, menos re-agendamientos). PoC en Fase 2 con 1-2 acreditados (partir por BestMed); expansión Fase 3. No los desafilia (ver Cuadrante D). Meta: 0% digitación manual en Workmed sobre exámenes acreditados. Owner: Pablo Martínez + dev interno Workmed.

**B.4 Sistema interno de cola dirigida + pre-informe IA con doble contraloría humana sostenida.** Productividad médico contralor: meta declarada **6 informes/hora** [§2.4 RN-10 03-contraloria-salud; Contraloria-20260421 10:47, 24:45] hoy bloqueada por dos cuellos: (a) **digitación manual masiva** previa al médico (40% del volumen llega de acreditados sin Megafy [§3 dolor 7 mapa-cruzado; Contraloria-20260421 12:46, 14:58]) y (b) **ausencia de distribución dirigida** — Vicente lleva conteo casuístico mental porque el dashboard FlowMed no distingue peso por batería y "necesito que libere de cuatro, de cinco. Eso todavía no lo puedo ver" [§2.6 03-contraloria-salud D-09; Contraloria-20260421 25:43, 26:12]. Vicente declara explícitamente KPIs deseados pero **no implementados**: peso específico por batería, asignación de cartera por médico tipo "ejecutivo comercial", distribución dirigida tipo cola/queue [§2.7 03-contraloria-salud; Contraloria-20260421 26:12, 30:54, 31:11, 32:10]. Solución integrada en tres componentes: **(1) sistema de tickets internos** que rutea automáticamente cada caso al médico contralor disponible **según peso de batería** (baterías de alta complejidad — ej. evaluación de altura física + evaluación psicológica + drogas — a médicos senior; baterías más simples a médicos con disponibilidad inmediata); **(2) sistema de apoyo al diagnóstico que pre-revisa y pre-recomienda** apto / no apto / no apto transitorio sobre la captura digital ya saneada por el Identity Service y FlowMed 2.0; **(3) doble contraloría humana sostenida como invariante** — el administrativo del paso 1 sigue preparando preinforme y la firma médica sigue siendo única autoridad legal para liberar [§2.4 RN-02 03-contraloria-salud; Top 10 RN-4]; el sistema asiste, no reemplaza. **Adicionalmente, la doble contraloría se convierte en bloqueo formal de FlowMed**: campo obligatorio + firma médica como única autoridad legal de liberación, cierra el riesgo regulatorio de "FlowMed no bloquea liberación con campos vacíos" [Contraloria-20260421 15:54, 16:18, 16:44]. Secall ya tiene fecha de entrega comprometida sobre el bloqueo formal, así que ese sub-componente corre paralelo dentro de B.4 sin esfuerzo adicional. PoC en Fase 2 con **100 informes** y métricas rigurosas: tasa de aceptación del pre-informe IA sin cambios, tasa de errores, tiempo medio de revisión por peso de batería antes vs después, % de informes que cambian de médico asignado por reasignación manual de Vicente. Owner: **Vicente Rivano + Pablo Martínez** + Eduardo González coordinando bloqueo formal con Secall.

**B.5 Integración FlowMed↔HubSpot retomada sobre plataforma propia.** El intento 2024 fracasó como big-bang [§3 dolor 4 mapa-cruzado; Agendamiento-20260413 47:19, 47:48]. Sobre FlowMed 2.0 con APIs propias, la integración deja de ser "anexo que vive afuera" y pasa a ser **flujo nativo**: el cliente que firma convenio en HubSpot existe en el Identity Service desde el día 1, y todo downstream lo consume. Owners: Eduardo + Rodrigo con responsabilidad operativa compartida + comercial. *(El "Identity Service consumido por al menos 1 sistema downstream" no es Big Bet sino test del Mes 6 de B.1 — vive en `09-recomendacion-roadmap.md` como criterio de éxito de la Fase 2.)*

**B.6 Marco de gobernanza de datos como capa interna de la TI Sovereignty.** Cierra el hallazgo transversal 11 (gobernanza ausente) y la cita explícita "datos en silos: cada área inventó su propia captura, sin gobernanza" [Operaciones-20260407 51:32, 52:19]. Sin esta capa, FlowMed 2.0 hereda los dolores con stack nuevo. Cinco entregables: **(1) DPO designado** con asesoría legal externa para Ley 21.719 + triple ISO; **(2) data stewards por dominio** con rol explícito — identidad → Eduardo + Rodrigo, pricing → Rodrigo + Ignacio + Coustasse, catálogo → comercial + Eduardo, modelo de datos → Eduardo + Rodrigo, servicio de datos operativos sobre FlowMed 2.0 (sucesor de Power BI) → Rodrigo + dueño asignado por vista (auditoría de cuentas paralelas hoy en Power BI), datos clínicos → DPO + Pablo Martínez; **(3) comité de cambios de datos** mensual o trigger-based que cierra los "cambios silenciosos" detectados a 3-4 meses [§hallazgo 9; Comercial-20260420 44:01] y el patrón "abandonado por rotación del validador" [Recaudacion-20260423 38:29, 41:43]; **(4) políticas de versionado** para catálogo, vistas/consultas del servicio de datos operativos, scripts canónicos, modelo de datos; **(5) log auditable** de accesos a datos sensibles que cierra "todos entran con la misma cuenta" en Power BI [Flowmed-20260409 1:06:32, 1:08:39]. No es CAPEX alto: es ciclo organizacional. Owner: Juan Pablo Coustasse (CFO, compliance + contratos) + Eduardo González (CTO operativo) + asesoría legal externa.

**B.7 Portal del Cliente — fase 2 (panel deudas, costos, informes, trazabilidad, alertas).** Expansión natural de A.2 sobre la sovereignty completa. Mientras A.2 entrega la fase 1 como Quick Win, B.7 lo crece sobre Identity Service (B.1) + FlowMed 2.0 release 1 con servicio de datos operativos (B.2, sucesor de Power BI) + marco de gobernanza (B.6, stewardship sobre los datos expuestos al cliente). Cinco capas: **(1) panel de deudas y compromisos** (estado de cuenta, EDPs pendientes, plazos contractuales — hoy en Excel manual de la Supervisora de Facturación [§5.6 mapa-cruzado; Recaudacion-20260423 11:52, 37:59]); **(2) visibilidad de costos** (producción valorizada, descuentos, mix por batería, evolución vs presupuesto — reduce iteraciones del ciclo EDP de 5 días [§5.2 mapa-cruzado]); **(3) entrega de informes con descarga de PDF firmados** (aptitud vigente por trabajador, foundation del SLA "% aptitud >95%" activable cuando comercial detecte apetito [§5.4 mapa-cruzado]); **(4) trazabilidad end-to-end** de cada examen (agendado → atendido → contraloría → informe disponible); **(5) alertas al cliente y al trabajador** de aptitud por vencer (hoy no existen [Flowmed-20260409 45:44, 46:10] — foundation del SLA + Ley 21.719). **Subsume D.4** (Portal real-time del EDP fuera de FlowMed 2.0, antes en bitácora): la diferencia clave es que B.7 está **dentro** de la sovereignty (sobre AWS Workmed propia + Identity Service + FlowMed 2.0 con servicio de datos operativos + B.6 gobernanza), no afuera. Owner: dev interno Workmed + comercial + DPO.

**B.8 Cierre contractual del mes con clientes top + alineación operativa.** El cierre de mes hoy es "blando": producción se mueve retroactivamente, atenciones de marzo aparecen en abril, último EDP sale recién el día 9 [§3 dolor 5 mapa-cruzado; Finanzas-20260416 7:34, 8:27]. No es Quick Win — requiere renegociación contractual con el 60% del top que ya tiene convenio firmado [Comercial-20260420 12:43] y alineación operativa con upstream que mueve la fecha (cultivos 3-4 días + metales 15 días + acreditados con digitación manual). Cuatro componentes: (1) **renegociación de fecha de corte dura** (ej. día 5 hábil) cliente por cliente; (2) **alineación operativa** apalancada en B.3 Megafy (elimina digitación manual), B.4 cola dirigida (acelera baterías complejas) y B.2 FlowMed 2.0 con servicio de datos operativos (visibilidad real-time del cierre vs presupuesto, con stewardship de B.6); (3) **política formal de cierre** dentro del marco de gobernanza B.6 — el comité de cambios aprueba la fecha como dato canónico; (4) **prerequisito de cualquier modelo contractual avanzado activable post-sovereignty** — sin cierre formal el SLA "% aptitud vigente >95%" no es medible en ventana acotada. Beneficio standalone: recupera 2-3 días de ventaja para facturar cada mes [Recaudacion-20260423 36:33, 1:33:37, 1:35:04] y cierra el gatillante "factura sale el 9 + cliente la rechaza el 17 = sin ventana de respuesta" frente al plazo legal de 8 días corridos. Esfuerzo: medio-alto. Owner: Juan Pablo Coustasse + comercial.

### Cuadrante C — Fill-ins (bajo impacto, bajo esfuerzo, mejoras puntuales)

**C.1 Documentación del modelo de datos de FlowMed.** FlowMed legacy nunca fue documentado [§3 dolor 10 mapa-cruzado; Recaudacion-20260423 1:23:16]: qué tablas existen, cómo se relacionan, qué columna almacena qué dato y cuál es sensible. El conocimiento vive en la cabeza de Eduardo González — refuerzo del riesgo SPOF que C3 ya señala. La documentación se construye en 1-2 sprints inspeccionando la réplica AWS RDS, con entregable concreto: diagrama Entity-Relationship + diccionario de datos por tabla + clasificación de datos sensibles (PII clínico, operacional, comercial). Es **prerrequisito invisible de B.2 FlowMed 2.0** — sin modelo documentado, la migración por estrangulamiento se construye a ciegas — y **prerrequisito de compliance Ley 21.719**: el inventario de tratamientos exigido por la ley es imposible sin esta documentación. **Esfuerzo: bajo (1-2 sprints).** **No toca FlowMed.** **Owners: Eduardo González (líder técnico) + Rodrigo Llancao.**

**C.2 Versionado de catálogo de prestaciones con alertas de cambio.** Marcela reportó un incidente concreto en sesión [§3 dolor 9 mapa-cruzado; Comercial-20260420 44:01]: un proveedor renombró una prestación y la valorizó al doble sin avisar; toda la producción salió mal por 3-4 meses hasta que se detectó. Hoy el catálogo se modifica sin trazabilidad ni notificación a downstream — cero gobernanza sobre un activo crítico que toca pricing, valorización y cobranza. La solución técnica complementa la pieza organizacional: trigger automático en la base de datos que envía email a comercial + Eduardo cada vez que alguien modifica un ID, precio o descripción de prestación, con bitácora versionada y auditable. **Complementa el comité de cambios de B.6 marco de gobernanza**: la gobernanza decide qué cambios se permiten; C.2 alerta cuando ocurren. **Esfuerzo: bajo (1-2 días).** **No toca FlowMed.** **Owner: comercial + Eduardo González.**

**C.3 Bodegas satélite como modelo de descentralización logística.** Hoy el abastecimiento de insumos está centralizado en la bodega de Santiago [§5.7 mapa-cruzado; Abastecimiento-20260423 10:02]: las sedes regionales (Calama, Antofagasta y futuras) dependen de despachos cotidianos desde el centro, con SLA estándar de 1-1.5 días [Abastecimiento-20260423 23:49]. Eso introduce dependencia logística, costo de transporte recurrente y riesgo de stockout cuando el despacho se atrasa o el insumo escasea. Pamela Lastra ya tiene un **piloto de bodega satélite operativo en Antofagasta** que descentraliza stock crítico hacia el norte: insumos cotidianos disponibles regionalmente, sin esperar despacho central. La acción consiste en documentar el modelo del piloto (qué stock se desplaza, qué SLA interno aplica, qué KPIs de rotación medir) y replicarlo a otras sedes con presión similar de transporte o stockout. **Esfuerzo: bajo (replicar patrón ya validado).** **No toca FlowMed.** **Owner: Pamela Lastra.**

**C.4 Visibilidad del no-show por cliente con umbral recomendado.** Workmed históricamente absorbe las inasistencias como parte de la propuesta de valor con sus clientes top [Top 10 RN-6; Comercial-20260420 6:25, 6:51] — práctica que la diferencia de otros prestadores y forma parte de la relación cultural con la cartera mayor. El dolor real no es la absorción sino que **nadie lo mide ni lo hace visible**: 15-17% de no-show sobre 700 agendas/día [Plataformas-20260420 53:39] equivale a 100-120 atenciones diarias regaladas, pero ese costo queda invisible tanto para Workmed como para el cliente. La acción tiene dos piezas que respetan el modelo histórico sin imponer cláusulas: (1) **instrumentar y reportar mensualmente el no-show por cliente** con cifras y valorización ("este mes Workmed absorbió X atenciones por no-show de tu equipo, valorizadas en $Y") · hace visible el servicio extra y genera data para futuras conversaciones contractuales; (2) **umbral recomendado de no-show por cliente** (ej. 10-12% mensual, a calibrar contra baseline) como norma cultural compartida — si un cliente se pasa del umbral, comercial abre conversación operativa sin cobro ni penalidad. El cobro formal del no-show queda como opción contractual avanzada dentro de B.8 (cierre contractual del mes con clientes top), donde la conversación tarifa-volumen ya está abierta. **Esfuerzo: bajo (instrumentar + reporte mensual).** **No toca FlowMed.** **Owner: comercial + Juan Pablo Coustasse + Mónica Pérez (PMO).**

### Cuadrante D — Hard slogs (bajo impacto, alto esfuerzo, descartar o posponer)

**D.1 Desafiliación de los 6 centros acreditados.** CAPEX alto (policlínicos modulares, carros de paro) + renegociación con clientes top que valoran cobertura nacional + recompensa baja vs pipeline de digitalización Workmed-side (B.3). Posponer indefinidamente; revisar sólo si SLA aptitud vigente es inalcanzable con red mixta saneada.

**D.2 Producto de datos B2B en Fase 1-2.** Requiere modelo FlowMed documentado, anonimización legal sólida y perfil comercial nuevo. Esperar a Fase 3 con activo ya saneado.

**D.3 Reemplazo big-bang de Defontana o HubSpot.** Patrón histórico Workmed: NetSuite y HubSpot↔FlowMed 2024 fracasaron como big-bangs [Finanzas-20260416 37:26; Agendamiento-20260413 47:19; Recaudacion-20260423 38:29]. Migración por estrangulamiento desde la plataforma propia, no reemplazo.


---

## §2 Tesis · TI Sovereignty

Workmed empodera a su equipo TI (**8-10 personas, área <3 años** [EcosistemaTI-20260415 36:49]) con **control directo sobre su infraestructura cloud, su propia plataforma central y la gobernanza de los datos que circulan por ella** — FlowMed 2.0 sobre la cuenta AWS Workmed propia ya decidida [Plataformas-20260420 18:14, 42:10, 1:03:20] — que reemplaza al partner-as-bottleneck (Secall) y elimina los puntos críticos actuales: **Secall como gatekeeper técnico real** de la BD productiva FlowMed en AWS RDS, con Eduardo González operando como broker funcional que canaliza solicitudes de acceso y un acceso interno distribuido vía cuenta genérica compartida sin trazabilidad por persona [§6.3 mapa-cruzado; Recaudacion-20260423 1:25:32, 1:38:42] y **el script Python en GitHub personal de Rodrigo Llancao** [§5 08-plataformas-ti riesgo 2; Recaudacion-20260423 1:15:49, 1:30:35]. El equipo TI deja de ser cliente de partners externos y pasa a ser **dueño de la plataforma y de los datos que la habitan**; sólo así sanear los procesos, mitigar dolores y abrir la **visión TO-BE (Agentes IA + Orquestador)** tiene base estable.

La sovereignty se descompone en **dos capas inseparables**: (a) **control técnico** — cuenta AWS propia, FlowMed 2.0 estrangulando al legacy, Identity Service, GitHub de Workmed, accesos AWS distribuidos —; y (b) **gobernanza de datos** — data stewards por dominio, comité de cambios, política de versionado, inventario de tratamientos, **DPO designado**, log auditable. La capa de gobernanza es la que hoy el AS-IS revela como ausente: **"datos en silos: cada área inventó su propia captura, sin gobernanza"** [Operaciones-20260407 51:32, 52:19], catálogo que cambia silenciosamente y se detecta a 3-4 meses [§hallazgo 9; Comercial-20260420 44:01], módulo de valorización abandonado "porque la persona que lo validaba rotó de cargo varias veces; nunca se llegó a validar si calculaba bien" [Recaudacion-20260423 38:29, 41:43]. Sin gobernanza, el control técnico es vacío: una plataforma propia mal gobernada hereda los mismos dolores con stack nuevo. Por eso B.6 (Marco de gobernanza de datos) no es complemento opcional, es condición de la sovereignty completa y de un compliance regulatorio (Ley 21.719 + triple ISO) ejecutable.

> **Antes de cualquier salto a la visión TO-BE** (Agentes IA + **[Orquestador de Transformación Digital](https://ada.emercom.cl/shared/clientes/workmed/orquestador-transformacion-digital.html)**), **la prioridad es mitigar dolores en cada proceso ya identificados en el AS-IS**. La TI Sovereignty es la base sobre la que todo lo demás se construye. El crecimiento volumétrico y los modelos contractuales avanzados (BPO outcome-based, planes anuales) emergen como **consecuencia natural** del saneamiento — no requieren tracks propios; se activan cuando el comité comercial detecta apetito del mercado.

---

## §3 Problema raíz

El problema de Workmed no es operativo: es **estructural y dependiente de terceros**. Hoy:

1. **Identidad fragmentada en 3-4 sistemas.** El mismo cliente vive en FlowMed, HubSpot, Defontana y Power Platform sin sincronización; el trabajador no tiene MPI; el mismo paciente se evalúa "como si fuera nuevo" 3-4 veces [§3 dolor 1 mapa-cruzado; Finanzas-20260416 11:13, 11:40; Agendamiento-20260413 11:48; Recaudacion-20260423 1:38:13].

2. **Soberanía sobre la BD clínica cedida a Secall.** El gatekeeper técnico real de la BD productiva FlowMed en AWS RDS es Secall (proveedor externo); Eduardo González opera como broker funcional que canaliza solicitudes a Secall; el acceso interno se distribuye vía cuenta genérica compartida (Eduardo + Rodrigo + Ignacio + ¿otros?) sin trazabilidad por persona; y todo ello sin contrato formal de encargo de tratamiento de datos verificable. La cadena de valorización y cobranza depende de un proveedor externo con "soporte 2 semanas a nunca" para cualquier cambio de IAM, red o auditoría [§6.3 mapa-cruzado; Recaudacion-20260423 1:25:32, 1:38:42; EcosistemaTI-20260415 33:37, 35:51, 36:49].

3. **Núcleo de pricing en repo personal.** El script Python de valorización (~2.553 líneas) vivía en el **GitHub personal de Rodrigo Llancao**; está en migración a GitHub de Workmed pero aún no completa [§5 08 riesgo 2; Recaudacion-20260423 1:15:49, 1:30:35, 1:38:42; Finanzas-20260416 45:17].

4. **FlowMed sin API genérica.** "Ni siquiera hay como una API, por así decirlo, de FlowMed"; sólo integraciones partner punto-a-punto. Todo desarrollo interno (R&S, Salud Compatible, Salud Mental, agente piloto, BI) se hace contra la base de réplica AWS [§5 08 dolor 6; Plataformas-20260420 35:00, 35:23; EcosistemaTI-20260415 3:14].

5. **Soporte Secall errático "2 semanas a nunca".** Tiempo de respuesta para incorporar formularios nuevos: 2 semanas a 1 mes, "a veces nunca" [§5.1 mapa-cruzado; Agendamiento-20260413 27:58, 44:28]. Workmed no tiene administración del software del core [EcosistemaTI-20260415 36:49, 38:38; Plataformas-20260420 35:23].

6. **Iniciativa de valorización en FlowMed abandonada hace ~6 meses.** El módulo "control de pago" sigue siendo origen del Excel diario, pero la automatización del pricing dentro de FlowMed quedó abandonada por rotación del validador; nunca se llegó a validar si calculaba bien [§5 08 dolor 3; Recaudacion-20260423 38:29, 38:58, 41:43; EcosistemaTI-20260415 29:38].

7. **Integración HubSpot↔FlowMed fracasada en 2024.** Intento dejado manual indefinidamente [§3 dolor 4 mapa-cruzado; Agendamiento-20260413 47:19, 47:48].

8. **Stack regulatorio sobre la BD productiva FlowMed: vigente hoy + deadline 1 dic 2026.** El informe ocupacional que se entrega al cliente es sólo aptitud, pero la BD almacena el detalle clínico (diagnósticos, antecedentes, exámenes). La BD productiva clon expuesta a internet (S1) y la réplica caliente AWS RDS con detalle clínico (C3) — administrada por Secall — **incumplen hoy** la **Ley 19.628 art. 2 letra g)** (datos sensibles · estados de salud) y el régimen específico **Ley 16.744 + DS 109 + dictámenes SUSESO** (el detalle clínico no debe ser accesible al empleador ni a terceros) — no se requiere brecha consumada para configurar la infracción. Adicionalmente Secall procesa esos datos sin contrato formal de encargo verificable (C4). La **Ley 21.719** entra en vigor el 1-dic-2026 con régimen sancionatorio robusto + DPO + ARCOP + obligación de contrato de encargo [§5 08 riesgo 4; EcosistemaTI-20260415 43:39, 44:05]. La triple norma ISO con deadline junio 2026 es el envoltorio [Flowmed-20260409 30:52; EcosistemaTI-20260415 42:40].

9. **"Lentitud creciente" del FlowMed legacy.** Tiempos de procesamiento se degradaron a 20-25 min para nóminas grandes vs ~5 min normal [§6.7 mapa-cruzado; Agendamiento-20260413 41:08, 40:40]. Síntoma temprano de saturación.

10. **Carga "todo o nada" en agendamiento.** Un registro malo bota la nómina completa [§5.1 mapa-cruzado; Agendamiento-20260413 22:25]. Modificar este módulo hoy depende exclusivamente de Patricia Maturana + soporte Secall errático.

Cada uno de los 10 puntos converge en la misma raíz: **Workmed no controla su propio core**. Sanear la operación sin antes resolver eso es construir sobre arena.

---

## §4 Por qué TI Sovereignty habilita todo lo demás

La sovereignty no es un fin en sí mismo; es la condición de posibilidad para los siguientes movimientos.

**Sanear procesos (mitigar dolores) requiere control sobre la plataforma.** Ejemplo concreto: la regla "todo o nada" en agendamiento [§5.1 mapa-cruzado; Agendamiento-20260413 22:25] sólo se rompe modificando el módulo de carga. Hoy esa modificación depende exclusivamente de Patricia Maturana + soporte Secall ("2 semanas a nunca" [Agendamiento-20260413 27:58]). Sin sovereignty no hay timeline ejecutable para este quick win.

**Crecimiento y modelos contractuales avanzados como consecuencia natural.** Un eventual contrato "% aptitud vigente >95%" exige plataforma propia con alertas de vencimiento al trabajador y al cliente — alertas que **hoy no existen** en FlowMed [§5 08 dolores cross; Flowmed-20260409 45:44, 46:10]. Sobre el legacy, el SLA es ficticio. Igualmente, multiplicar volumen por 7,5× (de ~400/día a ~3000/día) sobre el legacy con "lentitud creciente" [§6.7 mapa-cruzado; Agendamiento-20260413 41:08] no tiene mecanismo de respuesta — Secall no escala con el cliente. **Ambos movimientos surgen automáticamente** cuando la sovereignty está en su lugar (FlowMed 2.0 + Identity Service + gobernanza). Por eso no son tracks propios del roadmap: son **consecuencia natural** del saneamiento, activables cuando comercial detecta apetito del mercado.

**Compliance vigente hoy (Ley 19.628 + Ley 16.744/DS 109) + Ley 21.719 desde 1-dic-2026 requieren control sobre el dato.** La réplica AWS RDS con detalle clínico (diagnósticos, antecedentes, exámenes) y la BD clon expuesta no son riesgos futuros: **incumplen hoy** la Ley 19.628 (datos sensibles) y el régimen ocupacional Ley 16.744/DS 109/SUSESO (el detalle clínico no debe quedar accesible al empleador ni a terceros) [§5 08 riesgo 4; EcosistemaTI-20260415 43:39, 44:05]. Adicionalmente Secall procesa esos datos sin contrato formal de encargo verificable. El Identity Service centraliza el consentimiento granular hoy disperso y permite anonimización selectiva [§Compromisos 5.8 mapa-cruzado; EcosistemaTI-20260415 41:46, 42:12]. Sin sovereignty, el deadline regulatorio del 1-dic-2026 sólo se cumple "a punta de papel" — y la exposición legal vigente sigue abierta.

**Patrón histórico que advierte.** Workmed ha intentado tres veces saltarse la sovereignty: NetSuite, HubSpot↔FlowMed 2024, módulo valorización [Finanzas-20260416 37:26, 39:06; Agendamiento-20260413 47:19, 47:48; Recaudacion-20260423 38:29, 41:43]. Las tres fracasaron. La sovereignty no es una preferencia estética; es la lección destilada del propio AS-IS.

---

## §5 Mecanismo y roadmap 90/180/365

Tres fases secuenciales. La fase 3 (decisiones de monetización) **sólo se evalúa cuando las fases 1 y 2 cierran sus hitos**. La estructura 90/180/365 reemplaza al 30/90/365 del v2.0 para reflejar que la sovereignty no es ejecutable en 30 días.

### Fase 1 — Saneamiento + sovereignty foundations (días 1-90)

- **Quick wins de §2 Cuadrante A ejecutados** en orden de prioridad: A.4 recuperación de soberanía sobre la BD clínica (contrato de encargo de tratamiento con Secall + acceso administrativo paralelo Workmed sobre AWS RDS + individualizar credenciales y cerrar cuenta genérica compartida — prioridad cero del Mes 1), onboarding EMERCOM + ambiente Workmed-Tech con AWS, GitHub, OpenCode, Claude, Power Platform, M365 (A.1, ya en marcha), Portal del Cliente fase 1 con pre-agendamiento + plantillas canónicas (A.2 — fase 1 del Portal · B.7 lo expande en Fase 2), pipeline producción + auditoría Power BI + panel Vicente (A.3). El bloqueo formal de doble contraloría en FlowMed queda subsumido en B.4 (Secall comprometido).
- **Arquitectura FlowMed 2.0 sobre AWS Workmed propia diseñada.** Documento técnico cerrado con Carolina Araya + Eduardo + Rodrigo. Stack, modelo de datos, plan de migración por estrangulamiento.
- **Identity Service definido y responsabilidad operativa compartida formalizada.** Eduardo González (líder técnico) + Rodrigo Llancao comparten la responsabilidad operativa sobre el Identity Service (cierra §6.3 mapa-cruzado: individualizar accesos hoy compartidos en cuenta genérica y recuperar soberanía sobre datos clínicos hoy en manos de Secall). Alcance acotado: `worker` + `client` con APIs de lectura.
- **A.1 Onboarding + Ambiente Workmed-Tech consolidado.** AWS Workmed propia operativa, GitHub de Workmed activo con script Python migrado (cierra SPOF de repo personal [§5 08 riesgo 2]), individualización de credenciales sobre AWS RDS + cierre de cuenta genérica + acceso administrativo paralelo Workmed [Recaudacion-20260423 1:25:32, 1:40:40], EMERCOM onboarded como partner técnico colaborador que apoya el levantamiento de Sovereignty, tooling AI-augmented (OpenCode + Claude) en uso. Es la base de A.5 (pipeline) y A.6 (herramienta).
- **Liderazgo nuevo + partner alineado.** Carolina Araya entra como CTO con mandato explícito ("acelerador máximo para FlowMed 2.0" [Plataformas-20260420 1:01:32, 1:04:16]); EMERCOM acompaña como partner técnico colaborador. Lo que falta del lado interno: formalizar roles, individualizar accesos hoy compartidos en cuenta genérica y recuperar soberanía sobre los datos clínicos administrados por Secall sin contrato formal de encargo.
- **Documentación inicial del modelo de datos de FlowMed** (insumo de FlowMed 2.0 y del producto de datos en Fase 3).

### Fase 2 — Plataforma propia + integraciones críticas (días 91-180)

- **Primer release de FlowMed 2.0 sobre AWS Workmed cubriendo agendamiento + intake.** Estrangulamiento progresivo del legacy en los módulos donde la "todo o nada" y la lentitud creciente más duelen.
- **Identity Service con APIs de lectura consumido por al menos 1 sistema downstream** (test concreto del Mes 6 — si no se cumple, el patrón monolítico se está repitiendo).
- **PoC de pre-informe IA con 100 informes en contraloría con medición rigurosa** de tasa de aceptación sin cambios + tasa de errores. Doble contraloría humana se mantiene.
- **PoC pipeline de digitalización acreditados con 1-2 acreditados** (partir por BestMed). Pasarela digital Workmed-side, no Megafy impuesto sobre operaciones independientes.
- **Big bets de §1 Cuadrante B priorizados arrancan.** B.1 (Identity Service) y B.2 (FlowMed 2.0 release 1) terminan; B.3 (pipeline digitalización acreditados) y B.4 (pre-informe IA — primer agente del ecosistema TO-BE) en PoC; **B.6 (Marco de gobernanza de datos)** instalado; **B.7 (Portal del Cliente fase 2)** crece sobre la fase 1 de A.2 con panel de deudas, costos, entrega de informes, trazabilidad y alertas — delivery channel de modelos contractuales avanzados activables post-sovereignty; **B.8 (Cierre contractual del mes con top + alineación operativa)** apalancado en B.3, B.4 y B.6 — recupera 2-3 días de ventaja para facturar.
- **Benchmark de carga FlowMed 2.0** — input crítico para validar capacidad volumétrica.

### Fase 3 — Visión TO-BE post-sovereignty (días 181-365)

Sobre la base saneada en Fases 1-2, Workmed **arranca la visión TO-BE original** que motivó este diagnóstico (proyecto [Orquestador de Transformación Digital](https://ada.emercom.cl/shared/clientes/workmed/orquestador-transformacion-digital.html)). El **crecimiento volumétrico** y las **opciones de monetización contractual avanzada** (BPO outcome-based, planes anuales) emergen como **consecuencia natural** de Fases 1-2 — no requieren un track propio en el roadmap; cuando la sovereignty está en su lugar, el comité comercial las activa cuando hay apetito del mercado. Lo que sí requiere un track explícito de Fase 3 es:

- **T1 — Agentes IA + Orquestador de Transformación Digital.** La **visión TO-BE original** del proyecto Workmed. Sobre sovereignty + saneamiento, el Orquestador coordina end-to-end agendamiento → operaciones → contraloría → EDP con agentes IA especializados por proceso. **B.4 pre-informe IA en contraloría con doble contraloría humana es el primer agente del ecosistema**, ya en Fase 2 con PoC de 100 informes; T1 expande la capacidad agéntica a los demás procesos (agente de pre-agendamiento que valida nóminas en B.7, agente de operaciones que coordina sucursales, agente conversacional sobre datos clínicos para mandantes en el portal). El Orquestador es la **capa integradora**: agentes coordinados vía orquestador central que conoce estado del trabajador, del cliente y de la batería en curso. Sin sovereignty (FlowMed 2.0 con APIs, Identity Service, gobernanza), cualquier agente IA queda como "anexo que vive afuera" reproduciendo el patrón fracasado.
- **T1 está condicionado al éxito de B.4** (PoC pre-informe IA con métricas rigurosas de aceptación, error y reasignación). Si B.4 valida la doble contraloría humana sostenida con productividad clínica medible, T1 se ejecuta; si B.4 no escala, T1 se posterga hasta resolver la brecha de calidad.
- **Decisión informada por validaciones Mes 6** (ver §7): capacidad sostenible FlowMed 2.0 con benchmark de carga, PoC pre-informe IA con métrica rigurosa (T1 condicionado al éxito de B.4), PoC pipeline digitalización funcionando con al menos 1-2 acreditados (partir por BestMed).

### Stakeholders identificados

- **Carolina Araya (CTO):** primer hito FlowMed 2.0 [Plataformas-20260420 1:01:32, 1:04:16].
- **Eduardo González (líder técnico) + Rodrigo Llancao:** responsabilidad operativa compartida del Identity Service.
- **Mónica Pérez · Oficina de Proyectos (PMO):** cadencia, hitos, riesgos, secretaría técnica del comité de gobernanza B.6.
- **DPO · por designar (Mes 2):** owner del compliance Ley 21.719 + custodios del dato.
- **Coustasse (CFO):** owner del **marco de gobernanza de datos (B.6)** + designación de DPO + asesoría legal Ley 21.719 + triple norma ISO; owner del contrato BPO si se elige T1.
- **Vicente Rivano + Pablo Martínez:** owners del SLA aptitud vigente o calidad clínica del pre-informe IA.
- **Christian Urbina (infraestructura):** GitHub de Workmed + scheduler del pipeline de producción diaria + on-prem Manuel Montt durante transición.

### Fuera de alcance Fase 1-3

- Desafiliación de centros acreditados (D.1 cuadrante hard slogs).
- Producto B2B de datos clínicos (fase posterior).
- Modelos contractuales avanzados (BPO outcome-based, suscripción anual flat) — emergen como consecuencia natural del saneamiento, no requieren track propio.
- Portal real-time del EDP construido fuera de FlowMed 2.0 (subsumido en B.7 dentro de la sovereignty).

---

## §6 Impacto esperado en KPIs

| KPI declarado en AS-IS | Cifra actual | Cifra esperada | Mecanismo | Fuente AS-IS |
|---|---|---|---|---|
| Volumen de EDPs | 300-400/mes | 1 factura/mes por contrato BPO (5-10 contratos) **si se elige T1** | Cuota fija mensual reemplaza al EDP por evento (T1 post-sovereignty) | §5.2 00-resumen; [Recaudacion-20260423 6:06] |
| Ciclo de validación EDP | 5 días/iteración; extremos 2 meses | 0 (T1) o <2 días (T2 con visibilidad continua) | Outcome-based o portal sobre plataforma propia | §3 dolor 2 mapa-cruzado; [Recaudacion-20260423 16:36] |
| Tamaño facturas | $20M-$40M (extremos $300M-$400M) | Cuota fija predecible (T1) o distribución más uniforme (T2) | Tarifa SaaS B2B o diversificación industrial | §5.2 00-resumen; [Recaudacion-20260423 31:05] |
| Concentración 80-90% top 10 = peores pagadores | Bola de nieve estructural | T1: riesgo controlado por SLA contractual; T2: 70/30 mix industrial | Contrato BPO o diversificación post-sovereignty | §3 dolor 8 mapa-cruzado; [Comercial-20260420 21:58, 43:02] |
| Errores de identidad que llegan a Contraloría/EDP | ~1% (2-6 sobre ~300/día) | <0.1% | Identity Service valida upstream | §5.3 mapa-cruzado; [Agendamiento-20260413 1:09:45] |
| Lunes "explosivo" hasta 20:00 corrigiendo RUT/fecha/género | Ocurrencia semanal | Reducción 80-90% | Captura única en Identity Service + validación intake | §3 dolor 6 mapa-cruzado; [Operaciones-20260407 21:23, 21:39] |
| Captura manual repetida del trabajador | 6+ estaciones × 700 atenciones/día | 1 sola captura por trabajador en su ventana de validez | Identity Service como fuente única | §3 dolor 6 mapa-cruzado; [Operaciones-20260407 11:43, 12:12] |
| Líneas script Python valorización | 2.553 líneas | ~50% migrable al servicio (depuración de identidad sale del script) | Reglas de descuento quedan; depuración RUT migra al Identity Service | §5.2 mapa-cruzado; [Recaudacion-20260423 1:30:35] |
| Alertas al trabajador por examen vencido | NO existen | Existen (foundation del SLA aptitud vigente >95% activable cuando comercial detecte apetito) | Plataforma propia con motor de alertas (B.7) | §5 08 dolores cross; [Flowmed-20260409 45:44, 46:10] |
| Carga manual de la Supervisora de Facturación (conciliación HubSpot↔Defontana) | 100% manual en Excel | Redirigida de chasing administrativo a gestión operativa | Plataforma propia con APIs Defontana | §5.6 mapa-cruzado; [Recaudacion-20260423 11:52, 37:59] |
| Compliance Ley 21.719 (1 dic 2026, 6 meses) | Réplica caliente con clínicos = vulnerabilidad | Servicio auditado con consentimiento granular y anonimización selectiva | Identity Service como frontera de compliance | §5 08 riesgo 4; [EcosistemaTI-20260415 41:46, 43:39, 44:05] |
| NPS Operaciones | Métrica activa | Indicador de retención del contrato BPO (T1) o del producto (T2) | Cambia el sujeto: dotación viva, no atención discreta | §5.1 mapa-cruzado; [Operaciones-20260407 41:12] |
| Soporte FlowMed (Secall) | 2 semanas a 1 mes; "a veces nunca" | N/A (equipo TI Workmed propio) | TI Sovereignty: control end-to-end del core | §5.1 mapa-cruzado; [Agendamiento-20260413 27:58] |
| Acceso AWS RDS | Gatekeeper técnico Secall + cuenta genérica compartida sin trazabilidad | Cuentas individualizadas con MFA + Workmed con admin paralelo + contrato de encargo formal con Secall | Cierre §6.3 mapa-cruzado | §3 dolor 10 mapa-cruzado; [Recaudacion-20260423 1:25:32, 1:38:42] |
| **Capacidad volumétrica nacional** | **~400/día** | **3000/día (consecuencia post-sovereignty cuando comercial detecta apetito)** | FlowMed 2.0 + pipeline digitalización acreditados (B.3) + sucursales nuevas | §5.1 mapa-cruzado; [Operaciones-20260407 30:46] |
| **Productividad médico contralor** | **6 informes/hora (meta)** | **12-15 inf/h** | Pre-informe IA con doble contraloría humana | §5.1 mapa-cruzado; [Contraloria-20260421 10:47, 24:45] |
| **% digitación manual en frontera Workmed sobre exámenes acreditados** | **100% (los 6 acreditados independientes, ej. BestMed)** | **0%** | Pipeline de digitalización Workmed-side (B.3) | §3 dolor 7 mapa-cruzado; [Contraloria-20260421 12:46, 14:58] |
| **Diversificación industrial top 10** | **100% minería** | **70/30 mix (minería/otros)** | Capacidad post-sovereignty + 1-2 industrias objetivo nuevas | §5.2 mapa-cruzado; [Comercial-20260420 21:58, 37:48] |
| **Concentración Manuel Montt** | **45% nacional** | **30%** | Descongestión geográfica con sucursales nuevas | §5.2 mapa-cruzado; [Operaciones-20260407 4:08] |
| **Capacity headroom FlowMed** | **~saturado (lentitud creciente)** | **5× sobre baseline** | FlowMed 2.0 en AWS Workmed propia | §6.7 mapa-cruzado; [Agendamiento-20260413 41:08, 40:40] |

> **Nota sobre estimaciones:** las cifras esperadas se calculan sobre el supuesto de que la sovereignty se ejecuta según roadmap 90/180/365 — Identity Service, primer release FlowMed 2.0, gobernanza B.6, pipeline digitalización B.3 y cierre contractual B.8 cierran sus hitos. Las cifras de capacidad volumétrica + diversificación industrial dependen además de las validaciones del Mes 6 (§7).

---

## §7 Riesgos · validaciones · regulatorio

### Riesgos consolidados (R1-R7)

**R1 — "El Identity Service es otra FlowMed 2.0 que tarda años; el patrón se repite".**
*Contraargumento:* Identity Service es microservicio acotado (`worker` + `client` con APIs de lectura) sobre AWS Workmed [Plataformas-20260420 18:14], independiente del calendario Secall. Workmed ha fracasado antes con reemplazos monolíticos [Finanzas-20260416 37:26; Agendamiento-20260413 47:19; Recaudacion-20260423 38:29]; este movimiento es deliberadamente acotado.
*Mitigación:* alcance Mes 1 limitado; migración por estrangulamiento, no big bang.
*Early warning:* si al Mes 6 ningún sistema downstream consume el servicio, el patrón se está repitiendo.

**R2 — Eduardo González sigue siendo punto único de falla (§6.3 mapa-cruzado).**
*Contraargumento:* Eduardo + Rodrigo con responsabilidad operativa compartida sobre el Identity Service es la respuesta explícita.
*Mitigación:* mail sobre acceso AWS RDS para Roberto/Barbarita [Recaudacion-20260423 1:25:32, 1:40:40] como hito Mes 1.
*Early warning:* si al final del Mes 1 sólo Eduardo tiene acceso, el riesgo bloquea el piloto.

**R3 — "La Ley 21.719 (1 dic 2026, 6 meses) hace inviable agregar nuevos sistemas con clínicos".**
*Contraargumento:* la Ley exige consentimiento explícito y anonimización; no prohíbe sistemas. El Identity Service **habilita** el compliance porque centraliza el consentimiento granular hoy disperso. La triple norma ISO con deadline junio es el envoltorio [Flowmed-20260409 30:52].
*Mitigación:* primer entregable incluye registro de consentimiento por trabajador y finalidad.
*Early warning:* si la asesoría legal rechaza el modelo de consentimiento al Mes 2, revisar arquitectura.

**R4 — FlowMed legacy no aguanta el volumen del crecimiento esperado.** "Lentitud creciente" ya documentada [§6.7 mapa-cruzado; Agendamiento-20260413 41:08, 40:40]: tiempos de procesamiento se degradaron a 20-25 min para nóminas grandes vs ~5 min normal. Cualquier crecimiento volumétrico significativo sobre el legacy es inviable.
*Mitigación:* la capacidad volumétrica está condicionada a FlowMed 2.0 release 1; hito Mes 6 = benchmark de carga.
*Early warning:* Mes 9 sin diseño FlowMed 2.0 cerrado = capacidad volumétrica se pausa.

**R5 — Pre-informe IA puede comprometer calidad clínica o exposición regulatoria.**
*Contraargumento:* doble contraloría humana se mantiene (la firma médica sigue siendo única autoridad legal [Top 10 RN-4]); IA solo prepara borrador. B.4 es además el primer agente del ecosistema T1 Agentes IA + Orquestador: si B.4 no escala, T1 entero queda en bitácora.
*Mitigación:* PoC Mes 6 con 100 informes y métrica rigurosa: tasa "edita el borrador" vs "acepta sin cambios".
*Early warning:* PoC con <70% aceptación o ≥1% errores = no escala. T1 (Agentes IA + Orquestador) se posterga hasta resolver la brecha.

**R6 — Capacidad de canal propio + acreditados insuficiente.**
*Contraargumento:* el pipeline de digitalización Workmed-side (B.3) opera con los 6 acreditados independientes absorbiendo la variabilidad de cada operación autónoma + 1-2 sucursales nuevas en zonas saturadas (Manuel Montt 45% [§5.2 mapa-cruzado; Operaciones-20260407 4:08]).
*Mitigación:* PoC pipeline funcionando con al menos 1-2 acreditados (partir por BestMed) como hito Mes 6.
*Early warning:* Mes 6 sin PoC pipeline funcionando con al menos 1 acreditado = la frontera digital no se materializa.

**R7 — FlowMed legacy puede degradarse durante los 6 meses hasta FlowMed 2.0 release 1.**
*Contraargumento:* "lentitud creciente" del legacy [§6.7 mapa-cruzado] + Secall errático ("2 semanas a 1 mes, a veces nunca" [Agendamiento-20260413 27:58, 44:28]) pueden llegar a paro operacional parcial.
*Mitigación:* A.2 (Portal del Cliente fase 1) y A.3 (Módulo de Producción fase 1) descargan operaciones del legacy sin requerir su modificación; observación informal del equipo TI sobre tiempos sirve como early warning intermedio; benchmark FlowMed 2.0 al Mes 6 cierra el horizonte.
*Early warning:* tiempos de procesamiento >35 min antes del Mes 4 o paro operacional ≥4 horas = escalar emergencia con Secall + acelerar release FlowMed 2.0.

### Validaciones pendientes (7)

Conversaciones con stakeholder ejecutivo antes de comprometer cada palanca:

1. **Capacidad TI real para FlowMed 2.0** (Carolina Araya): ¿el primer release sobre AWS Workmed propia es compatible con el roadmap 90/180? Hoy "FlowMed 2.0" no tiene diseño público [Plataformas-20260420 55:32].
2. **Cobertura ISO + Ley 21.719** (asesoría legal): ¿el Identity Service como frontera de consentimiento granular es defensible frente al deadline junio 2026 (ISO) y 1 dic 2026 (Ley)?
3. **Acceso AWS RDS distribuido** (Eduardo González): mail sobre acceso para Roberto/Barbarita ejecutado antes del Mes 1 [Recaudacion-20260423 1:25:32, 1:40:40].
4. **Política comercial renegociada** (Coustasse + comercial): ¿se acepta suspensión de SLA como palanca contractual de cobranza? Hoy "no hay palanca" [Recaudacion-20260423 29:16] y "le vende al que no le paga" [Recaudacion-20260423 32:26].
5. **Capacidad sostenible FlowMed 2.0 con benchmark de carga** (Carolina Araya): benchmark del primer release como prerrequisito de cualquier compromiso volumétrico. Sin benchmark, la capacidad sobre el nuevo stack es aspiracional.
6. **Apetito IA pre-informe en contraloría** (Vicente Rivano): ¿Vicente acepta el PoC con 100 informes y la métrica rigurosa? La viabilidad de T1 Agentes IA + Orquestador depende de este sí — sin B.4 escalando con calidad, T1 entero se posterga.
7. **PoC pipeline de digitalización acreditados funcionando** (Carolina + Pablo Martínez + dev interno): pipeline operando con al menos 1-2 acreditados (partir por BestMed) antes del Mes 6.

### Exposición regulatoria

- **Stack legal vigente hoy aplicable a la BD productiva FlowMed** — **Ley 19.628 art. 2 letra g)** (datos sensibles · estados de salud físicos), **Ley 16.744 + DS 109 + dictámenes SUSESO** (régimen específico de confidencialidad ocupacional: el detalle clínico no debe ser accesible al empleador ni a terceros). **Ley 20.584 art. 13** (deber de reserva) aplica con fuerza a SACMed (ficha clínica completa) y como argumento defendible-pero-secundario sobre FlowMed. La BD clon expuesta, la réplica RDS con detalle clínico y la cuenta genérica compartida con Secall **incumplen estas normas hoy**, no en el futuro.
- **Encargado de tratamiento sin contrato formal** — Secall procesa datos sensibles de Workmed sin contrato escrito de encargo verificable. Bajo Ley 19.628 (vigente) + Ley 21.719 (futura), Workmed (responsable del tratamiento) responde por todas las acciones de Secall mientras no exista ese contrato.
- **Ley 21.719 (1 dic 2026 · 6 meses para cumplir)** — añade régimen sancionatorio administrativo + DPO + ARCOP + obligación explícita de contrato de encargo con todo procesador externo. Habilita el Identity Service como frontera de consentimiento granular hoy disperso [§5.3 mapa-cruzado; Flowmed-20260409 30:02; EcosistemaTI-20260415 41:46, 42:12].
- **Triple norma ISO (junio 2026)** — envoltorio de la Ley; certificación en curso [Flowmed-20260409 30:52; EcosistemaTI-20260415 42:40].
- **Réplica AWS RDS con detalle clínico = vulnerabilidad vigente, no futura** [§5 08 riesgo 4; EcosistemaTI-20260415 43:39, 44:05]. La sovereignty + Identity Service la convierten en servicio auditado con anonimización selectiva.
- **Retención clínica obligatoria 15 años** [§5.3 mapa-cruzado; Flowmed-20260409 21:10] — no cambia bajo sovereignty pero sí su gobernanza.

---

## §8 Trazabilidad

| # | Afirmación factual | §AS-IS | Finding [mm:ss] |
|---|---|---|---|
| 1 | Producto vendible = informe de aptitud Ley 16.744 | §3.2 03-contraloria-salud | [Contraloria-20260421 6:48, 7:30] |
| 2 | Concentración 80-90% en 5-10 empresas top mineras | §5.2 00-resumen | [Comercial-20260420 21:58, 37:48] |
| 3 | Top 10 = peores pagadores simultáneamente | §3 dolor 8 mapa-cruzado | [Comercial-20260420 21:58, 24:17, 43:02] |
| 4 | Ciclo EDP 5 días/iteración | §3 dolor 2 mapa-cruzado | [Recaudacion-20260423 16:36; Agendamiento-20260413 1:09:21] |
| 5 | Caso extremo validación EDP 2 meses | §5.2 00-resumen | [Recaudacion-20260423 16:36] |
| 6 | 300-400 EDPs/mes | §5.2 00-resumen | [Recaudacion-20260423 6:06] |
| 7 | Tamaño facturas $20M-$40M; extremos $300M-$400M | §5.2 00-resumen | [Recaudacion-20260423 31:05] |
| 8 | Política comercial debilita cobranza ("le vende al que no le paga") | Top 10 RN-3 06-recaudacion | [Recaudacion-20260423 32:26] |
| 9 | "No hay palanca contractual para presionar al cliente" | §2.5 06-recaudacion | [Recaudacion-20260423 29:16] |
| 10 | Cliente fragmentado en 4 sistemas (FlowMed, HubSpot, Defontana, Power Platform) | §3 dolor 1 mapa-cruzado | [Finanzas-20260416 11:13, 11:40; Recaudacion-20260423 1:38:13] |
| 11 | Sin MPI del trabajador | §5.1 mapa-cruzado | [Agendamiento-20260413 11:48] |
| 12 | Script Python 2.553 líneas con depuración RUT > reglas de descuento | §5.6 mapa-cruzado | [Recaudacion-20260423 1:30:35, 1:31:02] |
| 13 | Errores que llegan a Contraloría/EDP ~1% (2-6 sobre ~300/día) | §5.3 00-resumen | [Agendamiento-20260413 1:09:45] |
| 14 | Lunes "explosivo" hasta 20:00 corrigiendo RUT/fecha/género | §3 dolor 6 mapa-cruzado | [Operaciones-20260407 21:23, 21:39] |
| 15 | Captura manual repetida 6+ estaciones × 700 atenciones/día | §3 dolor 6 mapa-cruzado | [Operaciones-20260407 11:43, 12:12] |
| 16 | 60% de los clientes top con convenio firmado | §5.2 00-resumen | [Comercial-20260420 12:43] |
| 17 | Universo Syncore = 3.344 trabajadores | §5.2 mapa-cruzado | [Flowmed-20260409 49:57] |
| 18 | Calculadora "Prevent" estratifica riesgo Syncore | §5.4 mapa-cruzado | [Flowmed-20260409 47:11] |
| 19 | Política no-show: Workmed no cobra inasistencias | Top 10 RN-6 | [Comercial-20260420 6:25, 6:51] |
| 20 | "No atención sin OC": 1 cliente al 100%, 1 entrando | §2.6 04-comercial RN-08 | [Comercial-20260420 25:46, 26:12] |
| 21 | Sin alertas al trabajador cuando vence un examen | §5 08 dolores cross | [Flowmed-20260409 45:44, 46:10] |
| 22 | Cambios silenciosos en catálogo detectados a 3-4 meses | §3 dolor 9 mapa-cruzado | [Comercial-20260420 44:01, 44:58] |
| 23 | Cierre de mes blando; producción se mueve retroactivamente | §3 dolor 5 mapa-cruzado | [Finanzas-20260416 7:34, 8:27] |
| 24 | Macro Excel core de EDP corrida por la Supervisora de Facturación | §2.6 06-recaudacion | [Recaudacion-20260423 1:51, 37:03] |
| 25 | Conciliación HubSpot ↔ Defontana 100% manual en Excel | §5.6 mapa-cruzado | [Recaudacion-20260423 11:52] |
| 26 | Decisión nuevo desarrollo en cuenta AWS Workmed propia | §Decisiones 08 | [Plataformas-20260420 18:14, 42:10, 1:03:20] |
| 27 | Carolina Araya pone "acelerador máximo" para FlowMed 2.0 | §5.8 mapa-cruzado | [Plataformas-20260420 1:01:32, 1:04:16] |
| 28 | Equipo TI Workmed 8-10 personas, área <3 años | §5.3 mapa-cruzado | [EcosistemaTI-20260415 36:49] |
| 29 | Secall gatekeeper técnico real BD productiva AWS RDS · Eduardo broker funcional · cuenta genérica compartida sin trazabilidad · sin contrato de encargo | §3 dolor 10 mapa-cruzado | [Recaudacion-20260423 1:25:32, 1:38:42] |
| 30 | Sin modelo de datos documentado de FlowMed | §3 dolor 10 mapa-cruzado | [Recaudacion-20260423 1:23:16] |
| 31 | Ley 21.719: vigencia 1 dic 2026, 6 meses para cumplir | §5.3 mapa-cruzado | [Flowmed-20260409 30:02; EcosistemaTI-20260415 42:12] |
| 32 | Triple norma ISO en certificación, deadline junio 2026 | §5.3 mapa-cruzado | [Flowmed-20260409 30:52; EcosistemaTI-20260415 42:40] |
| 33 | Réplica AWS con datos clínicos como vulnerabilidad de compliance | §5 08 riesgo 4 | [EcosistemaTI-20260415 43:39, 44:05] |
| 34 | Anonimización selectiva como meta declarada | §Compromisos 5.8 mapa-cruzado | [EcosistemaTI-20260415 41:46, 42:12] |
| 35 | Tabla log FlowMed = 31 GB; tabla atención = 2.2 GB | §5.3 mapa-cruzado | [Recaudacion-20260423 1:26:56, 1:27:22] |
| 36 | Retención clínica obligatoria 15 años (Ley) | §5.3 mapa-cruzado | [Flowmed-20260409 21:10] |
| 37 | Catálogo base normado SUSESO/ACHS/Mutual ~100 baterías | Top 10 RN-9 | [Comercial-20260420 46:28] |
| 38 | Tarifario congelado hace 2 años | §2.6 04-comercial RN-01 | [Comercial-20260420 27:34] |
| 39 | Meta médico contralor 6 informes/hora | §5.1 mapa-cruzado | [Contraloria-20260421 10:47, 24:45] |
| 40 | NPS Operaciones como métrica activa | §5.1 mapa-cruzado | [Operaciones-20260407 41:12] |
| 41 | Iniciativas TI fallidas: NetSuite, HubSpot↔FlowMed 2024, módulo valorización | §Sorpresas 5.5 + §5 08 dolores cross | [Finanzas-20260416 37:26, 39:06; Agendamiento-20260413 47:19, 47:48; Recaudacion-20260423 38:29, 41:43] |
| 42 | Réplica AWS desfase 5-10 min (suficiente para producto de datos) | §5.3 mapa-cruzado | [Finanzas-20260416 35:15, 40:52] |
| 43 | Equipo Finanzas + Abast + Personas endosado = 22-23 personas | §5.5 mapa-cruzado | [Finanzas-20260416 45:47, 46:16] |
| 44 | Re-envío de nómina cliente últimos 5 días del mes | §Dolores 5.6 mapa-cruzado | [Comercial-20260420 13:42] |
| 45 | Ventana de revisión cliente sobre EDP: 1-90 días sin SLA | §5.4 mapa-cruzado | [Comercial-20260420 13:42] |
| 46 | Script Python en GitHub personal de Rodrigo Llancao (en migración a GitHub de Workmed) | §5 08 riesgo 2 | [Recaudacion-20260423 1:15:49, 1:30:35, 1:38:42; Finanzas-20260416 45:17] |
| 47 | Mail acceso AWS RDS para Roberto/Barbarita pendiente | §Compromisos 5.6 mapa-cruzado | [Recaudacion-20260423 1:25:32, 1:40:40] |
| 48 | FlowMed no expone API genérica | §5 08 dolor 6; §6.8 mapa-cruzado | [Plataformas-20260420 35:00, 35:23; EcosistemaTI-20260415 3:14] |
| 49 | Soporte Secall errático: 2 semanas a 1 mes, "a veces nunca" | §5.1 mapa-cruzado | [Agendamiento-20260413 27:58, 44:28] |
| 50 | Carga "todo o nada" en agendamiento (un registro malo bota la nómina) | §5.1 mapa-cruzado | [Agendamiento-20260413 22:25] |
| 51 | "Lentitud creciente" del FlowMed legacy: 20-25 min nóminas grandes vs ~5 min normal | §6.7 mapa-cruzado | [Agendamiento-20260413 41:08, 40:40] |
| 52 | Iniciativa de valorización en FlowMed abandonada hace ~6 meses | §5 08 dolor 3; §6.5 mapa-cruzado | [Recaudacion-20260423 38:29, 38:58, 41:43; EcosistemaTI-20260415 29:38] |
| 53 | Cero capacidad TI interna respecto al core: "todo está contratado con el proveedor [Secall]" | §5 08 dolor 9 | [EcosistemaTI-20260415 36:49, 38:38, 39:00; Plataformas-20260420 35:23, 52:15, 55:32] |
| 54 | 40% atenciones en centros acreditados con transcripción manual | §3 dolor 7 mapa-cruzado | [Contraloria-20260421 12:46, 14:58] |
| 55 | Manuel Montt concentra ~45% de la actividad preocupacional nacional | §5.2 mapa-cruzado | [Operaciones-20260407 4:08] |
| 56 | Volumen diario nacional preocupacional ~400 personas/día | §5.1 mapa-cruzado | [Operaciones-20260407 30:46] |