SaludPay — la capa transaccional conversacional de la salud chilena
Plataforma que reemplaza las interacciones de mostrador (iMED) por un chat asistido por IA: el paciente se autentica, cotiza su bono con cobertura real y paga el copago desde la conversación. Evolución horizontal de AIYA (aiyatecuida.com), operada por AIYA SpA.
Estado
AIYA en producción; SaludPay en especificación avanzada con sandbox PlexoTech.
Hito vigente
Cierre del MOU y confirmación de clínica + ISAPRE + aseguradora piloto.
Go-live piloto
1 clínica, 1 ISAPRE y 1 aseguradora con transacciones reales.
Mercado objetivo
Transacciones anuales de bono/copago en Chile (TAM del reemplazo de iMED).
Propuesta de valor
- Paciente: resuelve bono y copago desde el chat (Telegram en MVP, WhatsApp en producción), con OTP en caja en vez de huella. Sin apps nuevas ni filas.
- Prestador: integración REST de 3 endpoints en ~4 semanas; menos tiempo en caja (<2 min objetivo) y nuevo canal de cobro del copago.
- ISAPRE / aseguradora: cobertura aplicada en línea vía PlexoTech, sin proyectos de integración propios.
- Compliance por diseño: cero biometría almacenada (vive en Sovos) y minimización de PAN (token + últimos 4 dígitos vía Lups).
Hitos del proyecto
| Fecha | Hito | Estado |
|---|---|---|
| 08-11-2024 | Constitución de Sinergix SpA (vehículo predecesor de la tesis). | Hecho |
| Jun 2025 | Constitución de AIYA SpA como joint venture; RUT e inicio de actividades (28-07-2025). | Hecho |
| 2H 2025 | Lanzamiento de AIYA (aiyatecuida.com) con pacientes reales. | Hecho |
| 1H 2026 | Validación del modelo de costos, 21 ADRs, diseño cero-biometría, evaluación LLM/BSP. | Hecho |
| May 2026 | Documento estratégico «De AIYA a Salud Pay» (v2) en circulación a socios. | Hecho |
| Jun–Jul 2026 | Cierre de MOU PlexoTech y contratos Sovos/Lups; build de agente y backend. | En curso |
| Ago 2026 | Go-live del piloto (1 clínica + 1 ISAPRE + 1 aseguradora). | Pendiente |
Equipo del proyecto
| Nombre | Rol | Organización | Contacto |
|---|---|---|---|
| Julio Lolas Martínez | Representante legal · Contacto único · Decisiones estratégicas | AIYA SpA | julio@aiyatecuida.com |
| Francisco | Operación técnica y estratégica · Modelo de costos · Evaluación LLM/BSP | AIYA SpA / Junngla | francisco@junngla.com |
| Por confirmar | CTO / Arquitecto · ADRs y stack | AIYA SpA | — |
| Por confirmar | PM Comercial · clínicas, ISAPREs, aseguradoras | AIYA SpA | — |
| Por confirmar | Seguridad / Compliance · Ley 21.719 | AIYA SpA | — |
Bitácora del proyecto
Fuente de verdad del proyecto: pendientes por responsable, acuerdos y registro de sesiones. Última actualización: 8 de julio de 2026 (hora de Chile continental).
Pendientes por responsable
| ID | Responsable | Pendiente | Prioridad | Estado |
|---|---|---|---|---|
| P-01 | Julio Lolas — AIYA SpA | Cierre del MOU definitivo con PlexoTech. | Alta | En curso |
| P-02 | Julio Lolas — AIYA SpA | Confirmar clínica, ISAPRE y aseguradora piloto. | Alta | Pendiente |
| P-03 | Julio Lolas — AIYA SpA | Cierre de contratos con Sovos (KYC) y Lups (pagos). | Alta | En curso |
| P-04 | Francisco — Operación técnica | Selección de modelo LLM final (Nova Lite · Haiku · Sonnet · GPT-4o mini). | Media | Pendiente |
| P-05 | Francisco — Operación técnica | Selección de BSP de WhatsApp (Meta directo · 360dialog · Twilio · Gupshup). | Media | Pendiente |
| P-06 | Francisco — Operación técnica | Decisión de región AWS (us-east-1 vs sa-east-1; criterio: regulación + residencia de datos). | Media | Pendiente |
| P-07 | CTO / Arquitecto — por confirmar | Build del agente IA (tools tipadas, prompts, memoria, guardrails clínicos). | Alta | Pendiente |
| P-08 | CTO / Arquitecto — por confirmar | Build del backend REST del prestador e integración SOAP con PlexoTech. | Alta | Pendiente |
| P-09 | Compliance — por confirmar | Auditoría externa de cumplimiento Ley 21.719 previa al go-live. | Media | Pendiente |
| P-10 | Francisco — Operación técnica | Registrar las HH históricas por persona y actividad (resumen de esfuerzo). | Baja | Pendiente |
Acuerdos y decisiones
Registro de las decisiones de negocio: cuándo se tomaron y quién las tomó. Cada acuerdo nuevo se agrega arriba. Los acuerdos son inmutables: uno nuevo reemplaza a otro citándolo.
| ID | Fecha | Acuerdo / decisión | Quién decidió |
|---|---|---|---|
| A-07 | 08-jul-2026 | El BBP (este archivo) reemplaza a la bitácora Word como fuente de verdad del proyecto; la bitácora del 29-06-2026 queda como antecedente histórico. | Francisco |
| A-06 | 29-jun-2026 | Puesta en marcha de una bitácora viva como fuente de verdad, con panel de pendientes, avances y esfuerzo (HH). | Francisco |
| A-05 | 1H 2026 | El copago se puede pagar in-app vía Lups (tarjeta tokenizada one-click); el share se reparte entre SaludPay y el prestador. Pago en caja sigue disponible. | Julio Lolas · Francisco |
| A-04 | 1H 2026 | Agente IA con tools tipadas (schema JSON estricto), no árbol de menú. El agente nunca calcula reembolsos localmente: siempre consulta al core. (ADR-008) | Equipo técnico |
| A-03 | 1H 2026 | PlexoTech como hub integrador de cores ISAPRE/seguros (Web Service Complementario v7.3 SOAP); se descarta integración directa por entidad. | Julio Lolas |
| A-02 | 1H 2026 | Cero biometría almacenada: la verificación (cédula + Face ID) vive en Sovos; SaludPay solo recibe «verificado sí/no». (ADR-007) | Equipo técnico · Julio Lolas |
| A-01 | May 2026 | Evolución de AIYA (vertical de adherencia) a SaludPay (capa transaccional horizontal que reemplaza iMED). Formalizado en el documento estratégico «De AIYA a Salud Pay» v2. | Julio Lolas · socios |
Registro de entradas
Entrada 002 — Migración al BBP estándar
Se creó este BBP (saludpay-bbp.html) según las reglas generales BBP y el template estándar, aplicando el brand SaludPay (teal del isotipo). Se migró el contenido de la bitácora Word del 29-06-2026: pendientes (P-01 a P-10), acuerdos históricos (A-01 a A-06) y cronología de hitos. Se estructuraron las secciones Producto, Negocio y Legal (incluido el checklist Ley 21.719) desde el contexto integral del proyecto.
Acuerdo A-07: este BBP es la fuente de verdad. Próximos pasos: P-01 (MOU PlexoTech), P-02 (piloto), P-04/P-05 (LLM y BSP), P-10 (HH históricas).
Entrada 001 — Puesta en marcha de la bitácora
Revisión del material de la carpeta (contexto integral, documentos de sociedad, NDA). Consolidación del historial real con fechas verificadas de los documentos legales (constitución, extracto, RUT, inicio de actividades). Construcción del panel de control con avances, pendientes por responsable y resumen de esfuerzo (HH por registrar).
Acuerdo A-06 (bitácora viva). Próximos pasos: registrar HH históricas (P-10), cerrar MOU PlexoTech (P-01), confirmar piloto (P-02), avanzar en selección de LLM y BSP (P-04, P-05).
Preguntas frecuentes
Respuestas oficiales para socios, prestadores e inversionistas.
¿Qué es SaludPay y en qué se diferencia de iMED?
¿Qué relación hay entre AIYA y SaludPay?
¿Dónde vive la biometría del paciente?
¿Cómo gana dinero SaludPay?
¿Cuándo y cómo parte el piloto?
¿Qué pasa si PlexoTech falla?
Fuentes: AIYA_CONTEXT_EXPORT_COWORK.md (29-05-2026) · Documento estratégico «De AIYA a Salud Pay» v2 (mayo 2026) · Bitácora SaludPay (29-06-2026).
Producto y alcance
Agente conversacional de IA (Claude, con tools tipadas) que orquesta autenticación, cotización con cobertura y pago del copago, sobre Telegram (MVP) y WhatsApp (producción).
Alcance del MVP
- Incluido: bono y copago en clínicas — onboarding KYC, OTP en caja, cotización con cobertura ISAPRE + seguro complementario, pago in-app opcional.
- Fase 2 (post-piloto): WhatsApp Cloud API, farmacia (receta-a-compra), más prestadores.
- Fase 3 (2027+): agendamiento de horas, procesamiento automatizado de recetas, dashboard de gastos y coberturas.
Segmentos de clientes
- Paciente (y sus cargas): afiliado a ISAPRE con o sin seguro complementario; resuelve la transacción desde el chat.
- Prestador: clínicas, hospitales y centros médicos (farmacias en Fase 2); integra 3 endpoints REST.
- Pagadores: ISAPREs y aseguradoras de seguros complementarios, conectados vía PlexoTech.
Stack e integraciones
| Pieza | Proveedor | Rol | Estado |
|---|---|---|---|
| Agente IA | Claude (Anthropic) + Vercel AI SDK | Conversación, tools tipadas, memoria, guardrails clínicos. Modelo final por definir (P-04). | Confirmado |
| Canal MVP | Telegram Bot API (grammy) | Iteración rápida del piloto, sin BSP. | En uso |
| Canal producción | WhatsApp Cloud API (BSP por definir, P-05) | Canal masivo de producción. | En curso |
| KYC | Sovos | Verificación cédula + Face ID; cero biometría almacenada en SaludPay. | Contrato en firma |
| Pagos | Lups | Tokenización, one-click, webhooks, liquidación al prestador. | Contrato en firma |
| Cores ISAPRE/seguros | PlexoTech (SOAP v7.3) | Cotización y aplicación de cobertura en línea. | MOU en negociación |
| Datos | PostgreSQL + pgvector (AWS RDS) | Transaccional + embeddings (RAG); región AWS por definir (P-06). | Confirmado |
| Hosting | Vercel | Despliegue del backend (ADR-018). | Confirmado |
Operación
Cómo funciona la transacción de punta a punta y cómo se integra un prestador nuevo.
Journey del paciente
- Onboarding (una vez): alta por chat con RUT + celular + email; verificación de identidad en Sovos (cédula + Face ID). Registro opcional de tarjeta tokenizada en Lups.
- En caja: el paciente pide su OTP por chat (vigencia 2 min) y lo entrega en el mostrador — reemplaza la huella de iMED.
- Cotización: el prestador consulta la prestación; SaludPay cotiza vía PlexoTech aplicando ISAPRE y seguro complementario, y muestra el copago resultante.
- Pago: el paciente elige pagar el copago en caja o in-app (one-click Lups). Confirmación y compensación cierran la transacción.
Integración del prestador (ciclo típico: 4 semanas)
| Semana | Actividad | Entregable |
|---|---|---|
| 1 | Implementación de /sessions/authenticate (OTP + ficha del paciente). | Autenticación exitosa 100 veces sin error. |
| 2 | Implementación de /quotes (cotización de prestaciones). | Cotización con 5+ ISAPREs/seguros sin timeout. |
| 3 | Implementación de /transactions/confirm (cierre y compensación). | Transacción end-to-end sin pérdida de datos. |
| 4 | UAT extremo a extremo, ajustes, paso a producción. | Go-live con monitoreo intensivo 2 semanas. |
SLA y métricas objetivo
OTP
Tiempo total de autenticación en caja.
Cotización
Target aspiracional; <8 s realista por latencia SOAP de PlexoTech (2–5 s).
Pago in-app
One-click con tarjeta tokenizada en Lups.
Uptime PlexoTech
SLA del hub de cores; cacheo de coberturas 15–30 min como mitigación.
Riesgos operativos principales
| Riesgo | Mitigación | Impacto |
|---|---|---|
| Concentración en PlexoTech (sin fallback de cores). | SLA contractual, escalation path, monitoreo de latencia, cacheo de coberturas. | Alto |
| Costo de mensajería a escala (utility messages 2–3x más caros). | Diseño conversacional con 70% de tráfico patient-initiated (ventana gratuita de 24 h); batching de recordatorios. | Alto |
| Ciclo de integración del prestador se alarga (4 → 8–12 semanas). | DRI desde el kickoff, UI web simulada, ejemplos Postman/cURL, office hours semanales. | Medio |
| Alucinación del agente en coberturas. | El agente nunca calcula reembolsos: consulta al core y muestra la respuesta; tools con schema validation; suite de 100+ casos borde. | Bajo |
Modelo de negocio
Monetización doble sobre la transacción de salud. Toda cifra definitiva de pricing debe nacer de un acuerdo A-XX de la bitácora; las cifras de esta sección son parámetros validados del modelo de costos.
Fuentes de ingreso
- Fee por transacción de bono: análogo al rol de iMED; se cobra por cada bono emitido vía SaludPay. Estructura exacta por definir (piso mínimo, descuento por volumen).
- Share del copago in-app: cuando el paciente paga por el chat vía Lups, el margen se reparte entre SaludPay y el prestador (acuerdo A-05). Conversión esperada: 15–25% en MVP, 40–60% en madurez.
Parámetros validados del modelo de costos
Mensajes / paciente / día
Promedio operativo validado en AIYA.
Mix de mensajes
70% patient-initiated (ventana gratuita 24 h) · 30% business-initiated (utility, de pago).
Escala de equilibrio
Pacientes activos donde el costo unitario se estabiliza.
BSP directo vs reseller
Ahorro de Meta Cloud API directo frente a Twilio/resellers a escala.
Palancas de pricing a definir
- Fee por transacción: monto, piso mínimo y descuentos por volumen (¿transparente o negociado por prestador?).
- Reparto del share del copago in-app entre SaludPay y prestador.
- Modelo LLM final (P-04) y BSP de WhatsApp (P-05): impacto de ±15–20% en unit economics.
- Horizonte de rentabilidad: break-even objetivo 18 meses post-piloto (por confirmar como acuerdo).
Marco regulatorio
Normativa aplicable a una plataforma transaccional de salud con pagos y datos sensibles en Chile.
| Norma / requisito | Alcance | Estado |
|---|---|---|
| Ley 21.719 — Protección de datos personales | Datos de salud (sensibles), biometría, derechos ARSOP. Vigencia plena 01-12-2026, antes del escalamiento post-piloto. | Diseño conforme · auditoría pendiente (P-09) |
| Ley 19.628 (régimen actual de datos) | Tratamiento de datos personales hasta la entrada en vigencia de la 21.719. | Cumple |
| KYC en transacciones financieras | Verificación de identidad del paciente (RUT + celular + email + Face ID en Sovos) antes de habilitar pagos. | Contrato Sovos en firma (P-03) |
| Minimización de datos de tarjeta (PAN) | Solo token y últimos 4 dígitos en SaludPay; captura y tokenización en Lups. | Por diseño |
| Normativa de ISAPREs (Superintendencia de Salud) | Aplicación de cobertura y emisión de bonos vía cores oficiales (a través de PlexoTech, que mantiene los contratos con las entidades). | Vía PlexoTech (MOU, P-01) |
| NDA y confidencialidad | NDA HESARA–AIYA (11-08-2025); especificación técnica, 21 ADRs y contratos bajo NDA. | Vigente |
Ley 21.719 — Protección de datos personales
Vigencia plena: 1 de diciembre de 2026. SaludPay trata datos sensibles de salud, por lo que el cumplimiento es condición de go-live y de escalamiento.
Mapa de datos que trata el proyecto
| Dato | Finalidad | Base de licitud | Sensible |
|---|---|---|---|
| RUT, celular, email | Identificación y onboarding del paciente. | Ejecución de contrato / consentimiento | No |
| Verificación biométrica (cédula + Face ID) | KYC en el alta. Se procesa en Sovos; SaludPay no la almacena (A-02, ADR-007). | Consentimiento explícito | Sí |
| Prestaciones, coberturas y copagos | Cotización de bono y aplicación de cobertura vía PlexoTech. | Ejecución de contrato | Sí (dato de salud) |
| Token de tarjeta + últimos 4 dígitos | Pago in-app one-click. PAN completo vive en Lups. | Ejecución de contrato / consentimiento | No (minimizado) |
| Historial conversacional + embeddings (pgvector) | Memoria del agente (RAG) y continuidad de atención. | Consentimiento / interés legítimo (por validar) | Potencialmente |
Checklist de cumplimiento
| Ítem | Estado | Responsable |
|---|---|---|
| Diseño cero-biometría y minimización de PAN | Hecho | Equipo técnico (A-02) |
| Consentimiento y avisos de privacidad (chat + web) | Pendiente | Compliance (P-09) |
| Derechos del titular (ARSOP + bloqueo) | Pendiente | Compliance (P-09) |
| DPA con encargados (Sovos, Lups, PlexoTech, Anthropic, AWS/Vercel) | En curso | Julio Lolas (P-03) · asesores legales |
| Registro de actividades de tratamiento (RAT) | Pendiente | Compliance (P-09) |
| EIPD (evaluación de impacto — datos sensibles de salud) | Pendiente | Compliance (P-09) |
| Protocolo de brechas y notificación | Pendiente | Compliance (P-09) |
| Decisión de región AWS con criterio de residencia de datos | Pendiente | Francisco (P-06) |
| Auditoría externa previa al go-live + seguro de ciberresponsabilidad | Pendiente | Compliance (P-09) |
Hitos e histórico de avances
Logros y avances ya cerrados del proyecto, en orden cronológico (los más recientes arriba). Complementa la bitácora. IDs T-XX, únicos y no reciclables.
| ID | Fecha | Hito / avance logrado | Estado |
|---|---|---|---|
| T-01 | [DD-mmm-AAAA] | [Hito o avance ya cumplido — reubicar acá el histórico que hoy esté en Inicio/Bitácora] | Hecho |
Mock / demos
Maquetas y demos en construcción para el cliente, aún no productivas. Archivos en la carpeta 02-[proyecto]-mock.
| Maqueta / demo | Qué muestra | Estado | Enlace |
|---|---|---|---|
| [Nombre] | [Qué demuestra] | En curso | [abrir] |
Web / plataformas
Webs y plataformas productivas del proyecto. Repo en la carpeta 01-[proyecto]-web.
| Web / plataforma | URL productiva | Estado | Repo |
|---|---|---|---|
| [Nombre] | [url] | En producción | 01-[proyecto]-web |
Riesgos
Riesgos del proyecto (negocio, operación, legal, técnico) con impacto, probabilidad y mitigación. IDs R-XX.
| ID | Riesgo | Impacto | Probabilidad | Mitigación |
|---|---|---|---|---|
| R-01 | [Riesgo — reubicar acá los riesgos que ya estén dispersos en otras secciones] | Alto | Media | [Mitigación · P-XX] |