DoXtime · App

The application behind DoXtime. To the dentist it is an assistant you talk to. Underneath it is a complete practice CRM with patients, appointments, records, billing and permissions. It is the client's product and we are the development team.

What it does

A dentist treats a patient and dictates at the chair, on an iPad, hands free, without taking a glove off. A patient number and the spoken treatment are the whole input. Out of that the system produces three things.

A structured record in the form a practice actually files, with fixed sections, no prose, editable before it is signed off. Dictated findings are quoted rather than reworded.

A billing proposal across the German catalogues, statutory and private fees, analogue positions, materials and laboratory work, with the multiplier and its written justification, checked against the billing rules and shown position by position so that the practice can see why each line is there.

And a plan for what is still outstanding, separated from what was billed today and carried forward to the next appointment.

Around that sits the part that makes it usable in a real practice: a chat assistant that knows the current screen, patient and appointment; multiple practices and multiple dentists with permissions down to the individual row; and a per-practice store of house rules, abbreviations and treatment bundles, so that the system bills the way that practice bills rather than the way a textbook does.

The two invariants

Everything else is negotiable. These two are not.

The language model never sees real patient data. The application that holds patient records makes no model calls at all. The AI path runs through separate services, identity is stripped before anything leaves, every removal is logged, and the deletion path reaches across all of them. The practice still sees who the appointment is with. The separation is something a data protection officer can be shown, not something we assert.

No billing code is invented. Every position is grounded on a real catalogue row. The model proposes candidates and the system verifies the composed bill against the catalogue, rather than letting a model produce codes from memory. This is the whole difference between a demo and a bill that survives review.

Stage

A prototype. A pilot is running in Munich within the Zahneins group.

Tech stack

• Laravel: The main application.
• Django: The AI service.
• MCP: The practice's own Claude or ChatGPT reaching the same data.

Internal project index: see INTERNAL.md in this folder (not published).