Kaya Dental PMS

The system covers the front desk, clinical records, billing, prescriptions, lab management, follow-ups, and reporting. The interesting engineering is in the connections between them. A lab order has a cost. A treatment plan has a payment history. An appointment needs to respect the doctor's calendar and the branch where the work happens.

Start with the clinic's day

The dashboard brings together the appointment queue, collections, balances, follow-ups, and work that needs attention. It gives the team a way into the tasks they need to handle, rather than making every visit start with a search through separate modules.

Appointments also appear in calendar and chair-board views. A consultation outside the clinic reserves the doctor's time through the same appointment model, so it participates in the same conflict checks. The underlying rule matters more than which screen created the booking.

Keep the patient record connected

Clinical charting records findings against individual teeth. Treatment plans, prescriptions, payments, consents, files, and previous visits sit alongside the patient's history. The chart is useful on its own, but it becomes much more useful when the next step does not require re-entering the same context.

There are details here that deserve careful handling. A saved treatment plan must remain readable after a reference item is renamed or removed. Discounts need to retain their exact meaning. Concurrent changes to visits or billing must not quietly overwrite one another. The application uses server validation and database transactions for these rules.

Inside the application

The daily overview and clinical chart, captured with demo records.

View full size ↗

View full size ↗

Lab work belongs in the same flow

Lab management covers vendors, work specifications, shades, instructions, tracking, and delivery back to the patient. Orders retain the selected work and tooth-level details, rather than reducing everything to an unstructured note.

A priced lab order creates a linked expense. Changes to that expense and the order's amount stay synchronized, and the bill cannot be deleted independently of the work it represents. Tracking retains the history of trials and redos instead of treating every order as a straight line to completion.

The application also has a read-only connection to Tipuleemo's lab data. The clinic and the lab have different responsibilities; connecting their workflows does not mean giving either application unrestricted access to the other.

The rules behind the interface

The application uses Next.js and TypeScript with PostgreSQL and Prisma. Permissions are enforced on the server, alongside the controls visible in the interface. Appointments, billing, expenses, and lab operations use the working branch. PostgreSQL row-level security adds an organization boundary beneath the application's own queries.

Reporting has its own definitions to preserve. A collection belongs to the day the payment arrived; billed revenue belongs to the bill's date. Treating those as the same number would make a report easier to build and harder to trust. Clinic-local date boundaries and transaction-safe financial changes are part of the product, even when they are invisible in a screenshot.

Assistance inside the workflow

The project also includes experimental, optional assistants beside existing workflows: patient summaries, prescription instructions, reply drafts, clinic questions, and daily briefings. They use bounded source records and inherit the relevant permissions. A person reviews the result before using it.

That boundary is deliberate. Generating a draft does not send a message, change a clinical chart, or create a prescription. The regular workflow stays usable without the assistant.

For me, the value of this project is in making those connections explicit. The front desk, clinical work, lab, and accounts are parts of the same working day. The software needs to remember that.