Qué hace y para quién

EMA Vault es la plataforma interna de operaciones, finanzas y gestión de producto del ecosistema EMA Health. Concentra en una sola interfaz todo lo que el equipo necesita para correr un negocio que opera cross-país: desde la gestión de pipeline comercial hasta el provisioning de nuevos clientes en cualquier país soportado, pasando por contratos, finanzas multi-moneda, configuración de facturación electrónica por país, gestión del catálogo de productos, auditoría cross-product y moderación del asistente EMI.

A quién está dirigido

Vault es el back-office de EMA Health, pensado exclusivamente para el staff interno —fundadores, área comercial, área técnica, área de finanzas, área de producto. El acceso queda restringido a usuarios con correo @emahealth.io y exige existencia previa en la tabla vault_users. No es un producto para clientes finales y no tiene plan de comercialización: las clínicas y laboratorios consumen el ecosistema EMA Health a través de Clinic, Lab, Well, Emi y los conectores (Bridge, DTE), no a través de Vault.

La razón para documentar Vault con tanto detalle, a pesar de ser interno, es doble. Por un lado el onboarding de nuevo staff exige una referencia operativa clara —Vault tiene 44 módulos API y 23 páginas, suficientes para que la curva de aprendizaje requiera material formal. Por otro lado, las decisiones operacionales que viven en Vault (provisioning, DTE config, contratos, auditoría) tienen implicaciones cross-product significativas; documentarlas como producto es la forma más limpia de dejar el conocimiento accesible.

El problema que resuelve

EMA Health opera once productos en su ecosistema. Cada uno tiene sus clientes, sus contratos, sus métricas, sus releases. Antes de Vault, gestionar el negocio implicaba mantener un patchwork de herramientas externas: un CRM (Salesforce o HubSpot) para pipeline; un sistema de contabilidad (Xero, Defontana o planillas de Excel) para finanzas; Notion para wiki, documentos y checklists; GitHub como source of truth para issues y releases; Excel y scripts ad-hoc para provisionar tenants en cada producto; dashboards separados por producto; y, lo más grave, ningún registro unificado de quién hizo qué cuándo.

Vault sustituye ese patchwork con una sola aplicación de back-office. La idea no es replicar funcionalidad de SaaS comerciales —la app no compite con Salesforce ni pretende reemplazar a Defontana— sino ofrecer el subset que EMA Health usa intensivamente, con la integración cross-product que ningún SaaS comercial puede dar y con control completo sobre los datos.

Propuesta de valor

La propuesta de Vault se construye sobre cinco capas funcionales que operan integradas. La primera es el single pane of glass: todo lo operativo del negocio vive en una sola aplicación con sidebar de siete grupos colapsables. Pipeline, clientes, contratos, finanzas, producto, brand, audit y configuración están a un click de distancia, sin necesidad de mantener pestañas abiertas a SaaS distintos ni de recordar cuál herramienta tiene cuál dato.

La segunda capa es el provisioning automatizado de tenants. Un proceso que en el patchwork anterior tardaba días —crear la organización en Aidbox, generar OAuth client, encriptar el secret, sembrar las tablas en cada producto, invitar al admin del cliente— ocurre ahora en cuestión de minutos con un único POST. La operación es idempotente, lo que permite reintentar sin temor a duplicar recursos, y queda registrada paso a paso en el audit log cross-product.

La tercera capa es el audit cross-product con sanitización de secrets. El trigger SQL audit_trigger() SECURITY DEFINER escribe en emashared.audit_log cada mutación a doce tablas críticas (contracts, vault_users, fiscal_config, organizations, tenants, products, releases, leads, invoices y otras). Cualquier campo cuyo nombre contenga password, token, secret, api_key, private_key o aidbox_client_secret_encrypted se reemplaza por [REDACTED] antes de loggear. El resultado es un registro completo y queryable de la actividad operacional sin riesgo de exponer credenciales.

La cuarta capa es el pipeline comercial con AI integrada. El módulo de pipeline opera como kanban de siete etapas con conversión automática de lead a cliente, métrica de pipeline value ponderado y linkeo con conversaciones del chatbot público (cuando un lead viene de EMI, el sistema asocia las invocaciones del agente al lead con un badge violeta visible). Sobre eso, tres endpoints AI corren contra Anthropic Sonnet para generar propuestas comerciales, resumir contratos largos y producir resúmenes ejecutivos de leads.

La quinta capa es el módulo de producto unificado. Vault mantiene un catálogo vivo de los once productos de EMA Health, con sub-páginas por producto: dashboard, issues sincronizados desde GitHub (webhook + cron horario), backlog de features, journeys editables, estructura de módulos, tech stack, releases con changelog y roadmap con capas inline-editables. Cuando un developer cierra un issue en GitHub, el webhook actualiza la cache local y, si el issue está vinculado a un feature del backlog, la feature se cierra automáticamente.

A esto se suman piezas funcionales más acotadas pero igualmente relevantes. Las finanzas multi-moneda trabajan con CLP, USD, UF y EUR como divisas habituales, actualizadas diariamente desde la fuente oficial del país (en Chile, Banco Central; otros países conectarían con su organismo equivalente). La configuración de facturación electrónica por cliente captura los certificados digitales y los ambientes del organismo fiscal local (en el plug-in chileno, los ambientes maullin y palena del SII; en plug-ins futuros de otros países, los ambientes equivalentes). La gestión EMI expone una matriz de acceso por tenant y aplicación más analytics de invocaciones a treinta días. Y las métricas agregadas de Ema Well se exponen en modo read-only desde un proyecto Supabase separado, lo que respeta las leyes de protección de datos de salud del país operativo (en Chile, Ley 21.719; otros países aplicarían LGPD, HIPAA, GDPR según corresponda).

Estado del producto

La versión actual es 0.2.0, con Wave 3 v1.0 y el sprint S9 cerrado en main. El sistema está en producción en vault.emahealth.io con uso diario del equipo. Los hitos más relevantes del último ciclo incluyen el provisioning orquestado cross-product (decisión F068, S9-1), las helpers AES-GCM para encriptar secrets de Aidbox (F075, S9-3), el proxy server-side para EMI (F078), el audit log de invocaciones EMI (F080), la matriz de acceso por aplicación (F082), el lead linking con conversaciones del chatbot público (F083) y el audit trigger SECURITY DEFINER con sanitización de secrets (F085).

Fuera del alcance

Vault es deliberadamente acotado. No es un CRM cliente final: no existe portal cliente, no se exponen datos a clientes externos. No es un ERP completo: las finanzas son operativas (entries, MRR, exchange rates) pero la contabilidad legal sigue viviendo en Defontana o el contador externo, ya que reproducir un ERP completo no está en el alcance ni en el ROI del equipo. No genera documentos fiscales: esa responsabilidad la cumple emadte (en Chile contra SII, en otros países contra el organismo equivalente). Vault solo configura los parámetros fiscales por cliente. No reemplaza GitHub: el módulo de producto sincroniza issues pero el repositorio sigue siendo source of truth. Y por última, los datos individuales de Ema Well no son accesibles desde Vault: por requerimientos de protección de datos de salud (en Chile la Ley 21.719, equivalentes en otros países), ese producto vive en un proyecto Supabase aislado y Vault solo consulta métricas agregadas.