What trusting an order that passed through three hands actually cost
- · Heterogeneous provider network, no traceability. The health insurer serves its members through hundreds of providers (clinics, independent professionals, locations), each with their own workflow. The order is assigned, then attended — but the insurer has no reliable way to know when it was done, who did it, or whether it was done at all.
- · Provider identity verification is absent or weak. Today, order execution is validated with paper forms, scanned signatures, or a shared username/password. Anyone can execute an order in someone else's name. The associated fraud and claim denials run into the millions per year.
- · Fragmented settlement cycle, no audit trail. The attended order is re-entered into the insurer's accounting system, reconciled against spreadsheets, and matched with the upstream payer (fund, workers' comp, employer). The cycle takes weeks and each step is a hand-rolled spreadsheet. When a claim is denied, there is no way to prove what happened in the field.
What the platform changed
- · Single order cycle, end to end. Mobile app for the provider, FastAPI backend for the insurer, one order state moving from "assigned" → "attended" → "verified" → "settled" → "collected". Continuous traceability, no re-entry.
- · Biometric verification at the point of care. The provider authenticates with biometrics (facial recognition + liveness) before executing the order. The insurer receives the order with the identity cryptographically bound to who actually executed it, not a shared login.
- · Settlement and collection ready to reconcile. The executed order is automatically translated into a voucher ready for the insurer's accounting system and for the upstream payer (fund, workers' comp, employer). No spreadsheet in the middle, no denial for "unable to verify attendance".
One order, one source of truth, auditable end to end
The hard part was not building the app or the backend — it was designing the data model for the order lifecycle so the insurer could trust its own information. The client and Colombian regulation required every episode of care to be reconstructible backwards, with cryptographic identity, no re-entry, and ready to reconcile with the upstream payer. The three critical decisions were:
- 1 Domain model for the order lifecycle. Immutable states, audited transitions, idempotency by event. Any order can be reconstructed backwards from the collection voucher to the original assignment, with timestamps, GPS, and the verified provider.
- 2 Provider identity verification at the point of care. Enrollment + biometric authentication flow that meets Colombian regulatory requirements. The biometric data never leaves the provider's device unencrypted, and the match is done against the insurer's enrolled provider roster.
- 3 Settlement integration without double entry. The executed order is translated into a structured voucher the insurer's accounting system can consume directly. Idempotent webhooks, exponential retries, and a reconciliation endpoint for when the upstream payer closes the cycle.
┌──────────────────┐
│ Flutter app │ ◄── Provider in the field
│ iOS + Android │ Biometric auth + order
└────────┬─────────┘
│ Signed, idempotent events
▼
┌──────────────────┐
│ FastAPI + Python│ ◄── Single order state
│ + PostgreSQL │ audit, immutable transitions
└────────┬─────────┘
│ Voucher on cycle close
▼
┌──────────────────┐
│ Settlement + │ ◄── Insurer accounting system
│ reconciliation │ + upstream (fund, workers' comp, employer)
└──────────────────┘ What the team took away from the project
- 01
Traceability is not a module — it is the data model
A system where the order is entered three times (by the provider, by the insurer, by the upstream payer) is not traceable. What lets the insurer trust its own information is that the order state lives in exactly one place.
- 02
Biometrics + regulation is as much a legal problem as a technical one
Recognizing someone's face is one thing. Doing it so the signature is legally valid in an eventual Ministry audit is another. This is designed in from day one, not bolted on at the end.
- 03
Payment is the proof
Settlement and collection are not the last step of the system — they are the proof that care actually occurred. If the insurer can collect for what it executed, its traceability works. If it cannot, there is a gap.
"We needed to stop receiving executed orders on paper forms, photos over WhatsApp, and signatures we could not verify. Today, the order is born in the app, executed with the provider's verified identity, and settled automatically. The day the regulator asked us to prove a specific episode of care, we had the answer in under thirty seconds."
Paraphrased testimonial.
Still running medical orders on paper forms and spreadsheets?
20 minutes on a call about your operation. The team walks through scope, architecture, and how to close the order cycle with biometric verification, automated settlement, and regulatory compliance. No commitment.