Doc-QHealthcare Appointment & Queue Platform
- Period
- Date not documented
- Project type
- Collaborative Group Project
- Role
- Contributing Developer (9-Person Team)
- Team
- 9-person group
A healthcare appointment platform that helps patients discover nearby clinics, book from a doctor's live schedule, and complete OTP-verified onboarding through an Express and Firebase stack.
- Collaborative build
- 9Team membersCollaborative build
- Hourly doctor availability
- 8Daily slotsHourly doctor availability
- Documented route surface
- ~14EndpointsDocumented route surface
Overview
Doc-Q connects patient registration, OTP verification, role-specific profile completion, clinic discovery, doctor availability, appointment booking, and patient management. Doctors expose eight hourly slots per day in Firestore, while patients can search by city and geolocation distance before selecting an available time.
Role & context
- Role
- Contributing Developer
- Team
- 9-person group
- Type
- Collaborative Group Project
- Period
- Date not documented
A nine-person university or bootcamp group project split between an Express/Firebase backend and HTML, CSS, JavaScript, and EJS interfaces. The available documentation confirms my participation but does not establish which routes or features I personally owned, so the case study describes the team's system without assigning unverified implementation claims to me.
Problem
Patients at private clinics can spend hours in physical queues and often lack a shared view of nearby doctors or current availability. The platform combines discovery and scheduling so a patient can find a clinic and reserve a time before travelling.
Approach & architecture
Express coordinates Firebase identity and data, email verification, distance lookup, role onboarding, and server-rendered appointment views.
Practices followed
Separated Firebase client authentication operations from privileged Admin SDK operations
Used distinct doctor and patient collections with role-aware onboarding
Created daily slot records lazily and updated selected slot fields atomically
Stored short-lived OTP state in the server session and supported code regeneration
Computed clinic distances concurrently for matched search results
Challenges & resolutions
Firebase client and Admin SDK responsibilities had different initialization and privilege requirements.
FixSeparated the SDK setup into dedicated modules so privileged operations never depend on client-auth state.
Outcomes
The 9-person team implemented the registration-to-booking lifecycle across patient and doctor views with 8 hourly slots per day
The source contains approximately 14 endpoints across authentication, scheduling, search, and patient management
Firestore models doctor profiles, daily slot maps, appointment summaries, and detailed patient records
Tech stack
Concepts & skills7
- Firebase client and Admin SDK boundaries
- Cloud Firestore data modeling
- OTP-based email verification
- Express session flows
- EJS server rendering
- Concurrent API fan-out
- Geolocation-based clinic search