Dental practice management platform
A multi-tenant workspace for dental teams, bringing patient records, clinical histories, interactive tooth charts, appointments, billing, and reminders together.
Overview
I am building a practice-management application for dental clinics, designed around the daily work of owners, dentists, and receptionists. It brings patient administration, clinical notes, interactive tooth charts, scheduling, billing, insurance workflows, and appointment reminders into a shared workspace. Operational and clinical capabilities are separated by role.
Technologies
Next.js, TypeScript, Tailwind CSS, Fastify, PostgreSQL, Prisma, Redis, BullMQ, and Cloudflare R2.
Architecture
A TypeScript monorepo combines a Next.js interface with a modular Fastify REST API and a shared Prisma schema. API routes validate inputs and pass the authenticated tenant and role into domain services. Services group patient, clinical, appointment, billing, notification, and subscription workflows.
System design
PostgreSQL holds operational records, while Redis and BullMQ support queued appointment notifications. The worker checks the latest appointment state before sending, so cancelled appointments can cancel pending communications. File storage supports local development and Cloudflare R2 through temporary signed upload and download URLs.
Payment-provider integration and webhooks handle subscriptions. Clinical record edits use transactions and version checks to preserve history and detect conflicting updates.
Database design
Tenant identifiers scope operational records. The relational model links clinics, staff, patients, appointments, clinical notes, files, billing records, and notification schedules. Dental charts model teeth and tooth surfaces separately, with change history for clinical traceability.
Clinical notes and patient clinical information have revision records and version numbers. Composite indexes support tenant-scoped patient, schedule, and history queries. Separate tables hold consent records, sensitive-data access logs, pseudonymous patient references, and privacy requests. Files remain outside PostgreSQL; their metadata and storage references live in the database.
Security
Controls include role checks, tenant-scoped service queries, password hashing, hashed refresh tokens, and protected session cookies. Sensitive patient and clinical fields use application-level AES-256-GCM encryption with versioned keys. Tenant-scoped keyed lookup hashes support exact matching without storing searchable identifiers in plaintext.
Clinical reads can generate sensitive-access logs, and logging utilities redact selected personal information. Receptionist access is restricted at clinical service boundaries. File downloads use expiring signatures after application authorization.
Development status
In development. Application modules and automated test suites are implemented. Production readiness still requires infrastructure and recovery validation, final privacy configuration, and release checks. Tenant isolation currently relies on application queries; database row-level security remains a future evaluation.