Browser-based key-value storage. Used to sync patient-booked appointments to the clinic portal without a backend.
dentayos_appointments — pending queue
dentayos_confirmed — confirmed visits
Browser-scoped (per device)
Clears in incognito mode
→
Layer 2 — Logic (Current)
JavaScript (Inline)
All business logic, state management, and data rendering is handled in vanilla JavaScript embedded directly in each HTML file.
Staff account validation
Patient account creation
Appointment booking flow
Dynamic table rendering
⚠ No persistent database in current prototype — all data resets on page refresh (except localStorage)
Patient
Self-registers on Patient Portal
Creates username + password. Account stored in memory for the session. In the production system, this writes to the users table in PostgreSQL via Firebase Auth.
Patient
Books an appointment
Selects date, time, and concern. On submit, an appointment object is pushed to localStorage['dentayos_appointments'] with patient name, concern, date, time, and timestamp.
↓
System
localStorage sync
The appointment object is available immediately in the same browser session. When the clinic staff opens the Appointments section, the portal reads from the same localStorage key and renders the pending queue.
↓
Clinic Staff
Sees pending appointment queue
The Appointments section displays all pending patient-booked appointments in a table. Staff can Confirm or Decline each entry.
Clinic Staff
Confirms appointment
The appointment is removed from dentayos_appointments, saved to dentayos_confirmed, and added to the Upcoming list with a green Confirmed badge.
Clinic Staff
Sends reminder
Staff selects a patient and sends a reminder via the modal. In the prototype this shows a success toast. In production, this triggers a Twilio SMS or Resend email to the patient's contact.
↓
System
Notification delivered
Patient receives notification in their portal notification feed. In production, also delivered via SMS (Twilio) and email (Resend).
Frontend
React + Tailwind
Component-based UI. Patient, clinic, and owner portals as separate React apps or routes within a single SPA.
React Router for portal routing
Zustand for state management
Tailwind CSS for styling
→
API Layer
Node.js + Express
RESTful API handling all business logic — authentication, data operations, notification dispatch.
JWT authentication middleware
Role-based access control
Appointment booking endpoints
Notification trigger endpoints
→
Database
PostgreSQL
Relational database storing all persistent data — users, clinics, patients, appointments, records.
Clinic subscription billing — GCash, Maya, debit/credit card support
Planned
Hosting (prod)
Render / Railway
Node.js API server hosting with PostgreSQL add-on
Planned
Frontend (prod)
React + Vite
Component-based UI with proper routing, state management, and build pipeline
Planned
Security considerations for the current prototype and the planned production system.
🔐
Authentication
Current: hardcoded demo accounts in JS. Planned: Firebase Auth with email/password, session tokens, and 24-hour expiry.
👥
Role-based Access
Clinic staff are separated by role — dentist, receptionist, assistant, admin. Each role sees only their permitted sections.
🏥
Multi-tenancy Isolation
Each clinic gets a unique clinic_id. All patient data is scoped to that ID — clinic A cannot see clinic B's records.
🔒
Patient Data Privacy
Patients can only see their own records. The clinic portal enforces that staff can only access patients belonging to their registered clinic.
📋
Data Privacy Act (PH)
DentAyos is designed with the Philippine Data Privacy Act of 2012 (RA 10173) in mind. Patient data is stored with consent and never shared with third parties.
🔑
Password Policy
Minimum 8 characters enforced. Username cannot match password. In production, bcrypt hashing replaces plaintext storage.