Projects

Live demo

Reconciliation. Three daily exports in, a dozen exceptions out.

Takes a dental practice's three daily exports, the schedule, the production ledger, and the clinical notes, and proves that every patient who was seen got both documented and billed. Staff review a dozen flagged exceptions instead of eyeballing three spreadsheets.

Deterministic engine · Revenue integrity 6 steps · synthetic data

Walk through it, six steps

Step 1 of 6

Upload three exports

End of day, staff upload the schedule, the production ledger, and the clinical notes for one date, plus an optional perio charting export. Two practice management systems are supported through separate adapters; a wrong file fails loudly, naming the missing column, instead of producing a silently wrong answer.

UploadSynthetic data
Scheduleok
  • appointments-0821.xlsx
  • 41 rows parsed
Production ledgerok
  • daily-journal-0821.xlsx
  • 118 rows parsed
Clinical notesok
  • progress-notes-0821.csv
  • notes reassembled across broken lines
Perio charting (optional)ok
  • perio-0821.xlsx
  • enables one extra rule
Step 1 of 6

Every name, number, transcript and document in this tour is synthetic. The mechanisms, thresholds and architecture are real. The production system and its data stay private.

The problem.

Two front office staff were each spending about three hours a day cross-checking three exports by hand: did everyone on the schedule get a note? Did every note get billed? Did the right provider bill it? Six person-hours daily, and misses meant either lost revenue or compliance risk.

  • Manual work replaced 6 h → 5 min daily cross-check becomes exception review
  • Auto-verified ~30 / 41 patients on a typical day need no review
  • Determinism byte-identical same inputs always produce the same report
  • Releases v1.16 240 tests, every rule traces to a staff review

How it fits together.

4 layers, left to right
  1. Pure engine

    • No network, no database, no clock: same inputs, byte-identical output
    • Per-source adapters map columns by name and fail loudly
    • Typed records carry their source row for the audit trail
  2. Rules

    • 7 primary buckets, 6 secondary checks
    • Provider, exam, code, arch and perio cross-checks
    • Every rule traces to a dated staff review
  3. App shell

    • FastAPI on Cloud Run, Google sign-in with allowlist
    • Firestore: users, saved reports, fixed-flag state
    • Self-service Gmail connect for sending reports
  4. Quality

    • 240 tests across 21 files, CI on synthetic fixtures only
    • Input SHA-256 hashes recorded per run
    • Golden assertion pins engine behavior

Where it landed.

Six person-hours of daily spreadsheet triage became a five-minute exception review. Because the engine is deterministic and every verdict cites its source rows, staff argue with the data, not the tool, and each disagreement became a versioned rule release: v1.7 added provider verification, v1.8 added the wrong-day guard after the 85-phantom-flag incident, and by v1.16 all eight known false-verified cases flag correctly.

Concepts

Deterministic coreRecord linkageRule enginesAuditabilityAdapter patternHuman feedback loops

Stack

PythonFastAPICloud RunFirestoreGoogle OAuthDockerGitHub Actions