Healthcare · dental · insurance · Tri-Valley Dental · October 2026

Putback, an insurance checker for a dental front desk: coverage checked two days before every visit, and every unpaid claim given a status and a next step.

Insurance problems used to surface at the visit or months later on the aging report. Putback puts them in front of the desk two days ahead, and every claim that hasn't paid comes with a status and the next step, in plain words.

2 daysahead every patient on the schedule sent to the insurer before the visit, with the ones who need something, or need a call, listed first Before the visits runs over the practice's schedule export about two days ahead of the appointments.

16situations from what the practice's front desk told us, each answered with the exact words to ask the patient

Before the visits screen with sample patients: five marked Attention at the top, each with a plain reason and a Do line, above patients marked Ready — The schedule, checked two days ahead, with the patients who need something first. Sample patients.

At a glance

Client: Tri-Valley Dental Care, an independent dental practice in Pleasanton, California.
Who uses it: Built for the front desk and the owner dentist.
Shipped: October 2026. About a week from the first version to the one built around the practice's schedule and aging report.
Stack: Python
FastAPI
Stedi clearinghouse API
X12 270/271 eligibility
X12 276/277 claim status
pydantic
httpx
pytest
Compliance: No real patient data goes through it until business associate agreements are signed, and then only under those agreements. It never asks for a Social Security number, never sends a guessed detail to an insurer, and its logs carry only request IDs and insurer names.
Cost to run: About 30 cents a check at the clearinghouse's published rate for the first 250 a month.
My role: My co-founder built the first version. I rebuilt how it reads each insurer's answers, added the Before the visits check, and ran the QA passes.

What I built

The build

Before the visits. The schedule goes in about two days ahead, and every patient comes back Ready or Attention, with the problem first: coverage ended, the year's maximum used up, the plan assigned to another office. Each one says what to do.
Check coverage. One card with what the claim needs: active dates, what's left of the annual maximum, the deductible, member ID and group number, and coverage by category, with frequency limits where the insurer sends them.
Claims this week. Every claim on the aging report gets one status: denied, needs info, no record, call, paid or pending. Where the insurer sends a reason, it's in plain words, and every status comes with the next step, like the attachment the insurer is waiting on or a payment that still needs posting.
What each insurer needs. A grid built from the same rules the checks run, so the desk knows which insurers can find a patient by name and birthday and what to ask for the rest.

Coverage card for a sample Delta Dental patient: active, $1,340 left this year, subscriber ID, group number and what the plan pays by category — One card with everything the claim needs.

Claims this week: counts for denied, needs info, no record, call, paid and pending, above denied claims each with a reason and a next step — Every claim on the aging report gets a status and a next step.

A grid of six insurers showing which can be checked by name and birthday and what to ask for the others — What each insurer needs, so the desk asks once.

What changed

Before and after

Before

By hand

Checking coveragePortal by portal, by hand

A patient with a problemFound at the visit

An unpaid claimA line on the aging report

What each insurer needsLearned call by call

After

The system

Checking coverageThe whole schedule, two days ahead

A patient with a problemListed first, with what to ask

An unpaid claimA status and a next step

What each insurer needsOne grid, from the same rules

Where the numbers come from. Checks go through a healthcare clearinghouse at about 30 cents each at its published rate. Every screen on this page uses sample patients.

For engineers

How it's built

Architecture: A Python service with a one-page web front end. Coverage checks are X12 270/271 eligibility requests through Stedi; claim status is 276/277. Deterministic code reads every insurer's answer: plan-year against coverage dates, ranked maximum and deductible rows, split categories (a crown at 60% beside a repair at 90%), DeltaCare facility matching. The schedule and the aging report come in as the exports the desk already makes, so nothing has to connect into the practice software.
Where it runs: On the practice's own computer, answering only on that machine unless a password is set, with the clearinghouse as the one outside connection.
Tests and evals: 210 automated tests across 14 files, plus 12 recorded insurer answers from the clearinghouse's test mode. Three QA passes and a review against 15 test requests to sample insurers.
Cost and latency: About 30 cents a check at the clearinghouse's published rate for the first 250 a month.
Guardrails: It never guesses. A check that is missing a detail says what to ask the patient instead of sending a guess, and an incomplete search never tells the desk to resubmit. An insurer that does not answer claim status electronically, like MetLife, is marked Call rather than given an answer it never sent.
The tradeoff we chose: Why this way and not the other
No direct connection into Dentrix yet. The schedule export and aging report the desk already makes are enough to run on, and an approved integration costs thousands up front. A direct connection comes once enough practices on the same software are using it.