HealthLuma
Full clinic management with separate portals for doctors and patients.
Overview
Private clinics run on fragmented tools: scheduling in one system, prescriptions in another, billing in a third. HealthLuma consolidates the entire clinical workflow into one platform, with separate experiences purpose-built for how doctors and patients actually use it.
The focus is speed and clarity in real clinical use. Every screen reduces steps, so doctors and patients complete tasks quickly, not just look at a clean UI.
The platform covers appointment scheduling, prescriptions, patient records, subscriptions, and AI-assisted booking, structured for real backend wiring.
Goal
Doctors lose time to administrative overhead. The goal was to reduce that friction by building interfaces that surface the right information at the right moment, not buried behind multiple navigation layers.
- Design a clean, separate workflow for doctors and patients
- Build a dashboard architecture with reusable components
- Keep every interface minimal but fully functional
- Ensure each page reflects a real clinical usage scenario
- Structure the project so backend integration is straightforward
Outcome
Modular layout with clean separation between UI and data layers, wired for backend integration. Each portal handles its own concern without cross-contamination.
- Fully structured doctor and patient dashboards
- Appointment booking with availability logic
- Prescription and medical record management
- Subscription and billing support
- AI assistant interface for guided booking
- Responsive layout designed for real clinical usage
- Backend-ready architecture using Next.js and Supabase
Tech Stack
Next.js
TypeScript
Tailwind CSS
Supabase- PostgreSQL
Stripe
Technical Decisions
PostgreSQL over a document database
Appointments, prescriptions, patient records, and billing have complex joins: a prescription references a patient, a doctor, an appointment, and medication data simultaneously. PostgreSQL's relational structure made cross-entity analytics queries clean and avoided the denormalization debt a document store would have required.
Separate route groups for doctor and patient portals
Two user types with distinct layouts, nav structures, and permission boundaries. Merging them into one dashboard with conditional rendering would have created a tangled permission tree. Separate route groups kept auth middleware straightforward and each portal's code fully self-contained.
Supabase for auth and data layer
Row Level Security at the database level isolated patient records by default; a misconfigured query couldn't expose another patient's data. Combined with Supabase Auth's session handling, it reduced the auth surface area without requiring a custom implementation.
Stripe for subscription billing
Standard and Family Care Pro tiers required a full webhook lifecycle: payment_intent, subscription_updated, and invoice events. Building custom billing logic would have meant recreating Stripe's retry logic, failed payment handling, and proration support.
3
Auth roles
2
Portal route groups
6+
Dashboard modules
4
Stripe webhook events
