Lo que costaba confiar en una orden que pasó por tres manos
- · Red de prestadores heterogénea, sin trazabilidad. La EPS atiende a sus afiliados a través de cientos de prestadores (IPS, profesionales, sedes), cada uno con su propio flujo. La orden se asigna, se atiende, pero la EPS no tiene cómo saber con certeza cuándo se hizo, quién la hizo, ni si se hizo.
- · Verificación de identidad del prestador ausente o vulnerable. Hoy, la ejecución de la orden se valida con planilla, firma escaneada, o un usuario/clave que se comparte. Cualquiera puede ejecutar una orden a nombre de otro. El fraude y las glosas asociados son millonarios al año.
- · Ciclo de liquidación fragmentado, sin auditoría. La orden atendida se digita otra vez en el sistema contable de la EPS, se concilia contra planillas, se cruza con la entidad que paga (fondo, ARL, empresa). El ciclo tarda semanas y cada paso es un Excel a mano. Cuando hay glosa, no hay forma de demostrar qué pasó en terreno.
Lo que cambió con la plataforma
- · Ciclo único de la orden, de punta a punta. App móvil para el prestador, backend FastAPI para la EPS, un solo estado de orden que se mueve de "asignada" → "atendida" → "verificada" → "liquidada" → "cobrada". Trazabilidad continua, sin re-digitación.
- · Verificación biométrica en el momento de la atención. El prestador se autentica con biometría (reconocimiento facial + liveness) antes de ejecutar la orden. La EPS recibe la orden con la identidad criptográficamente atada a quien la ejecutó, no a un usuario/clave compartido.
- · Liquidación y cobro listos para conciliar. La orden ejecutada se traduce automáticamente en un comprobante listo para el sistema contable de la EPS y para la entidad upstream (fondo, ARL, empresa). Sin Excel intermedio, sin glosa por "no se puede verificar la atención".
Una sola orden, una sola verdad, auditable de punta a punta
Lo difícil no fue construir la app ni el backend, sino diseñar el modelo de datos del ciclo de la orden para que la EPS pueda confiar en su propia información. El cliente y la regulación colombiana exigían que cada atención pudiera reconstruirse hacia atrás, con identidad criptográfica, sin re-digitación, y lista para conciliar con el upstream. Las tres decisiones críticas fueron:
- 1 Modelo de dominio del ciclo de la orden. Estados inmutables, transiciones auditadas, idempotencia por evento. Cualquier orden puede reconstruirse hacia atrás desde el comprobante de cobro hasta la asignación original, con timestamps, GPS y prestador identificado.
- 2 Verificación de identidad del prestador en el momento. Flujo de enrolamiento + autenticación biométrica que cumple los requisitos de la normativa colombiana. La biometría nunca sale del dispositivo del prestador sin cifrado, y el match se hace contra el padrón enrolado de la EPS.
- 3 Integración con liquidación sin doble digitación. La orden ejecutada se traduce en un comprobante estructurado que el sistema contable de la EPS puede consumir directamente. Webhooks idempotentes, retries exponenciales, y un endpoint de conciliación para cuando la entidad upstream cierra el ciclo.
┌──────────────────┐
│ App Flutter │ ◄── Prestador en terreno
│ iOS + Android │ Auth biométrica + orden
└────────┬─────────┘
│ Eventos firmados, idempotentes
▼
┌──────────────────┐
│ FastAPI + Python│ ◄── Estado único de la orden
│ + PostgreSQL │ auditoría, transiciones inmutables
└────────┬─────────┘
│ Comprobante al cierre del ciclo
▼
┌──────────────────┐
│ Liquidación + │ ◄── Sistema contable EPS
│ conciliación │ + upstream (fondo, ARL, empresa)
└──────────────────┘ Lo que nos llevamos como aprendizaje
- 01
La trazabilidad no es un módulo, es el modelo de datos
Un sistema donde la orden se digita tres veces (en el prestador, en la EPS, en el upstream) no es trazable. Lo que hace que la EPS pueda confiar en su propia información es que el estado de la orden viva una sola vez.
- 02
Biometría + regulación es un tema legal tanto como técnico
Reconocer la cara de alguien es una cosa. Hacerlo de manera que la firma tenga validez legal ante una eventual auditoría del Ministerio es otra. Esto se diseña desde el día uno, no se agrega al final.
- 03
El pago es la prueba
La liquidación y el cobro no son la última etapa del sistema — son la prueba de que la atención ocurrió. Si la EPS puede cobrar lo que ejecutó, es porque su trazabilidad funciona. Si no, hay un agujero.
"Necesitábamos dejar de recibir órdenes ejecutadas en planillas, fotos por WhatsApp y firmas que no podíamos verificar. Hoy la orden nace en la app, se ejecuta con identidad del prestador, y la liquidación se cierra sola. El día que la entidad reguladora nos pidió demostrar una atención, la respuesta salió en 30 segundos."
Testimonio parafraseado.
¿Tenés un proceso de orden médica que sigue dependiendo de planilla y Excel?
Hablemos de cómo cerrar el ciclo de la orden con verificación biométrica, liquidación automática, y cumplimiento normativo.