TeleHealth Connect is a near-production-ready Next.js telehealth infrastructure platform built for real-time doctor-patient coordination. Here's what I shipped, how it works, and what's left before production.
The problem I was solving:
Healthcare in Tier 2 and Tier 3 India — especially the Northeast — has a coordination gap, not just a resource gap. Doctors exist. Patients exist. What's missing is structured real-time infrastructure to route the right clinician to the right patient at the right time, especially in hyperlocal geographies.
Most telehealth products are built for metros. I wanted to build something proximity-aware, operationally structured, and deployable in lower-connectivity regions — a platform any healthcare provider or district health team could white-label and deploy.
What's inside the platform
Patient gateway
Symptom submission, consultation requests, multimedia upload support
Clinician dashboard
Patient queue management, consultation workflows, routing interface
Hyperlocal routing
Proximity-based doctor routing with geospatial case allocation
Workflow system
Structured consultation lifecycle with queue and patient workflow handling
Privacy-first arch
Local-first persistence, compartmentalized workflows, minimal central dependency
Responsive UI
Fully mobile-responsive across patient and clinician surfaces
Tech stack
Next.js
React
TypeScript
Tailwind CSS
Vercel
Firebase (ready)
The architecture is Firebase-ready — the persistence and auth layers are scaffolded but not yet connected to a production backend. This was intentional: the MVP is UI-complete and deployment-ready so any health org can wire in their own Firebase project with minimal configuration.
Geospatial routing — the interesting bit
The hyperlocal routing engine is what differentiates this from a generic telehealth template. Rather than global queuing, the system uses proximity-aware case allocation — incoming patient cases are routed dynamically to clinicians based on geographic proximity and current queue load. This matters significantly in district-level healthcare deployments where a "nearest available doctor" model is the operational norm.
The routing architecture is modular, so it can be extended with additional signals — specialisation matching, language preference, historical outcomes — without restructuring the core workflow engine.
