El problema.
Pablo dirige una consulta de traumatología y rehabilitación con dos quirófanos propios, diez centros hospitalarios concertados y más de cuarenta médicos colaboradores repartidos por toda su área. Cada mes, los centros envían fichas de liquidación con los actos y cirugías realizadas: PDFs estructurados con tabla ordenada, XLS sin reglas aplicadas, listados propios con formato inventado por cada hospital, escaneos manuscritos sin OCR y XLSX con la regla ya aplicada. Cinco formatos irreconciliables, llegando por email a la bandeja del equipo administrativo.
Una persona cualificada del equipo fiscal dedicaba un fin de semana completo al mes a abrir cada documento, transcribir líneas en un Excel maestro con cuarenta y cuatro pestañas, buscar al médico, aplicar la regla correcta (porcentaje sobre baremo, fijo, o porcentaje sobre beneficio según acto × centro × mutua), calcular honorarios, generar un PDF individual por colaborador y enviarlo. En paralelo, la secretaría dedicaba media hora por cirugía a rellenar plantillas de autorización de mutua, coordinar proveedor de material, agendar el quirófano en Google Calendar y enviar recordatorios al paciente. Seiscientas cirugías al año.
Y lo peor: las cirugías que los centros olvidaban facturar a mutua quedaban colgadas 60, 90, 120 días sin que nadie las reclamara hasta que aparecía en extracto bancario que el cobro no había entrado.
El equipo perdía un fin de semana al mes liquidando. Encima cometíamos errores (un porcentaje mal aplicado, un médico mal asignado a un acto) que costaban dinero. Y cuando cerraba el mes, empezaban los impagos que nadie estaba reclamando. Íbamos apagando fuegos todo el rato.
Qué construimos.
Captura multicanal de liquidaciones
Una casilla dedicada liquidaciones@ recibe las fichas mensuales que envían los centros. Un workflow de n8n recoge el adjunto, calcula su SHA-256 para evitar duplicados, lo deposita en Supabase Storage cifrado con retención de 5 años (LOPD sanitaria) y registra trazabilidad de origen, timestamp y hash antes de procesar nada.
Extracción con LLM + Vision
Cada documento pasa por OCR si es escaneo, y después por un prompt de extracción estructurada contra GPT-4.1 o Gemini 2.5 Pro con tool use y JSON Schema estricto. Salen: centro emisor, periodo de facturación, y por cada acto → fecha, médico tal como aparece en la ficha, paciente (iniciales), mutua, descripción del acto, baremo, importe facturado y confianza. El mismo prompt funciona con tabla limpia, PDF escaneado o formato propio del hospital. Si la confianza cae por debajo del umbral, el flow pide nueva captura al centro citando el asunto original.
Matching de médico + aplicación de reglas
Antes de calcular nada, cada acto cruza tres etapas de matching: cache de alias verificados, trigrams en Postgres (pg_trgm) y fallback a LLM si ninguna de las dos resuelve. El médico resuelto se cruza contra la matriz de reglas (médico × centro × mutua × categoría de acto → porcentaje, fijo o porcentaje sobre beneficio). Los honorarios se calculan y persisten. Si hay ambigüedad, el flow no inventa: abre un ticket con la fila completa y el contexto para revisión humana.
Portal del médico colaborador + contabilización
Cada médico entra en su portal con MFA y ve sus actos del mes, el importe calculado, la regla aplicada y el PDF original del centro — todo aislado por Row-Level Security de Supabase. En paralelo, los importes cierran contra Holded vía API, con el archivo fuente adjunto al asiento. El titular recibe un informe mensual con resumen por médico, totales por centro y cualquier KO pendiente.
Reclamación T+30 a centros hospitalarios
El titular no factura directamente a mutuas — lo hacen los centros. Cada día a las 09:00, un cron recorre las cirugías con 30 días desde la fecha de intervención sin marcarse como cobradas y manda email al contacto de facturación del centro. Tres estados visibles en pantalla: en gracia, reclamada automáticamente, cobrada. Una sola reclamación por cirugía — sin spam.
Cómo lo implementamos.
Seguimos nuestras 5 fases estándar — ver proceso completo.
- Semana 1 · Descubrimiento + plan de ruta: sesión con titular, secretaría y equipo fiscal. Mapeamos los 5 formatos de fichas, inventariamos mutuas y centros activos, documentamos el Excel maestro de reglas y cerramos propuesta con fee fijo. Quick win: empezar por el centro que concentra el 40 % del volumen.
- Semanas 2-3 · Desarrollo: construcción en staging sobre VPS dedicado y Supabase EU-Frankfurt. Conexiones con Holded, Google Calendar (los 2 quirófanos propios), Gmail/IMAP, SMTP corporativo y OpenAI API.
- Semanas 4-5 · Desarrollo con datos reales: entrenamiento del parser contra 4 meses de fichas reales de los 10 centros. Calibración formato a formato. Ajustamos el prompt hasta que el ratio de errores cayera por debajo del proceso manual. Se matchean 44 médicos con sus alias frecuentes.
- Semana 6 · Portal médico + motor de reglas: UI de autoconsulta con RLS por colaborador. Carga del Excel maestro a la matriz editable. Validación matemática contra liquidaciones históricas.
- Semana 7 · Reclamación T+30 + calendario en vivo: cron diario al centro. Sincronización bidireccional Google Calendar con los dos quirófanos.
- Semana 8 · Entrega y corte: 5 días de sombra en paralelo al proceso manual, luego sustitución. Sistema corriendo.
- Semanas 9-11 · Estabilización (3 semanas supervisadas): reuniones semanales con el equipo para revisar casos borde, ajustar validaciones con fichas raras que aparecen sólo en uso real y afinar el umbral de confianza. Al cerrar: producción 100 % autónoma.
- Producción: retainer mensual recomendado los primeros 6 meses para incorporar mutuas nuevas, parsers de centros nuevos y evolución del motor de reglas.
Stack utilizado.
n8nOpenAI GPT-4.1Gemini 2.5 ProHolded APIGoogle Calendar APIGmail IMAP + SMTPSupabase (PostgreSQL + Auth + Storage + RLS)Next.js 14VercelTesseract OCRSentry