The Dental Specialists

One patient identity across three branches

Registration takes under a minute and generates a unique patient ID on save, so the same person is recognised at any branch and is never entered twice. A database backed duplicate guard enforces it.

A quick register path back enters the old paper files, so the clinic could move off paper without stopping operations for a day. Every field is audited.

The tooth chart, made interactive

The clinical centerpiece is a real FDI tooth chart for adult and child teeth. Click a tooth and tag the problem, the surface, and a note, and the chart colour codes findings by category.

I had this built first, because it is the hardest piece and the one a dentist judges first. From these findings the doctor builds a treatment plan and proposes it for senior approval.

Where revenue stops leaking

Estimates build straight from the treatment plan and the total is always derived, never typed by hand. A discount stays pending, with no price change, until a senior or the founder approves it with a reason on record.

And you cannot approve a discount you requested yourself. That rule lives in the database, not in a hidden button, which is the difference between a real control and a polite suggestion.

Stock that protects safety and money

Every item is tracked per branch and per batch, with expiry dates, reorder levels, and low stock flags. The oldest safe batch goes out first.

Dispensing a prescription decrements the right batch automatically, so the ledger and the shelf never drift apart, and branches can move stock to each other instead of over ordering at every location.

The highest risk feature, made structurally safe

The most novel piece, and the one with the most ways to go wrong, is the case copilot. It is a retrieval augmented generation pipeline, and the highest risk feature: an assistant that invents clinical claims, or leaks a patient's name to a third party model, is worse than no AI at all.

So I designed it in four steps so a wrong or unsafe answer is structurally hard. It retrieves only from the clinic's own records behind a role gate, strips every patient's identity before anything reaches the model, and declines without calling the model when nothing is retrieved.

When it answers, the model is restricted to the cases provided and must cite each clinical claim. Citations are validated against the cases actually used, and the whole thing runs under hard rate and cost caps.

The screen is never the security boundary

Two diagrams carry most of the product thinking. The screen is never the security boundary: every write goes through a server side function that re-checks the caller's real role and stamps the actor.

Row level security guards every table, every mutation lands in an immutable audit log, and records, accounts and patient media stay pinned to the India region for DPDP residency.

I ran it the way I run every engagement: discovery, then a roadmap of six vertical slices, each through a plan, build, validate, review, commit loop, proven by 615 automated tests run together, not by spot checking screens.

The copilot's guardrails are the route itself

The copilot's safety is the path itself. It declines before calling the model when nothing is retrieved, so there are no tokens and no ungrounded claim. It strips identity before any case reaches the model.

It forces a citation on every clinical claim, validates each one against the cases actually used, and runs under hard rate and cost caps. A wrong or unsafe answer is structurally hard to produce, not just discouraged.

All six specs were built, tested, and handed to the client on plan: one system across three branches, safe delegation across five roles, provable compliance, and a foundation for AI with a reserved vector store for the next phase.