Todavía no trabajamos con seguros. Esto es lo que sí está construido.

Un financiador de salud evalúa controles, no promesas. AkiVeo+ no tiene hoy integración con ninguna isapre ni compañía de seguros, y lo decimos antes de la reunión. Lo que sí existe es un recorrido donde el precio sale del catálogo que cargan los laboratorios, donde una oferta con topes declarados no se propone si no cubre la graduación de la receta, y donde cada cambio de estado se escribe como un evento aparte que la aplicación no ofrece editar. Eso se puede auditar hoy, línea por línea.

Lo que un financiador esperaría y todavía no está

Preferimos decirlo antes de conversar. Ninguna de estas tres cosas está a medio construir: no está construida.

  • No existe la aseguradora como actor

    No hay rol de aseguradora ni panel para un financiador. Los roles que existen son usuario, óptica, laboratorio, clínica, tecnólogo, doctor, vendedor y administrador. Trabajar con una isapre implica construir ese actor desde cero.

  • La plataforma no conoce coberturas

    Calcula un precio, no un copago. No sabe qué cubre un plan ni cuánto le toca pagar a cada parte, y no controla cada cuánto una persona puede renovar. Cuando decimos que un cristal "cubre", hablamos de que soporta la graduación de la receta.

  • Sin conexión a sistemas de bonificación

    No hay integración con FONASA ni con bonificación en línea, no se emite documento tributario y no hay contrato de integración ni credenciales para que un tercero se conecte. El cobro al paciente pasa por una pasarela y ahí termina.

Los controles que sí se pueden auditar

  • 01

    El precio sale de un catálogo cargado, no de un cálculo

    El cotizador busca la oferta más económica del catálogo que cargan los laboratorios y cobra ese mismo valor, sin agregar margen ni recargo. Si ninguna fila vigente sirve, el proceso se corta antes de informar un precio. AkiVeo mantiene acceso de administración sobre ese catálogo para cargarlo y corregirlo.

  • 02

    La oferta con topes no pasa si no cubre la graduación

    Una fila de precio puede declarar hasta qué esfera y qué cilindro alcanza ese cristal, y al cotizar se descartan las que no llegan a la graduación de la receta. Dos límites que conviene conocer antes de auditarlo: las filas que no declaran topes se proponen sin ese control — el importador los acepta vacíos — y el tope de adición no se evalúa en el camino principal de cotización.

  • 03

    Un historial que la aplicación solo agrega

    Cada cambio de estado se escribe como un evento aparte, con estado anterior, estado nuevo, responsable, la hora que pone el servidor y las notas, y la aplicación no ofrece editarlos ni borrarlos. En dos tablas —la bitácora de contactos y la foto contable de cada descuento— el bloqueo además no depende del código: la base de datos rechaza el UPDATE y el DELETE. En el historial de derivaciones esa regla todavía no está puesta.

  • 04

    La liquidación sale sin identidad del paciente

    El reporte que recibe un centro médico lleva fecha de cirugía, fecha de alta, quién derivó, origen, estado y comisión. No lleva nombre, ni RUT, ni teléfono, ni motivo de consulta: para cobrar una comisión no hace falta la identidad de nadie.

Dónde se controla cada paso

Cuatro puntos del recorrido donde hay un control escrito, con su límite declarado.

  1. 01

    La lee un modelo, la confirma una persona

    La foto de la receta la lee un modelo y lo que sale queda editable en pantalla. El botón de continuar está bloqueado hasta que la persona marca que revisó los datos, y esa confirmación se guarda con fecha y hora. El límite: la verificación vive en la pantalla — el servidor guarda la marca, no rechaza una cotización que llegara sin ella.

  2. 02

    Manda lo que indicó el médico

    La búsqueda parte por el tratamiento que el profesional marcó en la receta — antirreflejo y fotocromático, los que el catálogo admite hoy — y si pidió alto índice, sube el índice al buscar. El límite es una cascada: si el catálogo no publica esa combinación, se reintenta con un cristal por defecto de índice 1.5, y si tampoco lo hay, con cualquier cristal de ese tipo aunque no traiga el tratamiento indicado. Solo el primer descarte queda advertido en el registro del servidor.

  3. 03

    Los estados avanzan por un camino declarado

    Las transiciones válidas viven en el dominio, fuera de los routers y de las pantallas, y es el servidor el que valida contra ese mapa antes de aceptar un cambio. La cadena clínica no admite retrocesos y cada rol tiene declarado qué puede ejecutar: el ejecutivo mueve el flujo, el tecnólogo solo cierra el seguimiento.

  4. 04

    El acceso se separa por convenio y por rol

    Existe un rol que entra, ve la bandeja, el detalle, el historial y la liquidación, y no puede cambiar ningún estado: la pantalla se lo dice y el servidor lo rechaza. Cada persona ve únicamente los convenios donde está mapeada, y las tablas de este flujo se crean con seguridad a nivel de fila activada en la base.

Si le sirve lo que hay, construyamos lo que falta sin vender lo que todavía no existe

Cualquier persona puede ejercer sus derechos sobre sus datos desde una página abierta, sin tener cuenta, con número de ticket y un plazo de respuesta de 30 días escrito en el código; la política publicada nombra la Ley 21.719 y al encargado de protección de datos. Lo que no tenemos es certificación de seguridad ni auditoría externa: lo que podemos mostrar es el detalle de los controles en el código y en las migraciones de la base.