To the dentist it is an assistant you talk to. Underneath it is a complete practice CRM with patients, appointments, records, billing logic, permissions, knowledge base and rules.

What it does
A dentist treats a patient and dictates at the chair, on an iPad or an iPhone, hands free. A patient number and the spoken treatment are the whole input. Out of that the system produces three things.
A structured documentation record in the form a practice files it, 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 line by line for the staff to check.
And a treatment plan, 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: an AI 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.

MCP layer opens every app's functionality inside ChatGPT, Claude and other MCP capable AI applications: ask your AI about upcoming appointments or dictate the current treatment right inside your favorite AI app.
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. 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
Pilot is currently running in Munich within the Zahneins group.
Tech stack
- Laravel, Django, Vue, MCP
Recently touched
- 2026-10-27 Alpha content parity in the beta model — every rule, product, bundle, alias, companion, Komplex case and practice price that main's widget and monolith carry as static or hard-coded data lives in the beta's tables and packs and reaches the widget through the bundle Open
- 2026-10-27 Product prices — `product_prices` as the one home of every amount (`products.default_price_id`), system price formulas with {{placeholders}} and a parser, price status and validity, branch prices, the `price` rule action; admin portal dictionary browser + formula CRUD (monolith + admin + assistant + nexus, session group s2) Open
- 2026-10-27 Products and line items — one product library per organization (`products`), `line_items` as the only billing line, four library tables and two position tables folded and dropped Open
- 2026-10-27 Admin portal (doxtime-admin) — separate super-admin service on its own users: P0 read-only cockpit, P1 SYSTEM dictionary editor, P2 support tooling; never impersonation Open
- 2026-10-27 Products P2 — branch price lists, stock and warehouses, suppliers, catalog versions: separate tables next to `products`, nothing inside it Open
Other projects in this case study
Website
DoXtime is an AI assistant for German dental practices. We built its marketing site as a static Astro build from the client's design screenshots, German only and free of page JavaScript, and wrote…
Read case studyDepersonalization
Depersonalization module for the DoXtime app family (repo: dxt-depersonalize). Documents in (PDF, DOCX, images), clean text plus reversible span map out, so the AI assistant never sees patient data.…
Read case study