Work / ClinoDesk
ClinoDesk
In production with paying clinicsMulti-tenant practice management for dental clinics: patients, appointments, tooth-by-tooth charting, billing, inventory and lab work in one application, in Arabic and English, on phone, tablet, desktop and web. Built for the small independent clinic priced out of hospital-grade software.
1,768
Blocking Flutter tests
23
Feature modules
36
Screens
5
Platform targets
1,419
Localized keys, AR + EN
The problem
A small clinic runs on a doctor, a secretary and a paper diary. Appointments live in a notebook, balances in the doctor's head, X-rays on WhatsApp. Hospital-grade practice software is priced for hospitals. ClinoDesk gives each clinic its own isolated system that the front desk can actually run, with Arabic as a first-class language and RTL from the locale, not a translation layer bolted on.
What it does
Clinical record
Patient registry, medical flags, per-visit history, the interactive tooth chart, treatment records and clinical imaging.
Scheduling
Calendar booking, a clinic dashboard and four derived work lists: follow-ups, overdue, tasks.
Money
Per-procedure price list, payments against visits, patient balances, clinic costs, revenue and procedure-mix reporting.
Supply chain & lab
Inventory with reorder thresholds, multi-supplier sourcing, lab orders tracked sent → returned.
Practice admin
Four staff roles, clinic settings and timezone, subscription and licensing, platform-owner console.
Arabic + English
1,419 keys maintained in both languages, right-to-left from the locale, not a translation layer.
Engineering notes
A database per clinic
Each tenant is a physically separate PostgreSQL database, not a shared table with a tenant column. Tenant identity comes from verified JWT claims only, never from request input.
The tooth chart is ours
The tooth-by-tooth chart, the thing dentists judge dental software by, is built in-house, wired to treatments and visit history, not licensed from a component vendor.
Cloud-only, by decision
The offline build was deliberately retired so no clinical data rests on a device. Credentials live in the platform keychain; web sessions use HttpOnly cookies with zero JavaScript reach.
Four states, all rendered
Strict MVVM across 27 repositories and 14 view models; every screen models loading, success, empty and error explicitly, enforced by 1,768 tests that block every push.
Compliance & security
Built to HIPAA and GDPR requirements. Not certified, and we say so.
HIPAA compliance is a property of an organisation and its signed business associate agreements, and nobody certifies GDPR compliance at all. So instead of a badge, here is what is actually implemented, each control traceable to a file in the codebase, alongside what is only partly done and what is a disclosed gap rather than an omission. ClinoDesk is sold and operated for clinics outside the United States; we do not currently act as a HIPAA business associate and do not serve US covered entities.
As implemented in ClinoDesk 1.2.1, verified against the codebase on 22 August 2026: 12 implemented, 2 partial, 3 gaps, all three states on this page.
Implemented
- One physically isolated database per clinic
- Tenant identity from verified JWT claims only
- No clinical data at rest on devices
- Credentials in Keychain / Keystore; HttpOnly cookies on web
- 15-minute idle auto-logoff, app-wide
- argon2id password hashing + login rate limiting
- Role-based access enforced server-side, four roles
- Session refresh distinguishes revoked from offline
- Append-only audit log that never stores full PHI
- Audit records survive account deletion
- No patient data in application logs
- TLS + HSTS + hardened headers, verified live; locked CSP
Partial
- MFA: TOTP is built end to end and enforced for the platform-owner account, but clinic users have no enrollment entry point yet, so it protects nothing for a doctor or secretary today
- Retention schedule: the written schedule and a candidate query for it exist; the retention periods still need confirming against dental-records law in each destination jurisdiction
Disclosed gaps
- Erasure does not drop the tenant database: when a clinic closes, logins die but clinical rows stay on disk pending a manual ops procedure
- Erasure runs manually, not on a schedule: the script exists, nothing calls it automatically
- Backups sit outside the erasure path: backups are encrypted, but an erased patient can still persist in an older backup
Patient data-rights endpoints, export and erasure, ship as routes, not support tickets. Erasure has the limits listed above: it does not yet drop the tenant database, it runs manually rather than on a schedule, and it does not reach existing backups. These controls describe how this product was built; they are not a warranty or a contractual commitment. See our terms.
Stack
- Client
- Flutter · Riverpod · go_router · dio
- Backend
- Next.js 16 · TypeScript · Zod
- Data
- PostgreSQL · Drizzle ORM · one database per clinic
- Security
- argon2id · secure storage · locked CSP
Status: version 1.2.1, in production with paying clinics. Cloud-only by design.