Skip to content
Tim Borja
Apps

D-Touch Health Platform

Clinic management SaaS for many independent clinics, with every authorization rule enforced in PostgreSQL

Timothy Maersk M. Borja

RLS policies
77
RLS policies
database checks
660+
database checks
Vitest tests
187
Vitest tests
Platforms
Web
Since
2024
Medical

Preview

Doctor's day and dental chart
Patient booking
Front-desk status board

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_net for Web Push. pg_cron sends 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.