Salud (healthcare) · Demo: /demo/cuentas-medicas · Modo de acceso recomendado: privado (solo por invitación del admin, primera sesión guiada obligatoria) · Prioridad: P1 · Esfuerzo total: XL (≈ 16 semanas de 1 dev senior + un auditor médico por horas para dejar una demo privada vendible y el Piloto de auditoría; el producto completo de cada cliente se estima aparte)

Captura actual de /demo/cuentas-medicas en producción: el tablero abre con el aviso "No se pudieron cargar las estadísticas. Verifique que el servidor esté corriendo." y sin datos. Ver también Sistema de demos, Flujo del cliente, Catálogo de productos, Seguridad y calidad y Roadmap. Relacionados: Motor de reglas del auditor (sistema experto), que se integra en este producto; Sistemas RAG y la landing /rag/salud; Facturación electrónica (factura en salud y RIPS); Telemedicina.

Problema: en Colombia, cada factura de una IPS a una EPS (o a una aseguradora SOAT, ARL o prepagada) pasa por una auditoría de cuentas que puede terminar en devolución o glosa. Las IPS pierden flujo de caja por glosas evitables (tarifa distinta a la del convenio, autorización vencida, soporte faltante, códigos mal asignados) y los pagadores y firmas auditoras revisan muestras a mano porque no alcanzan a revisar todo. La información llega en PDF (factura, epicrisis, autorizaciones), en RIPS y en contratos con tarifas distintas por pagador ("SOAT −15 %", "ISS 2001 +30 %", paquetes).

Para quién (cliente ideal en Colombia):

• Firmas de auditoría de cuentas médicas que auditan por encargo de pagadores: compran productividad por auditor y deciden rápido. Primer objetivo comercial.
• IPS de mediana y alta complejidad (clínicas, hospitales privados, ESE grandes): pre-auditoría antes de radicar para reducir glosas y devoluciones. Compra el área financiera o de cuentas médicas.
• Pagadores (EPS, aseguradoras SOAT, ARL, medicina prepagada, regímenes especiales): auditoría del 100 % de lo radicado. Ciclo de compra largo; plan Empresarial.

Propuesta de valor: "Revisa el 100 % de las cuentas, no una muestra. La IA lee la factura, los RIPS y los soportes; el motor aplica las reglas de tu convenio y propone cada glosa con su evidencia y su norma; el auditor decide. Entrega en Excel con tu plantilla y tablero de valor glosado por causa."

Qué es según su código (para el reposicionamiento RAG): no es un RAG. Es un sistema experto híbrido: extracción con IA (texto y visión) + motor de reglas + catálogos (CUPS, CIE-10, tarifarios) + una decisión asistida por un modelo de lenguaje. El flujo de auditoría que usa la demo no usa embeddings ni búsqueda vectorial (solo la búsqueda de CUPS de la consola del Motor de reglas los usa), y la "Base de conocimiento" de la pantalla Administración es texto fijo dentro del bundle que no alimenta respuestas con cita. Por la regla de la especificación RAG (con búsqueda vectorial: "Caso RAG"; sin ella: "Sistema experto para salud"), la etiqueta correcta hoy es "Sistema experto para salud": en /rag/salud la tarjeta dice "Auditoría de cuentas médicas · Sistema experto para salud", con el botón "Solicitar demo personalizada". El puente con el producto principal es un módulo nuevo "Consulta normativa y contractual con citas" (RAG sobre contratos, manuales tarifarios y normas, con el núcleo de los Sistemas RAG, tarea 11); cuando exista, la tarjeta pasa a "IA + reglas + consulta con citas".

Veredicto: sí entra al catálogo, como producto 28 en la categoría Salud, con estas condiciones:

1. Modo privado (DECISIÓN 1): nunca abierto, solo por invitación del admin.
2. Venta consultiva con un Piloto de auditoría de precio cerrado, igual que el Piloto RAG.
3. No se publica la landing hasta cerrar las tareas de la Fase 0 de este documento (endurecimiento y datos sintéticos).
4. Planes propios por volumen de facturas, no la fórmula genérica de 4 planes de services-catalog.ts.

Alternativas descartadas: (a) dejarlo como herramienta interna o caso de estudio: desperdicia la mayor inversión técnica y la única credencial en salud; (b) abrirlo como SaaS de autoservicio: no hay base multi-tenant ni el marco legal para recibir historias clínicas de cualquier visitante (DECISIÓN 7).

Nombre comercial: "Auditoría de Cuentas Médicas con IA" (corto: "Auditoría Médica IA"). Slug propuesto del offering: auditoria-cuentas-medicas; el demoSlug sigue siendo cuentas-medicas. En DemoCatalogItem, offeringSlug pasa de nulo a auditoria-cuentas-medicas. Landing: /productos/auditoria-cuentas-medicas, enlazada desde /rag/salud.

Lo que hace bien: el flujo central existe de punta a punta: se sube un lote (PDF y Excel/RIPS), la IA extrae factura, paciente, diagnósticos y procedimientos, el sistema compara contra tarifas, autorizaciones y duplicidades, crea glosas y descarga un Excel de varias hojas. La vista "Proceso paso a paso" explica cada paso con el dato extraído, el archivo y la ubicación de origen (hoja, columna, fila), algo que un auditor valora mucho porque muestra por qué se glosa. Ya hay modelos de datos del dominio colombiano (radicados, convenios, cuotas moderadoras, autorizaciones), un servicio de aprendizaje con retroalimentación humana y conectores configurables a sistemas externos (gestor documental, consulta de autorizaciones).

1. Falla en producción: el tablero muestra el error de estadísticas y el sistema experto muestra ceros: los catálogos no están cargados en el entorno o el servicio no responde. Hoy no se puede mostrar a nadie (ver Landings SEO).
2. Atado a un pagador real: 83 referencias a una EPS real en 12 archivos del backend (tarifario de 14 códigos en glosa-calculator.service.ts, paso "Validación de medicamentos SISMED - " en ProcesoAuditoriaVisual.tsx, Excel Auditoria_<EPS>_….xlsx en api.ts). Sugiere una relación comercial que no existe y no sirve para otro cliente.
3. Cifras y fuentes que no se pueden respaldar: "Base SISPRO actualizada con 12.457 códigos" cuando el contenido son unas 435 líneas; "Tarifario SOAT 2024" y "Manual ISS 2001" con valores en pesos inventados; precios de medicamentos "negociados" por EPS reales (page.tsx); "Reduce rechazos hasta 80 %" en la metadata. Algunos códigos de ejemplo no corresponden a la CUPS vigente.
4. La IA "decide": auditor-ia-final.service.ts se documenta como la "decisión final" sobre la glosa y el "monto exacto a pagar". En auditoría de cuentas la decisión y la firma son del auditor; la IA debe proponer con evidencia.
5. Códigos de glosa propios: las reglas usan una numeración interna (101, 201, 301, 401) que no sigue el Manual Único de Devoluciones, Glosas y Respuestas vigente. Un auditor lo nota en el primer minuto.
6. Flujo fragmentado: seis caminos de procesamiento, cuatro formatos de Excel y tres sistemas de reglas (ver Motor de reglas). Mantener y explicar esto es inviable.
7. Mezcla de simulado y real sin aviso: "Ver proceso" desde el tablero muestra una simulación con "FAC-2024-001" y $100 M, al lado de facturas reales; al crear una cuenta con "ver proceso" se espera 13 s fijos (setTimeout en page.tsx).
8. Nombres inconsistentes: "Nueva factura" abre "Nueva cuenta de auditoría"; en otras partes se habla de radicado o cuenta médica.
9. Administración engañosa: los interruptores de "documentos de conocimiento" guardan una configuración, pero el contenido que dicen usar es texto fijo del frontend.
10. Ingeniería: página de 2.640 líneas en un solo componente cliente; mockData.ts y types.ts (760 líneas) sin uso; modelos de IA fijados en el código (uno ya retirado por su proveedor) y dos modelos de embeddings distintos para los mismos CUPS; procesamiento síncrono de hasta 15 min; archivos en disco efímero.
11. Seguridad y privacidad: antes de recibir cualquier documento de un prospecto, el módulo necesita la auditoría general de autenticación y autorización en servidor, el aislamiento de datos por cliente, los límites de costo de IA y la revisión del manejo de datos personales en registros (logs) descritos en Seguridad y calidad.
12. Detalles de presentación: emojis en títulos ("🏥", "🤖", "✨"), "Características del sistema" genérico en el tablero, botones sin estados de carga, "Volver a Demos" a un hub donde la demo no aparece.

• Que funcione y sea segura: Fase 0 completa para este módulo (ver tareas 1 y 2) y la demo estable en producción.
• Datos 100 % sintéticos y verosímiles, revisados por un auditor médico: IPS y EPS ficticias, facturas en PDF con marca de agua, RIPS, soportes y convenios de ejemplo, con un error sembrado por cada regla.
• Un solo flujo explicable: carga → extracción → validación → reglas → propuesta de glosa con evidencia → decisión del auditor → reporte.
• Lenguaje del sector: códigos del manual único de glosas, causales, plazos de respuesta, convenios por pagador.
• Las tres vistas de quien compra: IPS (pre-radicación y respuesta a glosas), auditor (bandeja de revisión) y gerencia (valor glosado por causa).
• Honestidad comercial: sin cifras de resultado prometidas; las métricas salen del Piloto con datos del cliente.
• Oferta de entrada de bajo riesgo: el Piloto de auditoría con informe comparativo frente al auditor humano.
• Paquete legal: contrato de transmisión de datos, acuerdo de confidencialidad y política de retención listos antes del primer piloto.

Estructura común de Landing de producto, enlazada desde la tarjeta "Auditoría de cuentas médicas" de /rag/salud:

1. Hero: "Audita el 100 % de tus cuentas médicas, con evidencia en cada glosa". Subtítulo: "La IA lee facturas, RIPS y soportes; el motor aplica las reglas de tu convenio; tu auditor decide. Para IPS, firmas auditoras y pagadores en Colombia." CTA principal "Solicitar demo personalizada" (modo privado), secundario "Agendar llamada".
2. Dos caminos (pestañas): "Soy IPS: reduce glosas antes de radicar" y "Audito cuentas: revisa todo, no una muestra".
3. Cómo funciona (5 pasos ilustrados con capturas de la demo nueva): carga del lote → lectura con IA → reglas del convenio → propuesta de glosa con evidencia → decisión y reporte.
4. Qué revisa (tabla): tarifa frente al convenio, autorización y vigencia, cantidades autorizadas, duplicidades, códigos CUPS y CIE-10 válidos, coherencia diagnóstico–procedimiento (como alerta para el auditor), soportes faltantes, plazos de radicación.
5. La IA propone, el auditor decide (bloque destacado): explicabilidad, trazabilidad y retroalimentación.
6. Datos y seguridad (bloque sobrio, sin sellos): datos sensibles bajo la Ley 1581, rol de Koptup como encargado, espacio aislado por cliente, cifrado, registro de accesos, retención y borrado, proveedor de IA y dónde se procesan los datos.
7. Capturas (6) y video de 90 s del recorrido guiado.
8. Planes: Piloto, Esencial, Profesional, Empresarial (tabla de esta página).
9. Preguntas frecuentes: ¿Reemplaza al auditor? · ¿Qué formatos recibe (PDF, RIPS JSON, Excel)? · ¿Funciona con mis convenios y tarifas? · ¿Usa el manual único de glosas? · ¿Dónde quedan los datos y cuánto tiempo? · ¿Puedo probar con mis facturas? (sí, en el Piloto con contrato) · ¿Se integra con mi gestor documental o plataforma de radicación? · ¿Cuánto cuesta por factura?
10. CTA final con el formulario de solicitud (campos extra abajo) y aviso visible: "No adjuntes facturas ni datos de pacientes en este formulario".

noindex no aplica a la landing (sí se indexa); la demo sí lleva noindex y sale del sitemap.

Recorrido guiado (5 pasos, menos de 6 minutos):

flowchart LR
  A["1. Cargar paquete de ejemplo: 12 facturas, RIPS y soportes"] --> B["2. Ver lo que leyo la IA: PDF y datos lado a lado"]
  B --> C["3. Reglas del convenio: 7 glosas propuestas con evidencia"]
  C --> D["4. Decision del auditor: aceptar, ajustar o descartar"]
  D --> E["5. Reporte Excel y tablero por causa"]
  E --> F["CTA: Solicitar piloto de auditoria"]

Ver diagrama como imagen

1. Carga: el prospecto elige "Usar paquete de ejemplo" (lote de "Clínica Demo Los Andes" a "EPS Andina Demo").
2. Extracción: abre una factura y ve los campos resaltados en el PDF, la confianza y el cruce con los RIPS.
3. Reglas: el motor marca 7 hallazgos (tarifa, autorización vencida, cantidad excedida, duplicidad, CUPS inexistente, soporte faltante, coherencia diagnóstico–procedimiento como alerta), cada uno con su código oficial y la cláusula del convenio.
4. Decisión: acepta 5, ajusta 1 y descarta 1 con nota; el tablero se actualiza.
5. Reporte: descarga el Excel con la plantilla y ve el valor glosado por causa. Cierre: "Esto con tus facturas, en 4 semanas: Piloto de auditoría".

• Modo privado (DECISIÓN 1 y Sistema de demos): no aparece como abierta en /demo; la tarjeta dice "Con invitación" y el botón "Solicitar demo personalizada". Solo el rol admin aprueba o invita; sales prepara la solicitud y agenda la sesión.
• Se elimina el modal del código de acceso fijo del hub /demo en la misma entrega que activa el control nuevo (sección 10.5 de Sistema de demos). Quienes hoy usan el código reciben una invitación directa personal.
• Puertas de entrada: tarjeta de /rag/salud, landing del producto, invitación directa después de una llamada. Quien abre la demo sin acceso cae en /demo/acceso?demo=cuentas-medicas&motivo=privado:

• Campos extra del formulario: tipo de organización (IPS, firma auditora, EPS o pagador, aseguradora SOAT/ARL/prepagada, otro), facturas por mes, número de auditores o facturadores, número de convenios activos, herramienta actual (Excel, software, ninguno), dolor principal (glosas recibidas, devoluciones, productividad), interés en piloto (sí/no).
• Calificación: organización del sector con NIT; a estudiantes, competidores o perfiles sin relación se les rechaza con motivo y se les envía el video.
• Duración: 14 días (valor por defecto), extensible 14 días desde el admin. Primera sesión guiada obligatoria (selfServiceAllowed = false); después de la sesión el admin habilita el autoservicio. Hasta 3 usuarios por acceso ("Invitar a mi coordinador de cuentas").
• Espacio aislado por acceso: cada DemoGrant trabaja sobre su propio espacio de datos (identificador de espacio = grantId), precargado con el paquete sintético, con botón "Reiniciar datos". Al expirar o revocar el acceso, todo lo cargado se borra en máximo 7 días.
• Cupos (quotas.aiActionsPerDay): 40 facturas procesadas por día por acceso, archivos de hasta 10 MB y 20 archivos por lote. Las APIs del módulo exigen el acceso en servidor (requireDemoGrant('cuentas-medicas'), sección 10.4 de Sistema de demos).
• Qué ve el prospecto aprobado en Mis demos (/dashboard/demos, ver Portal del cliente): tarjeta "Auditoría de cuentas médicas — preparada para <organización>", días restantes, sesión guiada agendada, botones "Abrir como IPS" y "Abrir como auditor", descarga del paquete de ejemplo y CTA "Solicitar piloto de auditoría" / "Agendar llamada".
• Eventos DemoEvent: vista elegida, lote cargado, factura abierta, glosa aceptada/ajustada/descartada, Excel descargado, consulta normativa, pasos del recorrido completados, invitados, clic en CTA.

flowchart TD
  A["Visitante en /rag/salud o en la landing"] --> B["Solicitar demo personalizada"]
  B --> C["DemoRequest pendiente: aviso a admin y sales"]
  C --> D{"Admin revisa: organizacion del sector"}
  D -->|"No califica"| E["Rechazo con motivo y video"]
  D -->|"Califica"| F["Aprobacion: preset IPS o pagador, 14 dias, sesion guiada"]
  F --> G["Enlace magico, prospecto entra a Mis demos"]
  G --> H["Sesion guiada de 30 min con el paquete de ejemplo"]
  H --> I["Autoservicio en espacio aislado"]
  I --> J{"Quiere probar con sus facturas"}
  J -->|"Si"| K["Piloto de auditoria con contrato de transmision"]
  J -->|"No por ahora"| L["Recordatorio y seguimiento comercial"]
  K --> M["Informe del piloto y propuesta"]

Ver diagrama como imagen

La demo nunca usa datos reales, ni siquiera "anonimizados a mano". Se construye un paquete sintético versionado en el repositorio (apps/backend/src/db/seeds/demo-cuentas-medicas/), revisado por el auditor médico asesor:

Si el prospecto quiere probar con sus facturas, eso es el Piloto de auditoría, con contrato y en un espacio aislado propio, no la demo.

Lista orientativa para el dueño y el equipo; validar vigencia y alcance con un abogado de protección de datos y un asesor del sector salud antes de la primera propuesta.

Controles mínimos del producto: cifrado en tránsito y en reposo, espacio aislado por cliente, roles (facturador, auditor, coordinador, administrador), registro de accesos y cambios, política de retención y borrado por contrato, sin datos personales en registros técnicos, copias de seguridad, gestión de incidentes y evaluación de impacto antes del primer piloto. Ver Comercial, marketing y legal.

Desde Admin › Solicitudes de demo › Aprobar (o Admin › Demos › Personalizar), guardado en el DemoGrant (ver Panel de administración):

Implementación: el paquete sintético se siembra por espacio al crear el grant; la página lee la personalización desde GET /api/demo-access/cuentas-medicas (DECISIÓN 3).

Flujo objetivo (uno solo, reemplaza los seis actuales):

flowchart LR
  A["Ingesta: PDF, RIPS y soportes"] --> B["Cola de trabajos"]
  B --> C["Extraccion con IA: texto y vision, confianza por campo"]
  C --> D["Validacion cruzada RIPS vs PDF"]
  D --> E["Catalogos y convenio: CUPS, CIE-10, tarifas"]
  E --> F["Motor de reglas: codigos del manual unico"]
  F --> G["Propuesta de glosa con evidencia y norma"]
  G --> H["Bandeja del auditor: aceptar, ajustar, descartar"]
  H --> I["Reporte, respuesta y conciliacion"]
  H --> J["Retroalimentacion: precision por regla"]
  J --> F

Ver diagrama como imagen

Alcance MVP — modalidad compra (plan Profesional, 10–14 semanas reales):

• Ingesta de PDF, RIPS (estructura vigente) y Excel; clasificación automática de documentos; procesamiento en cola (no dentro de la petición) con reintentos; almacenamiento de objetos cifrado, nunca en el disco del servidor.
• Extracción con IA con confianza por campo, verificación cruzada RIPS vs PDF y revisión humana de campos de baja confianza.
• Catálogos versionados: CUPS, CIE-10 y medicamentos vigentes con su fecha; manuales tarifarios y su actualización anual; importación de las tablas oficiales en lugar de scrapers.
• Convenios (ConvenioTarifa): tarifa por CUPS o por manual ± %, paquetes, exclusiones, servicios con autorización, vigencias.
• Motor de reglas único con códigos del manual vigente y reglas propias (ver Motor de reglas).
• Bandeja de auditoría: la IA propone, el auditor decide; doble revisión por monto; notas; trazabilidad completa.
• Vista IPS: pre-auditoría antes de radicar, respuesta a glosas con plazos, conciliación.
• Reportes: Excel con la plantilla del cliente, PDF del informe, tablero por causa, pagador, prestador y auditor.
• Consulta normativa y contractual con citas (núcleo RAG) sobre contratos, manuales y normas cargados por el cliente.
• Integraciones típicas: gestor documental (p. ej., OnBase, ya hay un conector base en services/endpoint-externo.service.ts), plataformas de radicación, validador de factura electrónica y RIPS, consulta de autorizaciones del pagador, SSO.
• Base técnica: consolidar en un módulo apps/backend/src/modules/cuentas-medicas/ (servicio de dominio + rutas + pruebas), retirar los caminos duplicados, configurar los modelos de IA por variable de entorno y un solo modelo de embeddings.

Modalidad de cobro (DECISIÓN 7): mientras no exista la base multi-tenant con cobro recurrente, se ofrece implementación + operación gestionada en una instancia dedicada por cliente (una instalación aislada por cliente, mensualidad facturada aparte). Es la opción más segura para datos de salud. SaaS multi-tenant: lista de espera hasta la Fase 4; para habilitarlo: aislamiento estricto por cliente verificado con pruebas, contrato de transmisión estándar, SLA, medición de facturas contra el plan y cobro recurrente (Wompi/PayU en COP, Stripe en USD).

No existen planes en el catálogo. Propuesta (COP más IVA si aplica; USD con la TRM de referencia 3.300 de la rama rag-reposicionamiento; a validar con el dueño y con 3 conversaciones de descubrimiento):

Factura adicional sobre el tope: COP 500 · USD 0,15. La mensualidad incluye la instancia dedicada, la IA hasta el tope, actualizaciones normativas y de catálogos, soporte y copias de seguridad.

Recomendaciones de claridad:

1. Hablar en costo por factura auditada (Esencial lleno ≈ COP 1.660 por factura; Profesional lleno ≈ COP 620), que es como compara un jefe de cuentas médicas.
2. No prometer porcentajes de reducción de glosas: el número sale del informe del Piloto.
3. Ley 1581 y seguridad en todos los planes, no como diferencial de un plan.
4. Publicar en la landing qué incluye la mensualidad y qué no (hosting dedicado, IA, soporte; no incluye costos de integraciones de terceros).
5. Política comercial común en Catálogo de productos y Comercial, marketing y legal.

Son metas iniciales a validar con datos reales; no son resultados actuales.

• Interés: ≥ 4 solicitudes calificadas por trimestre (IPS, firmas auditoras o pagadores con NIT) desde /rag/salud y la landing.
• Activación: ≥ 80 % de los aprobados asiste a la sesión guiada; ≥ 60 % procesa el paquete completo; ≥ 40 % descarga el reporte.
• Conversión: 1 Piloto de auditoría en los 6 meses siguientes a la Fase 2; ≥ 50 % de los pilotos termina en contrato.
• Calidad (medida, no prometida): en el set sintético, ≥ 95 % de campos clave extraídos correctamente y ≥ 90 % de exhaustividad por regla; en cada piloto, informe de precisión frente al auditor humano.
• Cumplimiento: 0 datos reales de pacientes en la demo; 0 incidentes de seguridad; 100 % de pilotos con contrato de transmisión firmado antes de recibir datos.