Problem statement

A healthcare provider's finance and capacity team spent a large part of each day doing something a machine should do: reading prescription documents, retyping their contents into the system, and then manually matching payments against claims.

  • Manual data entry from scanned and photographed prescriptions — slow, error-prone and tiring.
  • Disconnected payments. Payment confirmation arrived separately and had to be reconciled by hand.
  • Skilled people on low-value work. The team's real expertise — reviewing and approving claims — was getting the least time.

Business outcome

35%reduction in the finance & capacity team's manual processing effort
1connected flow from document upload to payment confirmation
↑team time refocused on claim review and approval

Current state

flowchart LR
  D[Prescription image / scan] --> M[Staff read & retype]
  M --> CR[Claim record]
  PG[Payment provider] -.->|separate confirmation| X[Manual reconciliation]
  CR --> X
  X --> AP[Review & approve]
Figure 1 · Current state — two manual hand-offs before any review happens

Future state architecture

We automated extraction and payment status, and kept humans firmly in the loop where confidence was low or the stakes were high.

flowchart LR
  U[Upload document] --> OCR[OCR service]
  OCR --> V{Confidence & validation rules}
  V -->|high| CR[Claim record auto-populated]
  V -->|low| HQ[Human review queue]
  HQ --> CR
  CR --> PAY[Payment gateway]
  PAY -->|webhook| REC[Auto reconciliation]
  REC --> AP[Claim review & approval]
Figure 2 · Future state — automate the predictable, route the uncertain

Payment confirmation sequence

sequenceDiagram
  participant SF as Salesforce
  participant PG as Payment gateway
  participant Q as Async processor
  SF->>PG: Create payment request (idempotency key)
  PG-->>SF: Payment reference
  PG->>SF: Webhook: payment status
  SF->>Q: Enqueue status update
  Q->>SF: Match to claim · update status
  Note over SF,Q: Retries are safe — same key, same result
Figure 3 · Sequence — idempotent, asynchronous reconciliation

Key architecture decisions

  • Confidence thresholds, not blind automation. Low-confidence fields go to a human. Trust was earned field by field.
  • Idempotency keys on every payment call. Networks fail; double-charging a patient is not an acceptable failure mode.
  • Webhooks over polling. Status arrives when it changes, processed asynchronously to stay well within platform limits.
  • Original documents retained and linked. Every auto-populated value can be traced back to its source for audit.

Learnings summary

Do
  • Measure OCR accuracy per field, not per document.
  • Design the human-review screen as carefully as the automation.
  • Make reconciliation boring: idempotent, async, observable.
Don't
  • Promise 100% automation in a regulated process.
  • Poll a payment provider when it offers events.
  • Hide the source document from the reviewer.
The goal was never to remove people from the process. It was to give them back the part of the job that needs them.
OCRIntegrationHealthcarePayments
Pranav Sanvatsarkar

Pranav Sanvatsarkar is a Solution Architect with 14+ years across telecom, healthcare, public sector and non-profit, focused on AI, agentic automation and Salesforce architecture. Say Hello!