The chart, the plan and the invoice stopped being three different documents.

The problem

Before this system, the clinic ran on a paper chart, a spreadsheet and the front desk's memory. The chart held the clinical findings, the spreadsheet held the money, and the recall schedule lived in someone's head: three copies of the truth, and none of them current.

The cost was not one dramatic failure. It was minutes lost on every patient, every day: re-reading the paper chart, cross-checking the spreadsheet, re-asking questions the record should already answer. And it was the recalls that never happened, because nothing existed to trigger them.

What we built

• A per tooth and per surface odontogram covering all 32 permanent teeth plus primary dentition, with 13 clinical conditions
• Treatment plans that phase the work and carry payment terms
• Appointments with a week calendar and automated reminder lists
• Billing with invoices, partial payments and daily close
• Supplies inventory drawn down by procedure
• A public online booking page for patients
• Roles for owners and front desk staff
• Multi tenant from the ground up: a second clinic is rows in a database, not a second deployment

How it works

1. 1A finding is charted against a specific surface of a specific tooth.
2. 2The finding becomes a planned procedure on the treatment plan.
3. 3The plan becomes a quote with payment terms.
4. 4Completed procedures become invoice lines.
5. 5Consumables are drawn down by the procedure that used them.
6. 6The recall is scheduled from the treatment, not from memory.

What changed

One record, entered once. The chart is the history, and it feeds everything downstream: the plan, the quote, the invoice, the inventory and the recall.

Industry

Dental and medical

Stack

FastAPI, React, PostgreSQL

Notable

Odontogram with per surface findings, multi tenant