Projects

Guided tour

Reconciliation. Three daily exports in, only the patients who disagree 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 only the patients who disagree 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, transcript and document in this tour is synthetic, and so are the numbers on the sample screens. The numbers under The problem and Where it landed are real. The production system and its data stay private.

The problem.

The insurance team spent about 70 hours a week 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? Misses meant lost revenue or a charge with no note.

  • Spec to live 8.75 hours first commit to the first live revision
  • Verified without review 30 of 41 patients on one June day, first engine version
  • Determinism byte-identical same inputs always produce the same report
  • False flags caught 85 a date check now stops a wrong day export

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

    • Input SHA-256 hashes recorded per run
    • Golden assertion pins engine behavior

Where it landed.

The insurance team spent about 70 hours a week on this cross check by hand. Now they open one page and review only the patients who disagree. 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