EMERCOM · SpA
ENTREGABLE · WORKMED
>root@emercom:~/clientes/workmed/bpmn/plataformas-ti
ANEXO TI · PLATAFORMAS Y ECOSISTEMA · ABRIL 2026

Anexo · Plataformas y Ecosistema TI_

Diccionario compartido de las plataformas que sustentan los siete procesos AS-IS de Workmed: FlowMed, SACMed, Megafy / Appian, RobleLabs, RIS Galen, TSCom, LIS, HubSpot, Defontana, Buk, Power BI, AWS (cuenta propia y réplica de FlowMed), GCP, plataformas internas (Acreditación R&S · Salud Compatible · Salud Mental) y la deuda técnica transversal.

CLIENTE Workmed
DEPARTAMENTO Plataformas y Ecosistema TI
FECHA 2026-04-27
VERSIÓN v2.0
NOTACIÓN BPMN 2.0 (OMG)
ESTADO ENTREGABLE

📄 Ver versión extendida AS-IS · documento fuente con detalle granular →

cat ./00-resumen.md

Este anexo no documenta un proceso de negocio: es el diccionario compartido de plataformas TI que sustenta los siete documentos AS-IS de Workmed (`01-agendamiento` … `07-abastecimiento`). Cada sistema citado en cualquiera de los procesos puede rastrearse hasta una entrada del catálogo, ubicarse en el diagrama de integraciones y, cuando aplica, en la tabla de identidad fragmentada del cliente / paciente.

La fuente principal son los tres findings técnicos: Flowmed-20260409 (Eduardo González sobre FlowMed legacy), EcosistemaTI-20260415 (mapeo de proveedores e integraciones) y Plataformas-20260420 (cuenta AWS propia, plataformas internas, GitHub). Entre los hallazgos cruzados destacan: FlowMed no expone API genérica (sólo integraciones partner punto-a-punto) [Plataformas-20260420 35:00, 35:23], la soberanía sobre la BD productiva FlowMed (AWS RDS read-replica) está cedida a Secall como gatekeeper técnico real, con Eduardo González operando como broker funcional y un acceso interno vía cuenta genérica compartida sin trazabilidad por persona ni contrato formal de encargo [Recaudacion-20260423 1:25:32, 1:38:42] y el script Python de valorización (~2.553 líneas, autoría Rodrigo Llancao) vivía en GitHub personal en migración a GitHub de Workmed de Workmed [Recaudacion-20260423 1:30:35; Plataformas-20260420 44:04].

La sección de deuda técnica reúne 16 riesgos transversales: SPOF de acceso a datos, núcleo de lógica en repo personal, iniciativa de valorización en FlowMed abandonada hace ~6 meses [Recaudacion-20260423 38:29, 41:43], hosting on-prem + réplica AWS con ambigüedades, fuente de verdad clínica disputada (FlowMed vs SACMed vs ficha papel) [EcosistemaTI-20260415 23:55, 24:25], vulnerabilidades reconocidas en portal HubSpot del cliente y bases en Supabase plan gratuito, identidad del cliente fragmentada en 3+ sistemas y centros acreditados con 100% transcripción manual desde OneDrive a FlowMed Contraloría. Decisión cerrada: reemplazar FlowMed legacy por FlowMed 2.0 en cuenta AWS propia (Carolina Araya).

root@emercom:~/bpmn-rules $ cat convenciones.txt

Este anexo no incluye un modelado BPMN propio. El catálogo de plataformas y la deuda técnica transversal son por naturaleza descriptivos: se documentan acá los hallazgos cruzados (puntos únicos de falla, vulnerabilidades, fragmentación de identidad) que viven entre los siete procesos AS-IS. Para diagramas operacionales, ver los visores BPMN de los procesos 01-07. El mapa de integraciones del ecosistema TI completo (FlowMed ↔ SACMed ↔ HubSpot ↔ Defontana ↔ Power BI ↔ AWS) queda como entregable de Fase 3.

⚠ DEUDAS TÉCNICAS TRANSVERSALES

1 · Soberanía sobre la BD productiva cedida a Secall + núcleo de lógica en repo personal. El gatekeeper técnico real de la AWS RDS read-replica de FlowMed es Secall (proveedor externo); Eduardo González opera como broker funcional; el acceso interno se distribuye vía cuenta genérica compartida (Eduardo + Rodrigo + Ignacio + ¿otros?) sin trazabilidad por persona; sin contrato formal de encargo de tratamiento [Recaudacion-20260423 1:25:32, 1:38:42; EcosistemaTI-20260415 33:37, 35:51]. El script Python de valorización (~2.553 líneas, fuente autoritativa de pricing) vivía en GitHub personal de Rodrigo Llancao y está en migración a GitHub de Workmed, aún incompleta [Recaudacion-20260423 1:15:49, 1:30:35; Plataformas-20260420 44:04].

2 · FlowMed sin API genérica + intentos previos fallidos. Sólo existen integraciones partner punto-a-punto (Megafy, RobleLabs, RIS Galen, TSCom, LIS); los desarrollos internos (R&S, Salud Compatible, Salud Mental, BI) deben ir contra la base de réplica con desfase de 5-10 min [Plataformas-20260420 35:00, 35:23]. La iniciativa de internalizar el pricing en FlowMed quedó abandonada hace ~6 meses sin haberse llegado a validar si calculaba bien [Recaudacion-20260423 38:29, 41:43]. La integración HubSpot ↔ FlowMed intentada en 2024 fracasó por falta de acuerdo entre las partes técnicas [Recaudacion-20260423 7:00, 11:23].

3 · Vulnerabilidades de seguridad reconocidas + identidad fragmentada. Portal HubSpot del cliente con «vulnerabilidades muy importantes» [Flowmed-20260409 1:02:43]; Supabase en plan gratuito como backend de plataformas internas [Plataformas-20260420 25:12]; cuenta única compartida en Power BI sin auditoría [Flowmed-20260409 1:06:32]; sin VPN ni restricciones de red [Plataformas-20260420 1:05:15]. La identidad del cliente vive en al menos 4 sistemas (FlowMed, HubSpot, Defontana, Power Platform) sin sincronización [Recaudacion-20260423 1:38:13, 1:39:12; Finanzas-20260416 11:13].


man bpmn-symbols

Leyenda de los símbolos BPMN utilizados en ambos diagramas:

Start Event
Círculo fino. Inicia el proceso. Variantes: None, Message, Timer.
End Event
Círculo grueso. Cierra el proceso. Marca el resultado final.
User Task
Humano interactuando con sistema (validar identidad, abrir SharePoint).
Manual Task
Trabajo humano sin sistema BPM (escanear papel, digitación manual).
Service Task
Ejecución automática por software (procesamiento, generación de informe).
Send Task
Envía un mensaje a otro pool (WhatsApp a Contraloría). Sobre relleno.
Receive Task
Espera la llegada de un mensaje. Sobre vacío.
Data Store
Persistencia de datos. SharePoint, Sacmed, Flowmed, Megafy.
Data Object
Artefacto entre tareas (PDFs escaneados, resultados en papel).
Sequence Flow
Línea continua. Orden de ejecución dentro de un pool.
Message Flow
Línea punteada. Comunicación entre pools (WhatsApp, archivos compartidos).

grep -i recomendacion ./

Como anexo transversal, este documento no genera recomendaciones de proceso sino movimientos arquitectónicos que habilitan a los siete procesos AS-IS. Se priorizan según severidad reportada en los findings técnicos y las decisiones ya tomadas por Carolina Araya y Rodrigo Llancao en la 9na sesión [Plataformas-20260420 42:10, 1:03:20]:

01
Migrar repos a la organización Workmed y eliminar SPOF de acceso

Cumplir la decisión de sesión: migrar el código del script Python de valorización y de las tres plataformas internas (Acreditación R&S, Salud Compatible, Salud Mental) desde la cuenta GitHub personal de Rodrigo a la organización Workmed [Plataformas-20260420 44:04, 44:26, 1:03:47]. En paralelo, recuperar soberanía sobre la AWS RDS read-replica: apretar contrato formal de encargo con Secall (Ley 19.628/21.719), establecer acceso administrativo paralelo Workmed sobre el RDS, individualizar credenciales y cerrar la cuenta genérica compartida [Recaudacion-20260423 1:25:32, 1:38:42; EcosistemaTI-20260415 36:49]. Reduce el bus factor en lógica core, recupera control sobre los datos productivos y cierra exposición vigente bajo régimen de confidencialidad ocupacional.

02
FlowMed 2.0 en cuenta AWS propia con API genérica

Acelerar la decisión de Carolina Araya: reemplazar FlowMed legacy por FlowMed 2.0 en la cuenta AWS propia de Workmed con failover y, sobre todo, API genérica. Hoy FlowMed sólo expone integraciones partner punto-a-punto y obliga a las plataformas internas, BI y valorización a depender de la réplica con desfase de 5-10 min [Plataformas-20260420 35:00, 35:23, 56:21; EcosistemaTI-20260415 33:37]. Habilita además la integración HubSpot ↔ Defontana en marcha y abre camino al puente Acreditación R&S ↔ FlowMed para informes de aptitud.

03
Cerrar vulnerabilidades de seguridad reconocidas y compliance Ley 21.719

Atacar el portafolio de vulnerabilidades documentadas: portal HubSpot del cliente «con vulnerabilidades muy importantes» [Flowmed-20260409 1:02:43], Supabase plan gratuito de Salud Compatible y Salud Mental [Plataformas-20260420 25:12], cuenta única compartida en Power BI sin auditoría [Flowmed-20260409 1:06:32] y ausencia de VPN para plataformas internas [Plataformas-20260420 1:05:15]. La réplica caliente de FlowMed con datos clínicos asociables expone a Workmed bajo la nueva Ley de Datos Personales [EcosistemaTI-20260415 43:39, 44:05]: requiere política formal de retención y trazabilidad antes de FlowMed 2.0.

04
Identidad del cliente / paciente unificada (MPI + cliente único)

Resolver la fragmentación documentada: el cliente vive en FlowMed (RUT empresa), HubSpot (nombre no normalizado), Defontana (código numérico interno), Power Platform y otros, sin sincronización [Recaudacion-20260423 1:38:13, 1:39:12; Finanzas-20260416 11:13]; el paciente sufre la misma falta de MPI con variantes del mismo RUT que la depuración del script Python intenta unificar a mano [Recaudacion-20260423 1:30:35, 1:31:02, 1:39:12]. Diseñar un identificador canónico transversal y un servicio de normalización es prerrequisito de la mayoría de las recomendaciones de los procesos Comercial, Finanzas, Recaudación y Abastecimiento.

root@emercom:~/proximos-pasos $ ls

Próximos pasos sugeridos

man bpmn-tools

Los archivos .bpmn generados son XML estándar OMG y se pueden abrir/editar en cualquier modelador BPMN profesional:

HerramientaURLUso recomendado
bpmn.io (web, gratis)demo.bpmn.ioEdición rápida en navegador
Camunda Modelercamunda.com/download/modelerModelado serio, ejecutable
draw.io / diagrams.netapp.diagrams.netEdición visual + export PNG/PDF
Signavio (SAP)signavio.comGobierno corporativo de procesos