DentScribe

Access is derived in one guard from role, tenant and subscription state together, rather than checked where each screen needs it. Scattered checks are easier to write and are how a trial-expired account ends up reading another practice's data through a route nobody re-checked. One guard means every new surface inherits the rule instead of re-implementing it.

The review surface has no silent-accept path. A machine-drafted clinical note is signed by a clinician who is accountable for it, so the interface is built to make the draft easy to disagree with — sections separated, edits where correction is expected — rather than optimised for the fastest possible approval.

On the API, ownership is a condition inside the query rather than a check after it. Loading a row by id and then comparing its owner reads more naturally, and it is how one forgotten branch hands a practice someone else's records. Scoping the where clause to the signed-in user means the unauthorised row is never loaded at all, and "not found" and "not yours" become indistinguishable from outside — which, for patient data, is what they should be.

The product listens to a dental appointment, drafts the clinical note the dentist would otherwise have written up afterwards, and files it back into the software the practice already runs on. The note is the visible part; getting it back into their existing system is the part that makes it worth paying for.

I worked on the portal — where a generated note is reviewed and signed — plus the administrative applications around it, and on supporting REST endpoints in the API behind them. The portal is the window onto the whole pipeline, so building against it meant knowing where every field came from.