D-Touch Health Platform
Clinic management SaaS for many independent clinics, with every authorization rule enforced in PostgreSQL
Timothy Maersk M. Borja
Preview
Thursday
16 October
6 visits · 1 waiting
- 9:00JDJuan Dela CruzCleaningDone
- 9:45ARAna ReyesFilling · #36Done
- 10:30MSMarco SantosCheck-upIn the chair
- 11:15LBLiza BautistaBraces adjustmentWaiting
- 1:00PGPaolo GarciaExtraction · #48Booked
- 2:00BMBea MendozaWhiteningBooked
Sample Dental Clinic
Main branch · Open today
Book a visit
October
Available times
Cleaning · 45 min
Wed 22 Oct, 11:15 AM · Dr. Reyes
Front desk
Thursday, 16 October
Sample data+ Walk-inConfirmed2
Paolo Garcia1:00
Extraction
Bea Mendoza2:00
Whitening
Arrived1
Liza Bautista11:15
Braces adjustment
5 min wait
In consultation1
Marco Santos10:30
Check-up
Completed2
Juan Dela Cruz9:00
Cleaning
Paid · GCash
Ana Reyes9:45
Filling · #36
Balance ₱1,500
Drawn screens use made-up sample data. The client's and clinics' real data never appears on this site.
Four React Native Web apps (patient, doctor, front desk, admin) on one Supabase Postgres backend, serving any number of clinics. There is no custom application server; tenant isolation, roles and privacy all live in the database. D-Touch Dental is the first clinic, running on test data ahead of launch.
What it is
Small clinics in the Philippines often run on paper logbooks, Messenger and a spreadsheet. This platform gives each clinic four apps, one for each person’s job, built for landscape tablets and desktops:
- Patient: book and reschedule, a four-step intake form a guardian can complete, visit history, and a private calendar feed.
- Doctor: day, week and month views, tooth charting (FDI or Universal), clinician-only notes and patient handover.
- Front desk: a drag-and-drop status board from confirmed to arrived, in consultation and completed, plus walk-ins and recall lists.
- Admin: staff invite codes with approval, billing with GCash, QR Ph, bank transfer or cash, an expense ledger, CSV import and export, and the audit log.
It started as one dental practice with three hard-coded clinic identities. It is now multi-tenant: clinics are data rows, the clinic type switches dental features on per vertical, and each clinic has its own public page.
The database is the backend
There is no custom application server and no role logic in client queries. The apps talk to PostgREST and Supabase Auth, and PostgreSQL enforces every rule: 77 Row Level Security policies, 100+ PL/pgSQL functions and 50+ triggers, checked by 660+ database tests.
- A role that leaked across tenants. Roles used to live on the global user profile, so one clinic’s admin could promote a person at another clinic. Roles now sit on each clinic membership, a trigger restricts branch-locked admins, and a guard keeps every clinic’s last full admin.
- Overlap rules that respect privacy. Scheduling clashes are checked per patient chart, not per person. A person-wide rule would let one clinic discover that the same patient has a booking at another.
- Notifications sent from the database. One SQL function writes the inbox row, checks mutes, and calls a Deno Edge Function through
pg_netfor Web Push.pg_cronsends reminders. - Integrity by construction. Time-range exclusion constraints stop double-booking, composite foreign keys keep each appointment inside its own clinic, and walk-ins run in one transaction, so a lost slot race leaves no orphan chart.
Privacy
The platform is pre-launch and runs on test data. The picture on this page is a drawn mock-up with made-up patients and visits; no real patient information appears on this site.
Sign-up records which version of the Privacy Policy and Terms each person was shown. Consent to process health information is collected separately, per clinic, as the National Privacy Commission recommends.