Diagnóstico AS-IS Workmed_

Síntesis ejecutiva del levantamiento de los 7 procesos de negocio + 1 anexo de plataformas TI, con hallazgos transversales, reglas cross-proceso, KPIs consolidados, contradicciones documentadas y recomendación estratégica. Producto del trabajo de campo entre el 7 y el 23 de abril 2026 (11 sesiones, ~25 horas).

$ cat ./00-resumen-ejecutivo-as-is.md

Síntesis ejecutiva del diagnóstico AS-IS. Ver fuente completa →

Workmed es una consultora chilena de salud ocupacional con ~400 atenciones diarias a nivel nacional, donde el 90% del negocio es preocupacional y la concentración comercial es 80-90% en 5-10 empresas mineras top que coinciden con los peores pagadores. Opera 12 sucursales (6 propias + 6 acreditadas) y se compromete a una SLA interna de 8 horas entre checkout del trabajador y entrega del informe de aptitud (vs 24 h contractuales).

Entre el 7 y el 23 de abril 2026, EMERCOM SpA realizó 11 sesiones de levantamiento (~25 horas) con todos los dueños de proceso de Workmed. Producto: 7 documentos AS-IS de proceso (Agendamiento, Operaciones, Contraloría, Comercial, Finanzas, Recaudación, Abastecimiento) más 1 anexo de Plataformas y Ecosistema TI, complementados por un resumen ejecutivo, un mapa cruzado de hallazgos y una recomendación estratégica.

El diagnóstico revela un negocio operativamente sólido pero arquitectónicamente expuesto: la identidad del trabajador y del cliente vive fragmentada en 3-4 sistemas (FlowMed, HubSpot, Defontana, Power Platform) sin sincronización, el pricing está en un script Python de 2.553 líneas en GitHub personal, FlowMed sólo lee bien ~2% de los Excel del cliente, y la integración HubSpot ↔ FlowMed lleva sin existir desde 2024. La Ley 21.719 de protección de datos personales entra en vigencia el 1 de diciembre 2026 (6 meses para cumplir) y Workmed hoy no tiene capacidad para hacerlo.

La recomendación estratégica converge en una tesis: TI Sovereignty — Workmed empodera a su equipo TI con control directo sobre su infraestructura cloud, su propia plataforma central y la gobernanza de los datos (cuenta AWS Workmed propia ya decidida), dejando atrás la dependencia del partner Secall y los puntos únicos de falla actuales. Este diagnóstico AS-IS nació como prerrequisito del proyecto Orquestador de Transformación Digital de Workmed (visión TO-BE con agentes IA + orquestación de procesos). La conclusión central es que el Orquestador NO puede arrancar sobre la operación actual: la fragmentación de identidad, FlowMed legacy bajo dependencia Secall, el script de pricing en GitHub personal y la ausencia de API genérica son la frontera que primero hay que cruzar.

Antes de cualquier salto a la visión TO-BE (Agentes IA + Orquestador), la prioridad es mitigar dolores en cada proceso ya identificados en el AS-IS — esa es la base sobre la que se construye todo lo demás. La Fase 3 contiene un único track con nombre propio: T1 Agentes IA + Orquestador, condicionado al éxito del PoC pre-informe IA en B.4 (primer agente del ecosistema). El crecimiento volumétrico y los modelos contractuales avanzados (BPO outcome-based, planes anuales) emergen como consecuencia natural del saneamiento, sin tracks propios del roadmap.

$ ls ./procesos · 7 + anexo TI

Cada tarjeta enlaza al visor BPMN 2.0 interactivo del proceso. El modelado BPMN sigue el contexto de los AS-IS markdown — son la misma realidad observada, expresada en dos lenguajes complementarios (narrativo + diagramático).

El detalle completo (Lógica de Negocio, Historias de Usuario con Gherkin, Reglas de Negocio, trazabilidad finding↔§) vive en los AS-IS fuente: 01·Agendamiento · 02·Operaciones · 03·Contraloría · 04·Comercial · 05·Finanzas · 06·Recaudación · 07·Abastecimiento · 08·Plataformas TI. Documentos cross: resumen ejecutivo · mapa cruzado.

$ cat ./7-procesos/*-resumen.md

Resumen ejecutivo de cada proceso con dueño, propósito, top 3 dolores (con cita literal de finding) y KPI principal declarado. Las tarjetas arriba enlazan al visor BPMN 2.0 interactivo. El detalle granular (RNs, HUs con Gherkin, BPMN) vive en los AS-IS de diagnostico/as-is/ y en el teamspace WORKMED de Huly.

Resúmenes ejecutivos por proceso

7 procesos AS-IS + 1 anexo TI levantados entre el 7 y el 23 de abril de 2026 sobre 11 sesiones diagnósticas. Cada ficha condensa el dolor central; el detalle vive en los documentos AS-IS por proceso (diagnostico/as-is/0X-...md).

01 · Agendamiento

Dueña: Patricia Maturana ("Paty") — única autorizada a modificar el módulo de Agendamiento en FlowMed [Agendamiento-20260413 0:04, 39:49]. Equipo: 3 titulares + 2 a honorarios por hora.

Propósito: convertir solicitud externa del cliente (correo + Excel, autoagenda o carga directa) en OS confirmada en FlowMed con datos limpios y notificaciones automáticas [§1 resumen-as-is; 01 §2.1].

Top 3 dolores:

1. 98% del trabajo es copiar/pegar manual; FlowMed sólo lee bien ~2% de los formularios — "Depende. La luna, no sé." — Patricia [Agendamiento-20260413 16:08, 29:52].
2. Soporte FlowMed (Secall) errático: 2 semanas a 1 mes para nuevos formularios, "a veces nunca" [Agendamiento-20260413 27:58].
3. HubSpot ↔ FlowMed sin integración desde 2024: "las dos partes técnicas no llegaron a acuerdo" [Agendamiento-20260413 47:19, 47:48].

KPI principal: ~1% de errores que llegan a Contraloría/EDP (2-6 sobre ~300 informes/día) — medición ad-hoc, no instrumentada [Agendamiento-20260413 1:09:45].

Fuente AS-IS: Ver 01-agendamiento → · descargar .md

02 · Operaciones de campo

Dueño: Pablo Martínez (Subgerente de Operaciones); María Ignacia Sandoval (jefa de centro Manuel Montt) como punto crítico operacional.

Propósito: ejecutar la evaluación preocupacional (preadmisión, admisión, estaciones, muestras) y entregar paquete clínico a Contraloría con SLA de 8 horas desde checkout [§1 resumen-as-is; 02 §2.1].

Top 3 dolores:

1. Captura manual repetida del mismo dato en 6+ estaciones por persona [Operaciones-20260407 11:43, 12:12].
2. Distribución manual de muestras a hasta 4 LIS por persona: "tengo que detectarlo yo" — María Ignacia [Operaciones-20260407 16:22, 16:53].
3. Picos de demanda no anticipados (Fluor Salfa 120 personas, BHP 200) sin gestor de flujo [Operaciones-20260407 25:20, 44:03].

KPI principal: SLA 8 h desde checkout y ~400 personas/día atendidas en Chile (700 agendas/día con 15-17% no-show) [Operaciones-20260407 23:30, 30:46; Plataformas-20260420 53:39].

Fuente AS-IS: Ver 02-operaciones-campo → · descargar .md

03 · Contraloría de Salud (UCI)

Dueño: Vicente Rivano (Subgerente UCI, 1.5 años en el cargo) · ~12 personas en Santiago.

Propósito: emitir el informe de aptitud (apto / no apto / no apto transitorio) firmado por médico contralor, único producto vendible bajo Ley 16.744 [§1 resumen-as-is; 03 §2.1].

Top 3 dolores:

1. Digitación masiva — 40% de las atenciones vienen de centros acreditados sin integración: "los chiquillos se vuelven locos digitando" — Vicente [Contraloria-20260421 14:58, 15:27].
2. FlowMed no bloquea liberación con campos vacíos; mitigado con doble contraloría: "Se le pasa, por lo mismo, y lo liberamos igual" [Contraloria-20260421 15:54].
3. Match Operación↔Contraloría es "triple pega": Excel + WhatsApp + reporte horario [Flowmed-20260409 33:13, 33:40].

KPI principal: meta 6 informes/hora por médico contralor; SLA interno 8 h vs contractual 24 h; >50% del stock pendiente al cierre de las 19:00 [Contraloria-20260421 10:47, 17:13, 23:49].

Fuente AS-IS: Ver 03-contraloria-salud → · descargar .md

04 · Comercial

Dueños: Marcela (gestión de venta) · Juan (gerente comercial) · Ignacio Ahumada (analista de valorización).

Propósito: captar cliente B2B (mantención y construcción minera), formalizar convenio o cotización aceptada y mantener cartera viva con BI sobre Pareto y mix [§1 resumen-as-is; 04 §2.1].

Top 3 dolores:

1. Valorización mensual 100% manual y lenta (≥1 semana) — cruce Excel + script Python: "no hay un código que me cruce eso directamente" — Ignacio [Comercial-20260420 22:53, 33:37].
2. Concentración de ingresos 80-90% en 5-10 empresas top mineras, peores pagadoras [Comercial-20260420 21:58, 37:48].
3. Cambios silenciosos en catálogo de prestaciones (renombre + valor x2 sin avisar, detectado a 3-4 meses) [Comercial-20260420 44:01].

KPI principal: 80-90% de ingresos en 5-10 empresas top; 60% del top con convenio firmado [Comercial-20260420 12:43, 37:48].

Fuente AS-IS: Ver 04-comercial → · descargar .md

05 · Finanzas y EDP

Dueño: Juan Pablo Coustasse (CFO) · equipo total ~22-23 personas (Finanzas + Abastecimiento + Personas endosado).

Propósito: reconocer ingreso devengado y emitir factura mediante el ciclo EDP → OC → Factura sobre la producción cerrada por Contraloría [§1 resumen-as-is; 05 §1].

Top 3 dolores:

1. Cierre de mes "blando": FlowMed sin cierre formal; producción se mueve retroactivamente [Finanzas-20260416 7:34].
2. Núcleo de la lógica de pricing en script Python local (~2.553 líneas) en GitHub personal del autor [Recaudacion-20260423 1:30:35].
3. Cliente creado en 3+ sistemas (CRM, FlowMed, Defontana, Power Platform) sin sincronización: "estamos creando un cliente como en tres lugares […] en ninguna está completo" — Coustasse [Finanzas-20260416 11:13].

KPI principal: 300-400 EDPs/mes; ~2 días hábiles de despacho; ciclo EDP 5 días por iteración [Recaudacion-20260423 6:06].

Fuente AS-IS: Ver 05-finanzas-edp → · descargar .md

06 · Recaudación y cobranza

Dueños: Roberto (operación de recaudación) · Supervisora de Facturación (conciliación HubSpot↔Defontana) · Coustasse (gobierno financiero).

Propósito: despachar EDPs en pipelines HubSpot (Facturación + Cobranza), conciliar con Defontana y cerrar el ciclo con pago, nota de crédito o factoring [§1 resumen-as-is; 06 §1].

Top 3 dolores:

1. "Peloteo" del EDP con el cliente: casos extremos hasta 2 meses [Recaudacion-20260423 16:36].
2. Política comercial debilita cobranza ("le vende para que nos pague el que no nos paga") [Recaudacion-20260423 32:26].
3. Conciliación HubSpot ↔ Defontana 100% manual en Excel por la Supervisora de Facturación [Recaudacion-20260423 11:52].

KPI principal: 8 días corridos plazo legal de rechazo de factura; 300-400 EDPs/mes; tamaño facturas $20M-$40M típicas, $300M-$400M extremas [Recaudacion-20260423 6:06, 10:26, 31:05].

Fuente AS-IS: Ver 06-recaudacion → · descargar .md

07 · Abastecimiento policlínico

Dueña: Pamela Lastra · equipo de 4 personas; reporta a Subgerencia de Finanzas.

Propósito: reponer insumos a sedes, crear OCs en Defontana, despachar equipamiento, administrar Codelco Ventanas y validar pagos a proveedores de servicios [§1 resumen-as-is; 07 §1].

Top 3 dolores:

1. Sin medición de costo, consumo real ni merma post-despacho ("la guía se contabiliza como salida"): "ni siquiera he podido medir mi nivel de costo" — Pamela [Abastecimiento-20260423 9:34, 45:34].
2. Pamela administra sola Codelco Ventanas + suplencia de marketing 3 h/día: "si te atropellan, eh, la memoria que está ahí no se mantiene" [Abastecimiento-20260423 35:21, 38:36, 44:09].
3. Creación de OC manual desde cotizaciones incompletas — "hartos pimpones" [Abastecimiento-20260423 31:00, 32:54].

KPI principal: Stock objetivo 1.5 meses para insumos críticos (drogas, espirometría); SLA estándar despacho 1-1.5 días [Abastecimiento-20260423 2:23, 23:49].

Fuente AS-IS: Ver 07-abastecimiento → · descargar .md

08 · Anexo · Plataformas y Ecosistema TI

Dueños técnicos: Carolina Araya (CTO) · Eduardo González (Subgerente Proyectos y Transformación Digital, dueño funcional de FlowMed) · Rodrigo Llancao (BI + plataformas internas) · Christian Urbina (infraestructura) · Mónica (PMO) · ~8-10 personas; área <3 años de existencia [EcosistemaTI-20260415 36:49].

Propósito: este anexo no es un proceso de negocio sino el diccionario transversal de plataformas TI que sustenta los 7 procesos AS-IS. Inventaria FlowMed (legacy core, Secall partner), SACMed (HIS sobre GCP), Megafy/Appian (preadmisión), RobleLabs (POS biométrico), RIS Galen (radiología), TSCom (drogas), LIS LaboCenter, HubSpot (CRM + portal), Defontana (ERP), Buk (RR.HH.), Power BI, script Python de valorización, AWS Workmed propia, AWS RDS read-replica, on-premise Manuel Montt, GCP, Cloudflare, Supabase, plataformas internas (Acreditación R&S, Ficha Salud Compatible, Salud Mental), GenieMD (futuro), GitHub personal Rodrigo y agente conversacional piloto n8n+Supabase [08 §2].

Top 3 dolores:

1. FlowMed no expone API genérica: solo integraciones partner punto-a-punto; los desarrollos internos deben ir contra la base de réplica AWS [Plataformas-20260420 35:00, 35:23].
2. Núcleo de la lógica de negocio en repo personal: script Python ~2.553 líneas en GitHub personal de Rodrigo, en migración pendiente a GitHub de Workmed [Recaudacion-20260423 1:30:35; Plataformas-20260420 44:04].
3. Soberanía sobre la BD productiva FlowMed cedida a Secall: el gatekeeper técnico real del AWS RDS read-replica es Secall (proveedor externo); Eduardo es broker funcional; acceso interno vía cuenta genérica compartida sin trazabilidad; sin contrato de encargo de tratamiento; sin modelo de datos documentado de FlowMed [Recaudacion-20260423 1:23:16, 1:25:32; Finanzas-20260416 50:26].

KPI principal: réplica AWS desfase ~5-10 min; tabla log FlowMed 31 GB; tabla atención 2.2 GB; refresco Power BI cada 30 min; configuración batería nueva en SACMed ~8 horas [Finanzas-20260416 35:15; Recaudacion-20260423 1:26:56; Flowmed-20260409 1:08:39; Plataformas-20260420 59:13].

Fuente AS-IS: Ver 08-plataformas-ti → · descargar .md

$ grep -l hallazgo ./7-procesos | sort -u

Top 10 dolores cross-proceso priorizados por impacto operativo × frecuencia × magnitud económica, empate desempatado por riesgo de continuidad. No son problemas de un área — son síntomas estructurales del ecosistema. Cada dolor lleva citas dobles (§AS-IS + finding [mm:ss]).

Hallazgos transversales

Patrones que aparecen en al menos dos de los 7 procesos AS-IS levantados entre el 7 y el 23 de abril de 2026, más las 3 contradicciones críticas que bloquean decisiones futuras. La priorización combina impacto operativo (cuántos procesos toca, si bloquea decisiones aguas abajo), frecuencia y magnitud económica declarada. Los empates se desempatan por riesgo de continuidad: los puntos únicos de falla pesan más que las pérdidas tácticas. Cada hallazgo lleva doble cita §AS-IS + finding [mm:ss].

1. Identidad fragmentada del cliente y del trabajador en 3-4 sistemas sin sincronización

Severidad: ALTA Procesos afectados: agendamiento · comercial · finanzas · recaudacion · plataformas-ti

No existe un MPI (Maestro de Pacientes) ni un master de cliente único. El mismo cliente se crea manualmente en HubSpot (CRM), FlowMed (operación), Defontana (ERP) y Power Platform; el mismo trabajador puede ser evaluado 3-4 veces "como si fuera nuevo" por distintas empresas sin que el sistema lo detecte. La depuración de variantes del mismo RUT consume la sección más extensa del script Python de valorización (~2.553 líneas) [§3 dolor 1 resumen-as-is; Recaudacion-20260423 1:30:35, 1:39:12].

La sesión de Finanzas lo nombra explícitamente como dolor estructural: "el cliente hay que crearlo, no sé, con el CRM, después en el Flow, en Defontana, en el Power Platform. Estamos creando un cliente como en tres lugares […] en ninguna está completo" — Juan Pablo Coustasse [§3 dolor 1 resumen-as-is; Finanzas-20260416 11:13, 11:40]. En Recaudación se confirma desde el ángulo opuesto: "sus perfiles están rehechos en distintos sistemas y ninguno está sincronizado" — Roberto [Recaudacion-20260423 1:38:13, 1:39:12]. En Agendamiento Carolina Araya articuló el concepto MPI con su propio caso ("Carolina sigue siendo Carolina Cecilia Reyes Espinoza") [Agendamiento-20260413 10:50, 11:20].

Magnitud: estructural, toca toda la cadena (5 procesos + TI). La sección de depuración de empresas en el script Python es más extensa que el código de descuentos [Recaudacion-20260423 1:31:02]; un trabajador puede ser evaluado 3-4 veces sin detección como duplicado; cliente vivo en al menos 4 sistemas paralelos. Bloquea cualquier intento de Pareto comercial, alertas al trabajador, o cumplimiento granular de la nueva Ley de Datos Personales.

2. Errores de Agendamiento se arrastran hasta facturación y cobranza con atrasos de hasta 30 días (extremos 2 meses)

Severidad: ALTA Procesos afectados: agendamiento · operaciones · finanzas · recaudacion

Un error introducido al agendar (RUT mal escrito, centro de costo equivocado, batería desactualizada) no se detiene en el día: viaja con el evento clínico, llega al EDP, gatilla un rechazo del cliente y obliga a iterar sobre una factura ya emitida. El ciclo EDP de 5 días por iteración [§5.2 resumen-as-is; Recaudacion-20260423 6:06] multiplica cada error; los casos extremos llegan a 2 meses para devolver el EDP validado [§3 dolor 2 mapa-cruzado; Recaudacion-20260423 16:36].

En Operaciones, María Ignacia describe la cascada: "errores de agendamiento atrasan la cobranza hasta 30 días" [Operaciones-20260407 33:49]. En Agendamiento, Patricia y Rodrigo coinciden: "un error de agendamiento puede atrasar pagos por semanas" [Agendamiento-20260413 1:09:21]. En Recaudación, Roberto cuantifica el extremo: "casos extremos hasta 2 meses para devolver el EDP validado" sobre facturas que rondan $20M-$40M típicas y $300M-$400M en extremos [Recaudacion-20260423 16:36, 31:05].

Magnitud: atrasos de 30 días como estándar y 2 meses como caso extremo, sobre facturas de $20M-$40M (extremos $300M-$400M). El ciclo EDP de 5 días por iteración multiplica cada error introducido aguas arriba. La frontera entre Agendamiento y Cobranza queda visible solo en el espejo retrovisor.

3. Núcleo de la lógica de pricing en script Python local de ~2.553 líneas en GitHub personal

Severidad: ALTA Procesos afectados: comercial · finanzas · recaudacion · plataformas-ti

El módulo de precios de FlowMed es referencial; la fuente autoritativa de pricing es un script Python que vive (vivía) en el GitHub personal de Rodrigo Llancao, con ~2.553 líneas que concentran descuentos por tramo, lista, unitario, grupo, más la depuración de identidad de empresas. Eduardo González lo dice textual: "el módulo de precios de FlowMed es referencial; los scripts son los que tienen los precios autorizados" [§3 dolor 3 resumen-as-is; Recaudacion-20260423 1:30:35, 1:38:42; Finanzas-20260416 45:17].

Roberto sintetiza por qué importa: "ahí es donde realmente existe la regla de negocio porque ahí es donde se calcula" [Recaudacion-20260423 1:30:35]. Ignacio Ahumada es el operador único; Rodrigo Llancao es el autor único. La migración del repo personal a GitHub de Workmed con Christian Urbina está en curso pero aún no completa [Plataformas-20260420 44:04, 44:26]. Mientras tanto, toda la valorización de Workmed depende de un solo desarrollador y un solo operador, sobre un repo personal.

Magnitud: toda la valorización mensual (300-400 EDPs / mes); ejemplo cuantificado: descuento Syncore ~16% sobre 750 personas = ~$33M sobre ~$208M [Recaudacion-20260423 1:34:06]. Sin redundancia humana, sin documentación operativa, sin gobierno del repo de origen.

4. HubSpot ↔ FlowMed sin integración (intento 2024 fracasado, queda manual indefinidamente)

Severidad: ALTA Procesos afectados: agendamiento · comercial · recaudacion · plataformas-ti

El intento 2024 de integrar el CRM con el core operativo "no llegó a acuerdo entre las partes técnicas" y quedó pendiente sin fecha. Esto deja al equipo Comercial sin BI accionable (cluster, mix, frecuencia, upsell), obliga al cierre manual de la cola "agenda por confirmar", y fuerza la conciliación HubSpot ↔ Defontana como hoja Excel manual de la supervisora de Facturación [§3 dolor 4 resumen-as-is; Agendamiento-20260413 47:19, 47:48].

En Comercial, Marcela lo describe así: "no estoy conectado con FlowMed […] no puedo hacer cluster de clientes, qué batería compra cada uno" [Comercial-20260420 52:10, 52:37]. En Agendamiento, Patricia confirma que la cola de tickets en HubSpot se transfiere copy-paste a FlowMed porque "las dos partes técnicas no llegaron a acuerdo" [Agendamiento-20260413 47:48]. Hay un proyecto distinto activo (HubSpot ↔ Defontana, no el de FlowMed); a no confundir.

Magnitud: 1 día de desfase estructural en la información comercial que llega al dashboard; ciclo de valorización ≥1 semana porque no existe el join automático que rompa el copy-paste. Bloquea Pareto, alertas al cliente y agente conversacional comercial.

5. Cierre de mes "blando" en FlowMed: producción se mueve retroactivamente

Severidad: ALTA Procesos afectados: operaciones · contraloria · finanzas · recaudacion

FlowMed no tiene un cierre formal de mes: las atenciones de marzo siguen llegando en abril (cultivos 3-4 días hábiles, metales 15 días hábiles), lo que obliga a doble descarga + comparación detectivesca para conciliar producción con valorización. La producción final no llega antes del día 5-6 y los últimos EDPs salen recién el día 9 [§3 dolor 5 resumen-as-is; Finanzas-20260416 7:34, 8:27].

Coustasse lo describe: "tenemos producción que se mueve retroactivamente; no hay un corte limpio" [Finanzas-20260416 7:34]. En Recaudación, Roberto e Ignacio cuantifican: "perdemos 2-3 días de ventaja para facturar cada mes" porque el cierre se cocina contra un blanco móvil [Recaudacion-20260423 36:33, 1:33:37, 1:35:04]. En Contraloría, los tiempos de espera de exámenes (cultivos 3-4 días hábiles; metales 15 días hábiles) son la causa estructural [Contraloria-20260421 24:15].

Magnitud: pérdida sistemática de 2-3 días de ventaja para facturar cada mes. Gatillante directo del 8 días corridos legales para rechazo de factura: si la factura sale el 9 y el cliente la rechaza el 17, no queda ventana de respuesta interna.

6. Captura manual repetida del mismo dato del trabajador en 6+ estaciones por persona/día

Severidad: ALTA Procesos afectados: operaciones · contraloria

El mismo dato del trabajador (RUT, nombre, fecha de nacimiento, batería, centro de costo) se vuelve a tipear en cada estación clínica y en cada handoff: lo escribe el cliente en el Excel, lo re-tipea Agendamiento en FlowMed, lo re-tipea la TENS en cada estación del HIS, lo re-digita el administrativo de Contraloría desde un PDF de SharePoint. No existe un identificador único que viaje sin transformación a lo largo del ciclo [§3 dolor 6 resumen-as-is; Operaciones-20260407 11:43, 12:12].

María Ignacia lo nombra como dolor concreto: "el mismo dato puede ingresarse 6+ veces para una sola persona en un día" [Operaciones-20260407 11:43, 12:12]. La consecuencia organizacional la describe ella misma: "el día lunes me revienta la agenda. Me la revienta, me la revienta, me la revienta" — los lunes "explosivos" se quedan hasta las 20:00 corrigiendo errores [Operaciones-20260407 21:23, 21:39, 44:03]. Sin gestor de flujo, las jefas mueven carpetas físicas para hacer el match.

Magnitud: 700 atenciones/día (~400 en preocupacional nacional + sus dependencias) × 6+ ingresos manuales por persona [Plataformas-20260420 53:39; Operaciones-20260407 30:46]. Lunes "explosivos" sostenidos hasta las 20:00 todas las semanas; 15-17% de no asistencia que también se gestiona a mano.

7. 40% de las atenciones provienen de centros acreditados que reportan vía OneDrive/SharePoint con transcripción manual

Severidad: ALTA Procesos afectados: operaciones · contraloria

De las 12 sucursales, 6 son propias (con SACMed, Megafy, RobleLabs e integraciones) y 6 son acreditadas (Red Salud, Copia a Po y otras) que operan con papel + escaneo + carga manual a OneDrive/SharePoint. Esto rompe la promesa "FlowMed = 100%" y es la fuente principal de la digitación masiva en Contraloría [§3 dolor 7 resumen-as-is; Contraloria-20260421 12:46, 14:58].

Vicente Rivano lo resume sin matices: "¿Dónde se va el mayor esfuerzo? Digitando. Efectivamente, digitando, al final es digitar" — y "los chiquillos se vuelven locos digitando" [Contraloria-20260421 14:58, 15:27]. En Operaciones se explicita: "todos los pacientes de Workmed pasan por Megafy salvo los de centros acreditados, que no tienen los mismos flujos" [Operaciones-20260407 17:15, 1:02:08]. En Ecosistema TI, Eduardo lo confirma: "centros franquiciados/acreditados aún operan con papel + escaneo […] 100% transcripción manual".

Magnitud: ~280 atenciones/día digitadas a mano (40% de ~700 atenciones diarias en pico). Sin firma biométrica, sin validación digital de documentos, sin trazabilidad inicial. Munición para que el cliente rechace el EDP cuando el centro acreditado mide más prestaciones de las pedidas (legalmente debe informar 10 drogas aunque el cliente pida 5).

8. Concentración de ingresos 80-90% en 5-10 empresas mineras top que coinciden con los peores pagadores

Severidad: ALTA Procesos afectados: comercial · recaudacion

El Pareto comercial coincide con el Pareto inverso de cobranza: los mismos 5-10 clientes top minera (mantención y construcción) que generan el 80-90% del ingreso son los que peor pagan. Esto convierte la cobranza en una bola de nieve estructural, no en un problema operativo. El descuento por pronto pago del 2% "no mueve la aguja" sobre EDPs de $500M [§3 dolor 8 resumen-as-is; Comercial-20260420 21:58, 24:17, 37:48, 43:02].

Marcela lo dice sin filtro: "top 10 en construcción/montaje minero = los peores pagadores y los mejores clientes simultáneamente" [Comercial-20260420 21:58, 43:02]. En Recaudación se cierra el ciclo: la política comercial debilita la cobranza desde adentro ("le vende al que no le paga") [Recaudacion-20260423 32:26] y "no tenemos con qué apretar, con qué presionar; no hay un porcentaje, no hay nada legal en este contexto" — Juan Pablo [Recaudacion-20260423 29:16].

Magnitud: 80-90% del ingreso mensual concentrado en 5-10 cuentas; descuento pronto pago 2% insuficiente sobre EDPs de $500M; "no atención sin OC" aplica al 100% solo a 1 cliente y 1 entrando, el resto opera sin esa palanca.

9. Cambios silenciosos en catálogo de prestaciones detectados 3-4 meses después

Severidad: ALTA Procesos afectados: comercial · finanzas · recaudacion

Un proveedor de informática renombró una prestación y la valorizó al doble sin avisar; toda la producción salió mal hasta que se detectó ~3-4 meses después. Los IDs padre/hijo de las baterías son opacos al editor; no hay versionado del catálogo; cero gobernanza de datos maestros [§3 dolor 9 resumen-as-is; Comercial-20260420 44:01, 44:58, 49:20].

Marcela lo describe como incidente real: "renombró una prestación y la valorizó al doble sin avisar; toda la producción salió mal hasta que se detectó (~3-4 meses después)" [Comercial-20260420 44:01]. En Plataformas Internas, Rodrigo confirma la otra cara: "Comercial vende baterías que no existen en el sistema y al cobrar hay que armar manualmente" [Plataformas-20260420 57:20]. La configuración de una batería nueva en SACMed depende del proveedor y demora ~8 horas.

Magnitud: 3-4 meses de producción mal valorizada antes de la detección; catálogo de ~100 baterías base SUSESO/ACHS/Mutual + baterías personalizadas por cliente, todas sin versionado público. Una sola incidencia equivale a meses de EDPs que hay que rehacer hacia atrás.

10. Soberanía sobre la BD productiva FlowMed cedida a Secall · cuenta genérica compartida sin trazabilidad

Severidad: ALTA (revisado mayo 2026 con información complementaria post-levantamiento) Procesos afectados: recaudacion · plataformas-ti · compliance

El gatekeeper técnico real de la BD productiva FlowMed en AWS RDS read-replica (la única vía por la cual las plataformas internas, Power BI y el script Python pueden tocar datos productivos) es Secall, no Eduardo. Eduardo González opera como broker funcional: solicita accesos a Secall y los redistribuye internamente. El acceso interno se distribuye vía cuenta genérica compartida entre Eduardo + Rodrigo + Ignacio + ¿otros?, posiblemente incluyendo personal de Secall, sin trazabilidad por persona. Sin contrato formal de encargo de tratamiento de datos verificable con Secall. Sin modelo de datos documentado de FlowMed; las tablas grandes (log 31 GB, atención 2.2 GB, otras dos ~13 GB c/u) sin gobernanza documental [§3 dolor 10 resumen-as-is; Recaudacion-20260423 1:23:16, 1:25:32; Finanzas-20260416 50:26].

Roberto lo nombra: "toda solicitud de visualizador pasa por Eduardo, sin backup explícito documentado" [Recaudacion-20260423 1:25:32, 1:38:42] — entendiéndose hoy que Eduardo es el broker funcional, no el SPOF técnico (la cuenta genérica permite que otros accedan; pero el control técnico real lo tiene Secall). Mónica complementa desde Finanzas: "no hay réplica externa o servidor interno por contingencia más allá de la réplica AWS; si se cae Amazon, ahí tenemos otros problemas" [Finanzas-20260416 50:26]. Ignacio lo enuncia explícitamente desde el modelo de datos: "no hay modelo de datos documentado de FlowMed".

Magnitud: soberanía operacional y legal cedida a un proveedor externo con "soporte 2 semanas a nunca". Cualquier cambio de IAM, configuración de red o auditoría depende de que Secall ejecute. La cuenta genérica compartida hace imposible cumplir hoy el deber de Ley 19.628 (datos sensibles · estados de salud) y Ley 16.744/DS 109 (régimen confidencialidad ocupacional) de demostrar quién accedió a qué dato sensible. Bajo Ley 21.719 (1-dic-2026), Secall sería formalmente "encargado de tratamiento" — exige contrato escrito que hoy no existe verificable. Bloquea cualquier modernización (FlowMed 2.0, Identity Service, agente conversacional) hasta que el acceso esté individualizado y el contrato cerrado.

11. Gobernanza de datos ausente como capa común detrás de los hallazgos previos

Severidad: ALTA Procesos afectados: todos · plataformas-ti

Los hallazgos 1, 3, 9 y 10 — junto con los puntos de fricción de Power BI y el cierre blando de mes — no son problemas técnicos independientes; son síntomas de una capa de gobernanza de datos ausente. Workmed tiene sistemas, datos y operadores, pero no tiene dueños formales por dominio, ni políticas de versionado, ni comité de cambios, ni inventario de tratamientos, ni DPO designado. María Ignacia lo nombra explícitamente desde Operaciones: "datos en silos: cada área inventó su propia captura, sin gobernanza" [Operaciones-20260407 51:32, 52:19]. La cita es la única vez que la palabra aparece como diagnóstico en las sesiones; el resto se manifiesta como dolores aislados.

Patrones concretos que sólo se entienden desde gobernanza ausente:

• Identidad fragmentada en 4 sistemas sin owner del cliente canónico [§hallazgo 1; Finanzas-20260416 11:13, 11:40] — nadie decide cuál es el master.
• Catálogo de prestaciones cambia silenciosamente, detectado a 3-4 meses [§hallazgo 9; Comercial-20260420 44:01] — sin owner, sin versionado, sin notificación, sin aprobación.
• Modelo de datos de FlowMed no documentado [§hallazgo 10; Recaudacion-20260423 1:23:16] — nadie es dueño del modelo.
• Power BI: cuentas paralelas con dashboards "dando vuelta" sin auditoría de acceso (todos entran con la misma cuenta), sin control de versiones — workaround: renombrar archivos v2.1, v3.1 [Flowmed-20260409 1:04:16, 1:06:32, 1:08:39].
• Script Python pricing: ~2.553 líneas, sin owner formal de los cambios, sin comité que apruebe modificaciones a las reglas de descuento [§hallazgo 3].
• Cierre blando de mes: producción retroactiva, "100 filas el 31 → 150 el 1" [§hallazgo 5; Finanzas-20260416 7:34, 8:27] — nadie cierra los datos.
• Sobre-reporte de centros acreditados [Recaudacion-20260423 56:07] — nadie reconcilia.
• Ambigüedad dueño FlowMed: Eduardo (sistema) vs Patricia (módulo) [§6.11 mapa-cruzado] — la propia nomenclatura de "dueño" es difusa.
• Tres iniciativas previas fallidas (NetSuite, HubSpot↔FlowMed 2024, módulo de valorización abandonado): el módulo de valorización se abandonó "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, 42:13] — gobernanza pura, no técnica.

Compliance regulatorio sin base: la Ley 21.719 (vigencia 1 dic 2026, 6 meses) exige consentimiento granular, base legal explícita, inventario de tratamientos y un DPO formal. La triple norma ISO (junio 2026: 9001 + 14001 + 45001) exige control documental, trazabilidad y auditorías. Sobre la operación actual, ambas auditorías se hacen sobre arena: no existe inventario de tratamientos, no hay DPO designado, los dashboards no son auditables, los catálogos no están versionados.

Magnitud: estructural y atemporal. La TI Sovereignty da control técnico (cuenta AWS propia, FlowMed 2.0, Identity Service, GitHub de Workmed), pero el control técnico sin gobernanza es vacío: una plataforma propia mal gobernada hereda los mismos dolores con stack nuevo. Por eso gobernanza de datos no es un pilar paralelo: es la capa interna de la TI Sovereignty que decide quién es dueño de qué dato, qué cambios necesitan aprobación, qué se versiona y cómo se audita.

Contradicciones críticas

De las 11 contradicciones documentadas en el mapa cruzado, las 3 que bloquean decisiones futuras y deben resolverse antes de la fase de recomendación:

C1. Fuente de verdad clínica disputada (FlowMed vs SACMed vs ficha papel)

Severidad: ALTA Procesos afectados: operaciones · contraloria · plataformas-ti

Tres versiones simultáneas y mutuamente incompatibles:

• Rodrigo afirma "FlowMed vuelve a tener el 100% de todo" [Flowmed-20260409 23:53, 1:00:21].
• Eduardo describe comunicación unidireccional ficha → Contraloría con "dos repositorios paralelos con riesgo de descalce" [EcosistemaTI-20260415 24:25, 24:52].
• Vicente trabaja con dos orígenes según sucursal: SACMed para 6 propias, SharePoint con digitación manual para 6 acreditadas [Contraloria-20260421 12:46].

Por qué bloquea: define dónde vive el dato clínico, y con eso la deduplicación, el MPI, el modelo de consentimiento y el cumplimiento de la nueva Ley de Datos Personales 21.719 (vigencia 1 dic 2026, 6 meses para cumplir). No se puede diseñar Identity Service ni FlowMed 2.0 sin resolver primero esta pregunta. Próximo paso: consolidar versión canónica con Eduardo González y Christian Urbina.

C2. Hosting de FlowMed: on-premise raqueado vs sólo réplica AWS

Severidad: ALTA Procesos afectados: plataformas-ti · operaciones · recaudacion

Versión Eduardo (dueño técnico, fuente autorizada): servidor on-premise raqueado en Manuel Montt + réplica caliente AWS RDS con desfase ~5-10 min [EcosistemaTI-20260415 33:37, 34:58, 35:22]. Versión Coustasse / Marcela / Rodrigo: solo réplica AWS desfasada 5-10 min, sin on-prem [Finanzas-20260416 35:15, 40:52; Recaudacion-20260423 1:15:49]. La versión canónica es la de Eduardo, pero la información parcial circulando en otras subgerencias produce decisiones inconsistentes.

Por qué bloquea: define qué se migra, qué se replica y desde dónde para FlowMed 2.0. La réplica caliente con datos clínicos es además una vulnerabilidad de compliance bajo la nueva Ley [EcosistemaTI-20260415 43:39, 44:05]. Próximo paso: dejar versión canónica documentada en 08-plataformas-ti.md y comunicarla al comité ejecutivo.

C3. Soberanía sobre la BD productiva FlowMed cedida a Secall · cuenta genérica compartida

Severidad: ALTA (revisado mayo 2026) Procesos afectados: plataformas-ti · recaudacion · compliance

Subordinada y condicionada por C2: si el hosting es como dice Eduardo, la dependencia técnica del proveedor externo Secall para todo cambio de IAM/red/auditoría sobre AWS RDS es estructural. La cadena de valorización (script Python → EDP → factura) y todas las plataformas internas (Salud Compatible, Salud Mental, agente piloto) dependen de un proveedor externo con "soporte 2 semanas a nunca" + una cuenta genérica compartida sin trazabilidad por persona [Recaudacion-20260423 1:23:16, 1:25:32; Finanzas-20260416 50:26].

Por qué bloquea: condiciona §C2 y la operación diaria del script Python. La respuesta inicial del diagnóstico fue "Eduardo + Rodrigo con responsabilidad operativa compartida" + mail de acceso para Roberto/Barbarita; tras el aporte de mayo 2026, la respuesta correcta es (a) apretar contrato con Secall (SLA + auditoría + obligaciones de Ley 19.628/21.719 como encargado de tratamiento), (b) acceso administrativo paralelo Workmed sobre el RDS, (c) individualizar credenciales y cerrar la cuenta genérica [Recaudacion-20260423 1:25:32, 1:40:40]. Próximo paso: ejecutar (a)+(b)+(c) como hito Mes 1, antes de cualquier otro entregable de FlowMed 2.0 o del Identity Service.

$ grep -l 'RN-' ./7-procesos | sort -u

Reglas que aparecen en más de un proceso o que son base del modelo operativo de Workmed (compliance, control financiero, cartera). Cada RN incluye procesos donde aplica y citas con finding+timestamp.

Top 10 reglas de negocio cross-proceso

Reglas que aparecen en más de un proceso o que actúan como base estructural de Workmed (compliance regulatorio, control financiero, modo de operar). Cada regla está fijada por al menos dos procesos AS-IS distintos: si fuera de un solo proceso, no clasificaría aquí (esas quedan al pie del documento). El criterio de inclusión es transversalidad y carácter no negociable: o bien proviene de la Ley 16.744 y su ecosistema regulatorio, o bien condiciona la gobernanza financiera, o bien define cómo Workmed se relaciona contractualmente con sus clientes top.

RN-1 · Plazo legal de 8 días corridos para rechazo de factura desde emisión

Procesos afectados: Finanzas y EDP (05) · Recaudación y cobranza (06).

Es el único hito duro del pipeline de cobranza. Una vez emitido el DTE, el cliente tiene 8 días corridos para rechazar la factura por la vía formal SII; pasado ese plazo la factura queda firme y entra en el ciclo de pago (o de mora, según corresponda). Toda la presión sobre el calendario de cierre de mes se origina aquí: si la producción final no llega antes del día 5-6 y los últimos EDPs salen el día 9 [Recaudacion-20260423 36:33], la ventana interna de respuesta a un rechazo desaparece.

La regla aparece literal en 05 §2.4 RN-FIN-03 y en 06 §2.2 RN-2.2.2, citada en sesión por Roberto Carvajal y Juan Pablo Coustasse [Recaudacion-20260423 10:26, 29:42]. Implicación operativa: cualquier visión TO-BE (Agentes IA, Orquestador, EDP continuo, modelos contractuales avanzados como consecuencia del saneamiento) debe respetar este plazo como restricción dura, no como objetivo a optimizar.

RN-2 · Reconocimiento contable sobre producción devengada (no sobre facturación)

Procesos afectados: Contraloría de Salud (03) · Finanzas y EDP (05).

El ingreso se reconoce al cerrar el informe de aptitud en Contraloría (producción devengada Ley 16.744), no al emitir la factura. Contablemente la producción se acumula en la cuenta "Estados de pago por facturar" y migra a "Deudores comerciales" sólo cuando se emite el DTE. Esta separación es la razón por la que el cierre de mes "blando" en FlowMed [§3 dolor 5; Finanzas-20260416 7:34] tiene impacto contable: cada atención que se mueve retroactivamente reabre el devengo.

La regla está fijada en 05 §2.4 RN-FIN-01 y citada por Coustasse [Finanzas-20260416 23:57, 24:27]. Implicación: si Workmed eventualmente adopta modelos contractuales avanzados (cuota fija por dotación cubierta como consecuencia natural del saneamiento), el devengo dejaría de estar atado a la atención individual y pasaría a estar atado al cumplimiento del SLA "% aptitud vigente" — un cambio de unidad de medida contable, no sólo comercial.

RN-3 · SLA del informe de aptitud: 8 horas internas desde checkout vs 24 horas contractuales

Procesos afectados: Operaciones de campo (02) · Contraloría de Salud (03).

Workmed se compromete contractualmente con sus clientes top a entregar el informe de aptitud en 24 horas desde el checkout del trabajador, pero internamente opera con un SLA más exigente de 8 horas. La diferencia es deliberada: las 16 horas de margen absorben tiempos de espera de exámenes (cultivos 3-4 días hábiles, metales 15 días hábiles [Contraloria-20260421 24:15]) y los rebotes por digitación masiva de centros acreditados.

Citada por María Ignacia Sandoval y Vicente Rivano [Operaciones-20260407 23:30; Contraloria-20260421 17:13, 17:38]; fijada en 02 §2.4 RN-06 y 03 §2.4 RN-12. Implicación: cualquier SLA agregado (ej. "aptitud vigente >95%" si surge un modelo contractual avanzado) no reemplaza este SLA puntual; lo subordina. El informe sigue siendo el evento clínico-legal aunque eventualmente cambie la unidad de facturación.

RN-4 · Doble contraloría obligatoria: administrativo + médico contralor

Procesos afectados: Operaciones de campo (02) · Contraloría de Salud (03).

Cada informe atraviesa dos manos: un administrativo arma el preinforme con los datos clínicos (digitando o consumiendo desde SACMed/SharePoint) y un médico contralor lo firma. Sólo la firma médica es autoridad legal para liberar el apto/no apto/no apto transitorio bajo Ley 16.744. La doble pasada existe porque FlowMed no bloquea liberación con campos vacíos [Contraloria-20260421 15:54]: la mitigación es humana, no sistémica.

Fijada en 03 §2.4 RN-02; citada por Vicente Rivano [Contraloria-20260421 3:25, 15:27]. Implicación: cualquier reducción del costo de digitación masiva (vía Identity Service, integración acreditados, eliminación de SharePoint) debe preservar la firma médica como capa terminal — no es un control redundante sino el contrato legal con el regulador.

RN-5 · "No atención sin OC" para clientes grandes

Procesos afectados: Comercial (04) · Recaudación y cobranza (06).

Política comercial dura: a un cliente top se le exige Orden de Compra emitida antes de atender, sin excepciones. Hoy se aplica al 100% sólo a 1 cliente y otra entrando [Comercial-20260420 25:46, 26:12]. El resto opera sin esa palanca contractual, lo que alimenta la bola de nieve de cobranza estructural sobre el top 10. Es el ejemplo más nítido de que el cliente sí acepta condiciones cuando Workmed las pide.

Fijada en 04 §2.4 RN-08; citada por Marcela [Comercial-20260420 25:46]. Implicación: la regla demuestra que la palanca contractual existe; la pregunta es si Workmed la generaliza vía suspensión de SLA por mora como cláusula contractual estándar (B.8 cierre contractual del mes con clientes top + alineación operativa).

RN-6 · Política de no-show: Workmed no cobra inasistencias

Procesos afectados: Operaciones de campo (02) · Comercial (04) · Finanzas y EDP (05).

Cuando el trabajador no se presenta a su cita, Workmed no factura. El cobro se activa sólo al atender y emitir informe. Con tasas de no-show del 15-17% sobre 700 agendas/día [Plataformas-20260420 53:39], esto es regalar entre 100 y 120 atenciones diarias al cliente. La política es histórica y nunca se renegoció.

Fijada en 04 §2.4 RN-07; citada por Marcela [Comercial-20260420 6:25, 6:51]. Implicación: la absorción del no-show es parte de la propuesta de valor histórica de Workmed con su cartera top — práctica que la diferencia de otros prestadores. Mientras tanto, C.4 instrumenta y reporta el no-show por cliente (visibilidad mensual del servicio extra que recibe + umbral recomendado como norma cultural compartida) sin imponer cláusula contractual, respetando el modelo histórico. Si Workmed eventualmente activa modelos contractuales avanzados (tarifa fija por dotación cubierta · consecuencia natural del saneamiento), la inasistencia deja de ser pérdida y pasa a ser problema del cliente — pero esa renegociación queda para B.8 cierre contractual del mes con clientes top.

RN-7 · Tramos de descuento por volumen con recálculo retroactivo intra-mes

Procesos afectados: Comercial (04) · Finanzas y EDP (05) · Recaudación y cobranza (06).

Sobre el catálogo base se aplican tramos: 5% a 100 pacientes, 10% a 200, 12% a 500. Si un cliente cruza un tramo a mitad de mes, se recalcula retroactivamente sobre toda la producción del mes. El ejemplo cuantificado: descuento Syncore ~16% sobre 750 personas = ~$33M sobre ~$208M [Recaudacion-20260423 1:34:06]. Esta lógica vive en el script Python de 2.553 líneas porque FlowMed no la soporta.

Fijada en 04 §2.4 RN-02 / RN-03, 05 §2.4 RN-FIN-02, 06 §2.4 RN-9; citada por Marcela y Roberto [Comercial-20260420 27:34, 34:36; Recaudacion-20260423 1:31:31]. Implicación: cualquier migración del pricing fuera del script local debe preservar el recálculo retroactivo o renegociar contractualmente la regla con cada cliente top — el caso más probable es mantener la regla pero migrarla a servicio, conservando el módulo de depuración de RUT que es la pieza más cara del script.

RN-8 · Umbrales de aprobación de OC (gobernanza financiera)

Procesos afectados: Finanzas y EDP (05) · Abastecimiento policlínico (07).

Cadena de autorización de Órdenes de Compra:

• ≤ $1M: Pamela Lastra sola.
• $1M – $3M: Pamela + Coustasse (CFO).
• > $3M: Claudio Jorquera.
• Inversión grande: comité Ricardo Jorquera + Max Dollmann.

Fijada en 05 §2.4 RN-FIN-07 y 07 §2.2 RN-04; citada por Pamela [Abastecimiento-20260423 37:14, 37:42]. Implicación: la regla es la única gobernanza financiera explícita y escalonada del corpus AS-IS. Cualquier proyecto TO-BE (Identity Service, FlowMed 2.0, policlínicos modulares, Orquestador) tiene que pasar por estos umbrales. El comité Jorquera + Dollmann es el techo decisional para el CAPEX de la sovereignty.

RN-9 · Catálogo base normado por mutualidades — el cliente sube el estándar pero nunca lo baja

Procesos afectados: Operaciones de campo (02) · Comercial (04).

Las ~100 baterías base SUSESO/ACHS/Mutual son el piso normativo. Un cliente puede agregar exámenes al catálogo (riesgo específico de su faena), pero no puede pedir menos que la batería base correspondiente. Esto fija el costo mínimo del producto y bloquea la presión deflacionaria del cliente top, aunque no impide los descuentos por volumen del RN-7.

Fijada en 04 §2.4 RN-04; citada por Marcela [Comercial-20260420 46:28, 47:24]. Implicación: el catálogo base es activo regulatorio, no comercial. Si Workmed eventualmente activa planes anuales o modelos contractuales avanzados (consecuencia natural del saneamiento), este catálogo sería el contrato técnico de cada plan.

RN-10 · Cartera estricta en Facturación y Cobranza: "nadie toca clientes que no son de ellos"

Procesos afectados: Finanzas y EDP (05) · Recaudación y cobranza (06).

Cada ejecutiva de cobranza tiene su cartera asignada y la regla operativa es no cruzar fronteras: ni para subsanar errores, ni para cubrir vacaciones, ni para acelerar gestiones. Esto hace que la conciliación HubSpot↔Defontana caiga 100% sobre la Supervisora de Facturación [Recaudacion-20260423 11:52] como única figura transversal, y que cualquier cuello de botella en una cartera específica se quede atascado allí.

Fijada en 05 §2.4 RN-FIN-06 y 06 §2.4 RN-4; citada por Roberto [Recaudacion-20260423 37:32, 37:59]. Implicación: si emergen modelos contractuales avanzados como consecuencia del saneamiento, las carteras transaccionales podrían ceder paso a dueños de SLA por contrato — la cartera dejaría de ser unidad organizacional para pasar a ser unidad contractual.

Reglas que quedaron fuera del Top 10

Existen reglas adicionales con peso real pero acotadas a un solo proceso, por lo que no clasifican como cross-proceso:

• RN-01 Agendamiento: Patricia Maturana es la única autoridad funcional sobre el módulo (formularios, prestaciones, masificación) [01 §2.4]. Es punto único de falla pero opera en una sola capa.
• RN-08 Operaciones: los operativos en terreno se consideran servicio prestado, no agendamiento delegado [02 §2.4].
• RN-08 Contraloría: la homologación CODELCO funciona como base normativa específica [03 §2.4].
• RN-FIN-03 Abastecimiento: stock obligatorio del carro de paro en Codelco Ventanas bajo resolución sanitaria [07 §2.4 RN-07] — regla regulatoria pero local a una sucursal heredada.

Estas reglas no son menos importantes: simplemente no construyen patrón cruzado y por eso viven en sus documentos AS-IS individuales.

$ awk '/KPI/' ./7-procesos/*.md

Las 45 cifras declaradas en sesión (2026-04-07 al 2026-04-23) consolidadas en 3 tablas: volumen y SLAs operativos · ciclo comercial y financiero · agendamiento, abastecimiento e infraestructura. Son la línea base AS-IS contra la cual se contrastan las cifras esperadas en la recomendación estratégica (§B.10).

KPIs declarados consolidados

Las 45 cifras que siguen son las declaradas literalmente en sesión entre el 7 y el 23 de abril de 2026. No son objetivos, no son estimaciones de Emercom, no son benchmarks externos: son los números que dueños de proceso y stakeholders técnicos verbalizaron como estado actual de Workmed. Cada cifra conserva el valor exacto pronunciado y va con cita doble (§AS-IS + finding).

Su utilidad es doble. Operan como baseline AS-IS: el contraste contra estas cifras es el que hace cuantificable cualquier propuesta TO-BE (ver 10-recomendacion-impacto-kpis.md). Y operan como memoria de sesión: si una cifra cambia entre AS-IS y el primer comité de seguimiento, la diferencia se rastrea aquí.

Las tres tablas siguientes preservan la organización del documento fuente (§5 del resumen ejecutivo AS-IS): volumen y SLAs operativos, ciclo comercial y financiero, y agendamiento + abastecimiento + infraestructura.

Volumen y SLAs operativos

Ciclo comercial y financiero

Agendamiento, abastecimiento e infraestructura

Cómo leer estas cifras

Tres lecturas son útiles antes de pasar al TO-BE:

1. El cuello de botella temporal vive en el cierre de mes: producción final llega entre los días 1 y 1,5 del mes siguiente, los últimos EDPs salen el día 9 y el plazo legal de rechazo es 8 días corridos. La ventana interna de respuesta a un rechazo cabe en horas, no en días.
2. El cuello de botella de identidad está cuantificado: ~1% de errores llegan a Contraloría/EDP (2-6 sobre 300 informes/día), 40% de las atenciones vienen de centros acreditados con digitación manual y la depuración de RUT consume la sección más larga del script Python de 2.553 líneas.
3. El cuello de botella comercial es estructural: 80-90% de ingresos en 5-10 empresas que coinciden con los peores pagadores, ciclo EDP 5 días por iteración con extremos de 2 meses sobre facturas de hasta $300M-$400M. El descuento por pronto pago de 2% "no mueve la aguja".

El documento 10-recomendacion-impacto-kpis.md toma 14 de estas cifras y las contrasta contra la cifra esperada bajo la tesis TI Sovereignty + saneamiento + visión TO-BE T1 Agentes IA + Orquestador.

$ diff ./testimonios/*.md

Las 11 contradicciones documentadas en el mapa cruzado, ordenadas: 3 críticas que bloquean decisiones futuras (fuente de verdad clínica · hosting FlowMed · soberanía sobre la BD productiva cedida a Secall + cuenta genérica compartida) seguidas de 8 secundarias acotadas a un ámbito específico. Cada contradicción incluye partes en disputa con cita literal y próximo paso para resolverla.

Contradicciones documentadas

Una contradicción es una afirmación factual sobre un mismo objeto (sistema, hosting, dato, rol, capacidad, KPI) sostenida con versiones incompatibles por dos o más informantes en sesiones distintas. No son errores de testimonio sino zonas de conocimiento parcializado que bloquean decisiones aguas abajo: si no se resuelven, cualquier roadmap se construye sobre arena.

El corpus levantó 11 contradicciones entre 2026-04-07 y 2026-04-23. 3 son de severidad alta y bloquean el diseño de FlowMed 2.0, el Identity Service y el cumplimiento de la Ley 21.719. Las 8 restantes tienen severidad media o baja y se resuelven con consultas dirigidas o desambiguación terminológica. Cada una tiene partes en disputa con cita literal y una propuesta concreta de cierre.

Contradicciones de severidad alta — bloquean decisiones futuras

C1 · Fuente de verdad clínica disputada (FlowMed vs SACMed vs ficha papel)

Severidad: alta · Procesos afectados: Operaciones · Contraloría · Plataformas TI.

Partes en disputa:

• Rodrigo Llancao: "FlowMed [...] vuelve a tener el 100% de todo" después de pasar por SACMed; "FlowMed con un botoncito rescata todos esos datos" [Flowmed-20260409 23:53, 1:00:21].
• Eduardo González: "La comunicación es de la ficha a la Contraloría, no de Contraloría a la ficha [...] puede pasar que no lo hagan y ahí se nos puede generar una diferencia"; FlowMed Contraloría y SACMed quedan como "dos repositorios paralelos con riesgo de descalce posterior" [EcosistemaTI-20260415 23:55, 24:25, 24:52].
• Vicente Rivano: la UCI trabaja con dos orígenes según sucursal: SACMed para 6 propias, SharePoint con digitación manual para 6 acreditadas [Contraloria-20260421 12:46].
• Roberto Carvajal / Ignacio Ahumada: "Workmed tiene UN solo dato del cliente repartido en al menos 4 sistemas (FlowMed, HubSpot, Defontana, comercial), y los registros pueden estar desincronizados" [Recaudacion-20260423 1:38:13, 1:39:12].

Qué bloquea: define dónde vive el dato clínico, y con eso la deduplicación, el MPI, el modelo de consentimiento granular y el cumplimiento de la Ley 21.719 (vigencia 1 dic 2026, 6 meses para cumplir). No se puede diseñar el Identity Service ni FlowMed 2.0 sin resolver primero esta pregunta.

Próximo paso: consolidar la versión canónica con Eduardo González y Christian Urbina; declarar explícitamente que la abstracción "FlowMed = 100%" se sostiene sólo para centros propios con SACMed integrado y sólo en modo lectura unidireccional ficha → Contraloría. Los acreditados rompen la promesa porque viajan por SharePoint con transcripción manual.

C2 · Hosting de FlowMed: on-premise raqueado vs sólo réplica AWS

Severidad: alta · Procesos afectados: Plataformas TI · Recaudación · Comercial.

Partes en disputa:

• Eduardo González (dueño técnico, fuente autorizada): "Servidor on-premise raqueado en las dependencias de Manuel Montt; replica de la BD en AWS RDS (réplica en caliente)"; el partner legacy Secall administra software, infraestructura on-premise, evolutivos y capacitación [EcosistemaTI-20260415 33:37, 34:07, 34:58, 35:22].
• Roberto Carvajal: "Guardaban cierta información en Amazon Web Services, una copia de la base de datos con un desfase. Información solo verbal hasta ahora; pendiente confirmar" [Operaciones-20260407 1:10:15].
• Coustasse / Ignacio Ahumada: "Workmed mantiene una copia/espejo de la base de datos vía Secall, con desfase de ~5-10 minutos respecto a producción" [Finanzas-20260416 35:15, 40:27, 40:52].
• Marcela / Rodrigo Llancao: "Workmed mantiene copia en caliente en AWS"; "sé que existe pero nunca la he visto" [Comercial-20260420 36:20, 55:00, 55:28].

Qué bloquea: define qué se migra, qué se replica y desde dónde para FlowMed 2.0. La réplica caliente con datos clínicos es además una vulnerabilidad de compliance bajo la Ley 21.719 [EcosistemaTI-20260415 43:39, 44:05].

Próximo paso: dejar la versión canónica documentada en 08-plataformas-ti.md §Hosting (la versión de Eduardo tiene mayor peso por especialidad del informante) y comunicarla al comité ejecutivo. Mientras tanto reflejar la ambigüedad como pregunta abierta.

C3 · Soberanía sobre la BD productiva FlowMed cedida a Secall · cuenta genérica compartida sin trazabilidad

Severidad: ALTA (revisado mayo 2026 con información post-levantamiento) · Procesos afectados: Plataformas TI · Recaudación · Compliance.

Partes en disputa (registro original del levantamiento):

• Roberto Carvajal: "Eduardo González — gatekeeper del acceso a la base AWS / read-replica de FlowMed"; "toda solicitud de visualizador pasa por él" [Recaudacion-20260423 1:25:32, 1:38:42].
• Eduardo González: presenta y conoce el ecosistema técnico end-to-end; el área TI Workmed "no tiene administración del software" de FlowMed (la tiene Secall); el equipo de visualización "se conecta a vistas de la réplica AWS" [EcosistemaTI-20260415 33:37, 34:58, 35:51, 36:49].

Aclaración complementaria (mayo 2026): el gatekeeper técnico real de la BD productiva en AWS RDS es Secall, no Eduardo. Eduardo es broker funcional que solicita accesos a Secall; el acceso interno se distribuye vía cuenta genérica compartida entre Eduardo + Rodrigo + Ignacio + ¿otros?, posiblemente incluyendo personal de Secall, sin trazabilidad por persona. No existe contrato formal de encargo de tratamiento de datos verificable con Secall — bajo Ley 19.628 (vigente) y Ley 21.719 (1-dic-2026) Secall es "encargado de tratamiento" y el contrato es exigible.

Qué bloquea: condiciona C2 y la operación diaria del script Python de 2.553 líneas. La cadena de valorización (script → EDP → factura) y todas las plataformas internas (Salud Compatible, Salud Mental, agente piloto) dependen de un proveedor externo con "soporte 2 semanas a nunca" + una cuenta compartida que hace imposible cumplir hoy el deber de Ley 19.628 + 16.744/DS 109 (régimen confidencialidad ocupacional) de demostrar quién accedió a qué dato sensible.

Próximo paso: ejecutar como hito Mes 1: (a) apretar contrato con Secall (SLA + auditoría + cláusulas Ley 19.628/21.719); (b) acceso administrativo paralelo Workmed sobre el RDS; (c) individualizar credenciales y cerrar la cuenta genérica. El mail sobre acceso AWS RDS para Roberto / Barbarita [Recaudacion-20260423 1:25:32, 1:40:40] es el gatillante operativo, pero por sí solo no resuelve el problema mientras Secall siga siendo el admin único.

Contradicciones de severidad media o baja

C4 · Integración HubSpot ↔ FlowMed: dos proyectos distintos confundidos

Severidad: media · Procesos afectados: Agendamiento · Comercial · Recaudación · Plataformas TI.

Partes en disputa:

• Patricia Maturana: "Las dos partes técnicas no llegaron a acuerdo" en 2024 al intentar integrar HubSpot ↔ FlowMed; quedó manual indefinidamente [Agendamiento-20260413 47:19, 47:48].
• Supervisora de Facturación: "Proyecto en marcha de integración con Defontana para sincronizar estado de facturas" entre HubSpot (cobranza) y Defontana [Recaudacion-20260423 7:00, 11:23].
• Marcela: "El problema ahí de no ocupar más o mejor el CRM porque no está conectado con FlowMed" [Comercial-20260420 52:10].

Qué bloquea: ambigüedad terminológica del corpus. No es contradicción real: hay dos proyectos distintos sobre el mismo nombre — (i) HubSpot ↔ FlowMed (2024 fracasado), (ii) HubSpot ↔ Defontana (activo 2026).

Próximo paso: desambiguar explícitamente en 01-agendamiento.md, 04-comercial.md y 06-recaudacion.md §2.5; tratar los dos proyectos como entidades separadas en cualquier roadmap.

C5 · Iniciativa de valorización en FlowMed: lista pero abandonada

Severidad: media · Procesos afectados: Finanzas · Recaudación · Plataformas TI.

Partes en disputa:

• Eduardo González: "Hubo un intento de automatizar el pricing y 'no dio éxito'; la administración sigue siendo manual + scripts" [EcosistemaTI-20260415 29:38].
• Supervisora de Facturación / Coustasse: "Iniciativa de valorización en FlowMed quedó abandonada hace ~6 meses porque la persona que la validaba rotó de cargo varias veces"; "nunca se llegó a validar" [Recaudacion-20260423 38:29, 38:58, 41:43, 42:13].

Qué bloquea: ambos relatos describen el mismo intento fallido con énfasis distintos (técnico que no escaló vs módulo construido y abandonado por rotación humana). No es contradicción dura.

Próximo paso: registrar como iniciativa histórica en 08-plataformas-ti.md y 06-recaudacion.md §2.5. Es contexto crítico para R3 de la recomendación estratégica (riesgo de repetir el patrón "core monolítico que tarda años").

C6 · "Informes por médico" en FlowMed: dato existe, semántica indefinida

Severidad: media · Procesos afectados: Contraloría · Plataformas TI.

Partes en disputa:

• Rodrigo Llancao: existe el dashboard "completitud de informes por doctor: total asignados, finalizados, sin finalizar y % por médico"; lo pidió Vicente y está en producción [Flowmed-20260409 36:24, 36:52].
• Vicente Rivano: "Hoy día me entregan un número, pero estamos definiendo qué es ese número"; "necesito que libere de cuatro, de cinco. Eso todavía no lo puedo ver" [Contraloria-20260421 24:45, 25:43, 26:12].

Qué bloquea: el KPI existe como tablero pero el dueño del KPI (Vicente) no lo considera operativo todavía porque le falta granularidad por peso de batería. Es una contradicción de "estado real del KPI" entre autor del tablero y consumidor.

Próximo paso: Vicente y Rodrigo redefinen la semántica antes de adoptar este KPI como input del SLA "aptitud vigente". Reflejar en 03-contraloria-salud.md §2.5.

C7 · Disponibilidad histórica de FlowMed: alta vs degradación reciente

Severidad: baja · Procesos afectados: Agendamiento · Plataformas TI.

Partes en disputa:

• Rodrigo Llancao: "Indisponibilidad histórica de FlowMed: muy baja. Última caída fue por 'tema físico, ni siquiera operativo'" [Plataformas-20260420 54:04].
• Patricia Maturana: "Lentitud creciente del sistema en últimos meses: 'He estado reclamando que algo pasa en el sistema, está demasiado lento'"; tiempos de procesamiento se degradaron a 20-25 min para nóminas grandes [Agendamiento-20260413 41:08, 40:40].

Qué bloquea: matiz métrico, no conflicto: A habla de uptime (disponibilidad), B de latencia (rendimiento). Pueden coexistir.

Próximo paso: etiquetar en 01-agendamiento.md §2.5 como matiz métrico diferente; el monitoreo de FlowMed debe tracear ambas dimensiones por separado.

C8 · ¿FlowMed expone API o no?

Severidad: media · Procesos afectados: Plataformas TI.

Partes en disputa:

• Eduardo González: FlowMed tiene integraciones activas con Megafy, POS RobleLabs, SACMed, RIS Galen, TSCom, LIS LaboCenter [EcosistemaTI-20260415 3:14, 4:39, 5:58, 12:25].
• Rodrigo Llancao: "FlowMed no expone API. Toda integración debe hacerse contra la base de réplica. 'Ni siquiera hay como una API, por así decirlo, de FlowMed'" [Plataformas-20260420 35:00, 35:23].

Qué bloquea: hipótesis a confirmar: FlowMed sí expone integraciones B2B punto-a-punto con sus proveedores partner ("viaje digital"), pero no expone una API genérica utilizable por terceros (incluyendo el propio equipo TI Workmed para desarrollos internos).

Próximo paso: consolidar la distinción en 08-plataformas-ti.md §Integraciones después de confirmación cruzada Eduardo + Rodrigo. Es un dato crítico para diseñar el Identity Service: si no hay API genérica, el servicio consume vía read-replica.

C9 · Autoría y ubicación del script Python de valorización

Severidad: media · Procesos afectados: Finanzas · Recaudación · Plataformas TI.

Partes en disputa:

• Sorpresa S7 (sesión Finanzas): "El script Python de valorización vive en la cuenta personal ('mi guiza') de Ignacio, no en un repositorio corporativo" [Finanzas-20260416 45:17].
• Roberto / Ignacio (sesión Recaudación): "Script Python: 2.553 líneas, autoría Rodrigo Llancao"; "estaba en el GitHub personal de Rodrigo; en migración a GitHub de Workmed" [Recaudacion-20260423 1:15:49, 1:30:35, 1:38:42].

Qué bloquea: simplificación de F5 corregida por F11. Hipótesis: Rodrigo es autor y aloja en su GitHub personal; Ignacio es operador con copia local de respaldo.

Próximo paso: registrar versión canónica en 08-plataformas-ti.md §Activos críticos: autor Rodrigo, operador Ignacio, migración a GitHub de Workmed pendiente con Christian Urbina.

C10 · Power BI: descartado estratégicamente vs sostenido a corto plazo

Severidad: baja · Procesos afectados: Comercial · Plataformas TI.

Partes en disputa:

• Rodrigo / Mónica: "No usar Power BI a futuro como destino estratégico de visualización: 'no nos gusta Power BI… es un dolor'. La aspiración es un portal SaaS multitenant propio" [Flowmed-20260409 1:08:12, 1:09:08, 1:09:31].
• Decisión sesión Comercial-BI: "Mantener Power BI como herramienta de visualización en el corto plazo: 'por el momento mantener Power BI tiene sentido'" [ComercialBI-20260422 22:56].

Qué bloquea: evolución no contradictoria: aspiración estratégica de mediano plazo (descartar) + decisión táctica de corto plazo (mantener). Conviven.

Próximo paso: reflejar en 08-plataformas-ti.md §Decisiones como puente operativo hasta que exista FlowMed 2.0.

C11 · Dueño funcional de FlowMed: módulo Agendamiento vs sistema completo

Severidad: baja · Procesos afectados: Agendamiento · Plataformas TI.

Partes en disputa:

• Rodrigo Llancao: "Eduardo González — dueño funcional de FlowMed dentro de Workmed; conoce la lógica del sistema; coordina los requerimientos al partner" [Flowmed-20260409 7:03, 8:32].
• Rodrigo / María Ignacia: "Patricia Maturana ('Paty') — ÚNICA persona autorizada a modificar el módulo de Agendamiento en FlowMed" [Flowmed-20260409 10:51, 11:15; Agendamiento-20260413 todo el finding].

Qué bloquea: ambigüedad común al referirse a "el dueño de FlowMed". No es contradicción.

Próximo paso: documentar como roles complementarios en 01-agendamiento.md §Roles y 08-plataformas-ti.md §Gobernanza FlowMed: Eduardo dueño técnico/Gobierno TI del sistema completo; Patricia dueña funcional del módulo Agendamiento.

Distribución y conclusión

De las 11 contradicciones: 2 altas (C1, C2), 6 medias (C3, C4, C5, C6, C8, C9) y 3 bajas (C7, C10, C11). El proceso AS-IS con más contradicciones aguas arriba/abajo es Recaudación y cobranza (5), seguido de Agendamiento (4). El anexo TI absorbe las 11 porque es el plano transversal donde se hacen visibles. Las dos contradicciones de severidad alta y la concentración del pricing en un script Python en GitHub personal son las tres piezas a resolver con consultas a Eduardo González y Rodrigo Llancao antes de la fase de recomendación: condicionan la viabilidad de cualquier roadmap.

$ cat ./mapa-incidencias-cto.md

21 incidencias concretas de seguridad · infraestructura · gobernanza · compliance identificadas durante el levantamiento. Para cada una: severidad (🔴 crítica · 🟠 alta · 🟡 media · 🟢 baja), responsable funcional con cargo y acción del roadmap que la mitiga. Pensada para acelerar el onboarding de Carolina Araya como CTO: muestra qué está mal hoy, quién es accountable y qué ya está cubierto en el plan.

Mapa de incidencias técnicas, de seguridad y gobernanza · onboarding CTO

Tabla de 22 incidencias concretas identificadas durante el levantamiento (11 sesiones, 7-23 abril 2026), agrupadas en 4 categorías y con severidad explícita. Para cada incidencia: el responsable funcional actual (con cargo) y la acción del roadmap que la mitiga. Pensada para acelerar el onboarding de Carolina Araya como CTO de Workmed: muestra qué está mal hoy, quién es accountable y qué acción del programa ya la tiene cubierta.

Cómo leer la severidad:

• 🔴 Crítica: requiere acción Mes 1 · expone a multa, brecha de seguridad o incidente operativo grave
• 🟠 Alta: requiere acción Fase 1-2 · genera riesgo estructural pero acotado
• 🟡 Media: requiere acción Fase 2-3 · descarga trabajo cotidiano sin urgencia
• 🟢 Baja: oportunidad / mejora continua

🔴 Seguridad

🟠 Infraestructura

🟢 Gobernanza · Buenas Prácticas

🟣 Compliance · Regulatorio

Nota sobre el stack legal aplicable a los datos sensibles que vive en FlowMed

>

El informe que se entrega al cliente/empleador es sólo aptitud (apto/no apto/con restricciones). Pero la BD productiva de FlowMed almacena el detalle clínico completo (diagnósticos, antecedentes, exámenes) que sustenta ese informe. Bajo Ley 16.744 + DS 109 + dictámenes SUSESO, ese detalle NO debe ser accesible al empleador ni a terceros — el empleador sólo recibe el resultado agregado/despersonalizado/por puesto.

>

Stack legal aplicable a esa BD: - Ley 19.628 art. 2 letra g) (vigente) — datos sensibles incluyen estados de salud físicos. - Ley 16.744 + DS 109 + dictámenes SUSESO (vigente) — régimen específico de confidencialidad de evaluaciones ocupacionales. - Ley 20.584 art. 13 (vigente) — deber de reserva. Aplica con fuerza a SACMed (ficha clínica completa); aplica como argumento defendible-pero-secundario sobre FlowMed (que almacena antecedentes de salud sin ser la ficha integral). - Ley 21.719 (1-dic-2026) — añade régimen sancionatorio administrativo + DPO + ARCOP.

>

Las incidencias S1, S2, S4, I1 y C3 no son riesgos futuros bajo 21.719: son incumplimientos vigentes hoy bajo 19.628 + 16.744.

Resumen ejecutivo · acción inmediata Mes 1

De las 22 incidencias, 6 son críticas y requieren acción dentro de los primeros 30 días:

1. S1 + S2 + C3 (BD expuesta + conexiones sin encriptar + réplica caliente con detalle clínico) → A.4 individualizar credenciales + cerrar exposición pública + cifrado en tránsito y at-rest. Estas tres son incumplimientos hoy de Ley 19.628 (datos sensibles) y Ley 16.744/DS 109 (régimen ocupacional) — no riesgo futuro.
2. I1 (Secall gatekeeper técnico real con soporte errático) → A.4 + apretar contrato Secall.
3. C4 (Secall sin contrato de encargo formal) → B.6 redactar contrato Ley 19.628/21.719 con asesoría legal · arrancar Mes 1 paralelo a la negociación técnica.
4. C1 (Ley 21.719 sin DPO, vigencia 1-dic-2026) → arrancar selección de DPO en B.6

Las 16 restantes están cubiertas por el roadmap de Fase 1-2 sin necesidad de track adicional.

$ cat ./08-plataformas-ti.md

Anexo de plataformas: FlowMed core, integraciones partner (Megafy, RobleLabs, RIS Galen, TSCom, LIS), GitHub de Workmed, AWS Workmed propia, Defontana, HubSpot, Power Platform, Supabase. No es un proceso de negocio: es el diccionario transversal que aparece en todos los AS-IS y soporta las decisiones técnicas de FlowMed 2.0.

Anexo: Plataformas y Ecosistema TI

Diccionario transversal de plataformas TI que sustenta los 7 procesos AS-IS de Workmed. Cada sistema citado en cualquier proceso debe poder rastrearse hasta una entrada de este anexo. La fuente principal son tres findings técnicos (Flowmed-20260409, EcosistemaTI-20260415, Plataformas-20260420), más menciones puntuales de los findings de proceso. Las contradicciones arquitectónicas críticas se reiteran al cierre con énfasis en su impacto sobre el roadmap.

1. Catálogo de plataformas

1.1 Núcleo clínico-operacional

FlowMed (legacy core). Dueño funcional Eduardo González (sistema completo) + Patricia Maturana (módulo Agendamiento) + Vicente Rivano (módulo Contraloría). Dueño técnico Secall (proveedor SaaS, administra software, infraestructura on-premise, evolutivos y capacitación; Workmed no tiene administración del software). Hospedaje canónico: servidor on-premise raqueado en Manuel Montt + réplica caliente AWS RDS con desfase 5-10 min. Cubre agendamiento, admisión, hoja de ruta, módulo Contraloría, maestros, módulo control de pago y dashboards internos. Tabla log = 31 GB, tabla atención = 2.2 GB, otras dos ≈ 13 GB c/u. NO expone API genérica: solo integraciones partner punto-a-punto. Decisión cerrada: reemplazar por FlowMed 2.0 en cuenta AWS Workmed propia con failover [§2.1 08-plataformas-ti; Flowmed-20260409 0:04, 23:53; EcosistemaTI-20260415 33:37, 34:58; Plataformas-20260420 35:00, 52:15; Recaudacion-20260423 1:23:16, 1:26:56].

SACMed (HIS). Dueño funcional equipo clínico (TENS, médicos contralores). Dueño técnico proveedor SACMed. Hospedaje GCP (cuenta separada de AWS Workmed). Ficha clínica electrónica por RUT (no por empresa); entrada en Santiago en diciembre 2024; historial 15 años por ley. Comunicación unidireccional ficha → Contraloría genera "dos repositorios paralelos con riesgo de descalce". Configurar una batería nueva tarda ~8 horas y depende del equipo SACMed [§2.2 08-plataformas-ti; EcosistemaTI-20260415 1:55, 24:25, 34:31; Plataformas-20260420 59:13].

Megafy (sobre Appian Cloud). Plataforma de preadmisión digital (consentimiento informado, drogas, encuesta de salud, epilepsia). Decisión arquitectónica de hace 3 años; Eduardo cuestiona si sigue siendo la opción correcta hoy [§2.3 08; EcosistemaTI-20260415 0:58, 10:28].

RobleLabs. POS biométrico (lector QR + NFC + huella + cámara) en estación de admisión y drogas. Verifica contra huella viva o foto del chip de la cédula. Flujo de contingencia manual cuando el chip está dañado (problema recurrente en mineros) [§2.4 08; EcosistemaTI-20260415 5:58; Operaciones-20260407 1:03:33].

SignAPIS. Firma electrónica + verificación; integrada a Megafy/Appian [§2.5 08; EcosistemaTI-20260415 4:39].

RIS Galen. Radiology Information System: imágenes (~1 GB por estudio RESO) e informes radiológicos; visualizador integrado en SACMed [§2.6 08; EcosistemaTI-20260415 3:14, 9:05].

TSCom. "Screens de drogas" con flujo automatizado hacia liberación cuando el resultado es negativo; trazabilidad explícita de scannings no efectivos [§2.7 08; EcosistemaTI-20260415 3:14, 40:24].

LIS (LaboCenter + lab propio). Laboratory Information System. Solo dos LIS activos e interoperando; otros laboratorios partner (Bionet Santiago, Blanco Calama, LabNostic) "activos pero no interoperando" — pendiente integración [§2.8 08; EcosistemaTI-20260415 3:43, 8:42].

CEMA. Proveedor de electrocardiógrafos / espirometría; integraciones "avanzando" (electro) y "se viene" (espirometría) [§2.38 08; Operaciones-20260407 15:12].

1.2 Comercial / BI / Back-office

HubSpot. Dueños múltiples: Comercial (CRM, prospección, cotizaciones), Cobranza (pipelines facturación + cobranza), Agendamiento (cola "agenda por confirmar"). Tres roles simultáneos: intake de correos de agendamiento, embudo comercial y pipelines de Facturación + Cobranza usados como sistema de gestión torcido (gobernado por fechas, no por estado real). También funciona como portal de cliente con dashboards Power BI. Vulnerabilidades reconocidas: "tiene vulnerabilidades muy importantes" — Rodrigo. NO integra con FlowMed (intento 2024 fracasado). NO integra con Defontana hoy (proyecto activo 2026) [§2.9 08; Flowmed-20260409 1:02:43; Agendamiento-20260413 47:19, 47:48; Comercial-20260420 52:10].

Defontana. ERP chileno que reemplazó a NetSuite en enero 2025. Cubre facturación, inventario, OC, estado de pagos. Forma ecosistema con Tivendo (POS módulo de caja). Sin API solicitada (proyecto activo). Sin integración con SACMed; sin integración con HubSpot (proyecto 2026). Centralización con Buk manual [§2.10 08; EcosistemaTI-20260415 4:12, 28:12; Finanzas-20260416 25:23, 31:39; Abastecimiento-20260423 8:37].

Buk. SaaS chileno de RR.HH./nómina; subgerencia de Personas endosada temporalmente al CFO Coustasse. Centralización con Defontana manual = duplicidad y errores [§2.11 08; Finanzas-20260416 25:23].

Power BI. Dueño funcional Rodrigo Llancao (BI); Ignacio Ahumada arma dashboards diarios; clientes finales con paneles asignados (Syncore, Fluor Salfa, Mercado Libre). Refresco cada 30 min (no es tiempo real). Cuentas paralelas sin auditoría de acceso (todos entran con la misma cuenta); sin control de versiones (workaround: renombrar v2.1, v3.1). Decisión cerrada en F9: mantener Power BI a corto plazo, descartar como destino estratégico futuro [§2.13 08; Flowmed-20260409 1:06:32, 1:08:39; ComercialBI-20260422 22:56].

Script Python de valorización. Operador Ignacio Ahumada; autor Rodrigo Llancao. Núcleo de la lógica de negocio de valorización: el módulo de precios de FlowMed es referencial; este script (~2.553 líneas) es la fuente autoritativa. Vivía en GitHub personal de Rodrigo; en migración pendiente a GitHub de Workmed de Workmed [§2.14 08; Recaudacion-20260423 1:30:35, 1:38:42; Plataformas-20260420 44:04].

Power Platform. Uno de los lugares donde se crea el cliente (en paralelo a HubSpot, Defontana, FlowMed); contribuye al problema de identidad fragmentada [§2.39 08; Finanzas-20260416 11:13].

Agente conversacional piloto (n8n + Supabase + Streamlit). Dueño Rodrigo Llancao; aspiracional para Comercial. Tiempo de respuesta esperado 10-30 min. Decisión: agente DESPUÉS de FlowMed 2.0 [§2.35 08; Plataformas-20260420 24:45; ComercialBI-20260422 18:37].

1.3 Plataformas internas Workmed

Plataforma Acreditación R&S. Stack Angular + NestJS sobre AWS Workmed propia. Dueña funcional Karina Jara (subgerenta R&S). Desarrollador único Rodrigo Llancao. Ninguna integración con FlowMed: línea adyacente, fuera de alcance de los 7 procesos centrales [§2.21 08; Plataformas-20260420 1:19, 7:25, 18:14].

Ficha Salud Compatible. Stack Python + Supabase free. Productivo, exclusivo Syncore: registro de gestión educativa (llamados periódicos, mediciones). Lee de la base de réplica AWS por RUT. Será reemplazada por GenieMD [§2.22 08; Plataformas-20260420 21:08, 24:45].

Salud Mental. Stack Python + Supabase free. En validación final, no productivo. Reemplazará Microsoft Forms + Excel para tests Wonderlic, "Persona bajo la lluvia", aversión al riesgo, somnolencia y fatiga conductor. Lee de la réplica AWS [§2.23 08; Plataformas-20260420 25:12, 28:32].

GenieMD. Plataforma EE.UU. de gestión de pacientes crónicos. Hoy en piloto, sin integración con FlowMed; futuro reemplazo de Ficha Salud Compatible [§2.24 08; Operaciones-20260407 1:06:33].

1.4 Infraestructura

AWS — cuenta propia Workmed. Hospedaje de las plataformas internas y futura sede de FlowMed 2.0. RDS + S3 + EC2 + Amplify + VPC + CloudWatch. "Servidor chiquitito"; sin VPN. Decisión Plataformas-20260420: nuevo desarrollo aquí, sin abrir cuentas paralelas [§2.15 08; Plataformas-20260420 18:14, 42:10, 1:03:20].

AWS RDS read-replica de FlowMed. Réplica en caliente (no backup) de la BD productiva FlowMed; cuenta AWS separada de la propia Workmed. Toda integración entre plataformas internas y FlowMed pasa por aquí, porque FlowMed no expone API. Desfase ~5-10 min. Punto único de falla: Eduardo González gatekeeper del acceso. Replica caliente con datos clínicos = vulnerabilidad de compliance bajo nueva Ley [§2.16 08; EcosistemaTI-20260415 33:37, 35:22, 43:39; Plataformas-20260420 35:00; Recaudacion-20260423 1:25:32].

Servidor on-premise FlowMed (Manuel Montt). Aloja la BD productiva FlowMed legacy. Replica en caliente a AWS RDS. Sin RP secundario en infraestructura; sin VPN [§2.17 08; EcosistemaTI-20260415 33:37, 34:58].

GCP (SACMed hosting). Hosting de la nueva instancia SACMed (Santiago, dic 2024) [§2.18 08; EcosistemaTI-20260415 34:31].

Cloudflare. DNS bajo control directo de Workmed; subdominios → Amplify [§2.19 08; Plataformas-20260420 33:10].

Supabase (plan gratuito). Postgres BaaS para Ficha Salud Compatible, Salud Mental y agente piloto. Plan gratuito = vulnerabilidad de seguridad reconocida por Rodrigo; sin VPN; expuesto [§2.20 08; Plataformas-20260420 24:45, 25:12].

GitHub (cuenta personal Rodrigo). Repositorio de código de las tres plataformas internas + script Python de valorización. No existe organización Workmed en GitHub. Decisión Plataformas-20260420: crear organización Workmed (o GitLab) y migrar [§2.34 08; Plataformas-20260420 44:04, 1:03:47].

Anthropic / Claude (aspiracional). Desarrollo asistido por IA para FlowMed 2.0. Sin suscripción contratada; pendiente decisión [§2.37 08; Plataformas-20260420 47:42].

1.5 Identidad / comunicación / ofimática

OneDrive. Repositorio de fichas escaneadas de centros acreditados; equipo dedicado consolida y tipea en FlowMed Contraloría (100% transcripción manual) [§2.25 08; Operaciones-20260407 17:15; EcosistemaTI-20260415 20:07, 48:21].

SharePoint. Exámenes digitalizados (visual, audiometría, drogas), observaciones TENS, carpetas de cobranza. Conexión directa Power BI. "Solución transitoria" según Rodrigo [§2.26 08; Flowmed-20260409 24:44, 1:14:00].

Outlook / Microsoft Office. Correo (canal de entrada a HubSpot vía agendamiento@workmed); Excel (formularios cliente, planillas masivas, control de fichas, conciliación HubSpot↔Defontana) [§2.27 08; Comercial-20260420 3:19].

WhatsApp. Canal de notificación manual: María Ignacia notifica RUTs listos a Contraloría con la lista "fichas listas". Workaround manual del match Operación↔Contraloría = "triple pega" [§2.29 08; Flowmed-20260409 33:13, 33:40].

Microsoft Forms. Cuestionarios de Salud Mental hoy; será reemplazado por la plataforma Salud Mental de Rodrigo [§2.30 08; Plataformas-20260420 28:32].

Rectificador del Servicio de Registro Civil. Validación manual de RUTs; acceso bloqueado a Workmed, usan páginas alternativas [§2.31 08; Agendamiento-20260413 8:26, 8:56].

InDesign. Vicente diagrama el flujo de Contraloría como una "foto" [§2.28 08; Contraloria-20260421 34:17].

Jira / Julie / Teams. Gestión de proyectos: Jira adoptado hace ~1 semana gracias a Carolina; Julie como alternativa propuesta; Teams canal formal del equipo. Múltiples canales sin consolidación [§2.33 08; Plataformas-20260420 1:00:38, 1:04:44].

IMED. Proveedor de insumos de oficina; permite envío directo a sedes (bypass de la bodega central) [§2.32 08].

1.6 Sistemas históricos y legacy

NetSuite (histórico). ERP Oracle: proyecto de implementación fallido (2022-2024); reemplazado por Defontana en enero 2025. Citado como contexto histórico de iniciativas TI fallidas [§2.36 08; Finanzas-20260416 31:39, 32:07].

2. Identidad fragmentada por sistema

[§4 08-plataformas-ti]

3. Contradicciones arquitectónicas críticas (énfasis roadmap)

Estas tres contradicciones bloquean cualquier roadmap de modernización (FlowMed 2.0, Identity Service, integración HubSpot↔Defontana, agente conversacional). Detalle completo en 01-hallazgos-transversales.md; aquí su impacto arquitectónico.

C1. Fuente de verdad clínica disputada

Tres versiones simultáneas: Rodrigo dice "FlowMed 100%" [Flowmed-20260409 23:53]; Eduardo describe "dos repositorios paralelos con riesgo de descalce" entre SACMed y FlowMed Contraloría [EcosistemaTI-20260415 24:25]; Vicente trabaja con dos orígenes según sucursal (SACMed para 6 propias, SharePoint para 6 acreditadas) [Contraloria-20260421 12:46].

Impacto roadmap: bloquea el diseño del Identity Service y de FlowMed 2.0. No se puede deduplicar al trabajador, construir el MPI, ni cumplir con la nueva Ley 21.719 de Datos Personales (vigencia 1 dic 2026, 6 meses para cumplir) sin antes consolidar dónde vive el dato clínico autoritativo.

C2. Hosting de FlowMed: on-premise raqueado vs sólo réplica AWS

Versión Eduardo (canónica, dueño técnico): on-premise raqueado en Manuel Montt + réplica AWS RDS [EcosistemaTI-20260415 33:37]. Versión Coustasse / Marcela / Rodrigo: solo réplica AWS desfasada 5-10 min. La información parcial circulando produce decisiones inconsistentes.

Impacto roadmap: define qué se migra y desde dónde para FlowMed 2.0. La réplica caliente con datos clínicos es además vulnerabilidad de compliance bajo Ley 21.719 [EcosistemaTI-20260415 43:39, 44:05]. Debe quedar versión canónica documentada antes de planificar migración o failover.

C3. Eduardo González como punto único de falla (acceso AWS RDS)

Toda integración entre plataformas internas y FlowMed pasa por la base AWS RDS read-replica; el acceso depende de un solo gatekeeper sin RP formal [Recaudacion-20260423 1:23:16, 1:25:32; Finanzas-20260416 50:26].

Impacto roadmap: condiciona C2 y la operación diaria del script Python. El mail sobre acceso AWS RDS para Roberto/Barbarita debe ejecutarse como hito Mes 1 antes de cualquier otro entregable de FlowMed 2.0 o del Identity Service [Recaudacion-20260423 1:25:32, 1:40:40].

4. Riesgos transversales priorizados

Lista priorizada de la deuda técnica cross-proceso (§5 del anexo TI):

1. Punto único de falla acceso AWS RDS (Eduardo). Severidad alta.
2. Núcleo de la lógica de negocio en repo personal (script Python). Severidad alta.
3. Iniciativa de valorización en FlowMed abandonada hace ~6 meses. Severidad media.
4. Hosting FlowMed: ambigüedad on-prem vs AWS. Severidad alta. Vulnerabilidad de compliance bajo Ley 21.719.
5. Fuente de verdad clínica disputada. Severidad alta.
6. FlowMed no expone API genérica. Severidad media. Bloquea desarrollo interno; obliga al uso de la réplica AWS con desfase.
7. HubSpot ↔ FlowMed sin integración (intento 2024 fracasó). Severidad media.
8. Vulnerabilidades de seguridad reconocidas: portal HubSpot del cliente, Supabase plan gratuito, GitHub personal con correo corporativo, sin VPN ni restricciones de red, cuenta única compartida en Power BI. Severidad media-alta combinada.
9. Cero capacidad TI interna de desarrollo respecto al core: "no tenemos, está todo contratado con el proveedor". Severidad alta hasta FlowMed 2.0.
10. Identidad del cliente fragmentada en 3+ sistemas. Severidad media.
11. Sin modelo de datos documentado de FlowMed. Severidad media.
12. Centros acreditados con 100% transcripción manual. Severidad media.
13. Múltiples canales de comunicación sin consolidar. Severidad baja.
14. Rotación alta de gerentes de tecnología; área TI <3 años. Severidad media.
15. Sin RP secundario en infraestructura. Severidad media.
16. Disponibilidad histórica vs lentitud reciente. Severidad baja.

[§5 08-plataformas-ti]