Coordinator portal for the walk-in queue
Front-desk surface for intake (walk-in or scheduled), queue assignment, and shift management. Live queue view shows who's waiting, who's in consultation, who's at the pharmacy, who's waiting on a lab result.
Case study · 2026 · Healthtech · Multi-portal
One patient journey, four portals, no shared spreadsheet
An outpatient management platform for an independent clinic in Bangalore. The patient is the unit of work; coordinator, doctor, pharmacist, and lab each see the same patient from a different operational vantage point. A nine-week foundation build that replaces a register, a WhatsApp group, and three Excel files with a single, scoped, audit-clean system.
- ClientIndependent clinic in Bangalore
- IndustryHealthtech · Multi-portal OPD
- Year2026
- Engagement9-week foundation build · phased rollout
01 — At a glance
- 4-portal
- Role coverageCoordinator, doctor, pharmacist, lab — each scoped, all connected to the same patient.
- 1-page
- Doctor workbenchSingle-page consultation with collapsible vitals, notes, prescription panels.
- 15s
- Queue poll cadenceRealtime-feeling without a websocket layer the clinic doesn't need to operate.
Summary
Small clinics run on muscle memory and paper. A coordinator at the front desk knows which patients are walk-in versus scheduled, which doctor is free, and which medicine the pharmacist last said they were out of — but only because she's been there for six years. The moment she's on leave the system falls apart. We built an outpatient management platform that codifies the operation: a coordinator portal that handles intake and queue, a doctor workbench that fits a consultation on a single page, a pharmacist portal that handles dispense and inventory, and a lab portal that handles sample requests. One patient record, four operational vantage points, no shared spreadsheet.
Procurement was held together with Excel and goodwill.
Small private OPD clinics in this market — one to two doctors, six patients per hour at peak, walk-in heavy, flat per-consult billing — have a small but real digital problem. The unit economics don't support an enterprise EMR. The clinical complexity doesn't fit a generic appointment-booking tool. And the practical reality is that the coordinator at the front desk is doing seven jobs simultaneously, holding the state of the entire clinic in her head, and the moment she steps away the clinic's productivity halves.
The clinic we worked with had tried two paid EMRs and one free one. Each was designed for a hospital workflow — patient admission, bed assignment, ICU notes — and treated walk-in OPD as an afterthought. The doctor used the EMR for ten percent of what was happening and a paper register for the rest. The pharmacist used a spreadsheet. The lab used WhatsApp.
“The coordinator was holding the state of the entire clinic in her head. The moment she stepped away the clinic's productivity halved.”
The brief was specific and practical. Build a platform that fits the way the clinic *actually* runs: walk-ins are the default, scheduled patients are the exception. The coordinator manages intake and the queue. The doctor does consultations in a single visual surface — not a wizard, not a multi-page form. The pharmacist handles dispense and tracks inventory. The lab handles sample collection and result entry. And every action — every consultation, every dispense, every sample — is tied to the same patient record, so the picture is coherent without the coordinator having to glue it together by hand.
Nine weeks. One foundation build. Production-ready scope: intake, queue, consultation, prescription, dispense, lab order, lab result, billing, basic admin.
The coordinator portal is the design centerpiece. The clinic actually runs through this surface.
Why they chose Synara
Three things weighed in our favor. First, we'd already shipped multi-portal architectures with strong role boundaries — the platform shape was a known problem, not a research project. Second, the clinic operates in a market where the design quality of the *coordinator's* surface matters as much as the doctor's; we treat front-of-house design with the same seriousness as the consultation interface. Third, we were explicit about scope. Nine weeks, one foundation build, scoped to the operational reality. No promises of a research-grade EMR for a clinic that runs at six patients an hour.
We were also clear that the platform would not be a consumer-style EMR. The doctor wanted a single-page workbench, not a guided wizard. That's a design call we make easily because we know how to ship dense operational interfaces — and we don't reach for a multi-step form when a collapsible panel is the correct primitive.
A three-portal procurement platform — buyer, supplier, admin.
Single-page doctor workbench
The consultation surface is one page. Vitals collapse upward, notes expand downward, prescription panel docks to the right. The doctor never tabs through a wizard. Every panel saves on blur — no submit-and-pray pattern.
Pharmacist portal with inventory tracking
Pharmacy view shows pending prescriptions, dispenses against current stock, and surfaces low-inventory alerts. Each dispense logs lot, expiry, and quantity. The pharmacist never has to second-guess what's available.
Lab portal for sample-to-result tracking
Lab view handles sample request, collection confirmation, and result entry. Results return into the same patient record the doctor opens — no copy-paste from a WhatsApp screenshot.
Flat billing the way clinics actually charge
Per-consult flat fee with optional add-ons for dispensed medication and lab work. Billing surface is on the coordinator portal where payment actually happens — not buried in a separate finance app.
Polling queues, not websockets
Queue views poll every fifteen seconds. At six patients an hour, that's perfectly responsive. We didn't reach for a realtime layer the clinic would have had to operate — the simplicity is the feature.
Single-page consultation. Vitals collapse up, prescription docks right, no wizard, no submit-and-pray.
In plain English, why each choice.
- Frontend
- Next.js 16 + React 19 with the App Router. Server components where the data can be server-side, client islands where the interactivity is genuinely interactive. Tailwind + shadcn/ui for the design system. The four portal surfaces share a primitive layer and diverge at the screen level.
- Multi-portal architecture
- Coordinator, doctor, pharmacist, lab, admin — each a route scope with its own dashboard. Authentication routes by role to the correct portal on login; cross-portal navigation requires the right role. The patient record is the unifying data primitive across portals.
- Backend
- Turborepo monorepo with a typed API. Supabase for auth and Postgres. The data model is patient-centric: every consultation, prescription, dispense, and lab result is an event on the patient timeline. The timeline is queryable by portal-scoped views.
- Realtime posture
- Queue updates poll on a fifteen-second interval. We considered websockets and decided against them — at the clinic's volume, polling is responsive enough, vastly simpler to operate, and survives the inevitable laptop-loses-wifi moment without a reconnection saga.
- Doctor workbench composition
- Single-page consultation surface composed of collapsible panels (vitals, history, notes, prescription, follow-up). Each panel autosaves on blur. The whole surface is keyboard-navigable so the doctor doesn't have to lift hands from the keyboard mid-consultation.
- Component discipline
- 150-line component cap enforced as a soft rule. Components that grow beyond that get refactored into smaller composable pieces. The discipline keeps the codebase legible to the next engineer.
What changed after launch.
- Coordinator-first
- Operational designFront desk gets the most-care surface — because that's where the clinic actually runs.
- 1-page
- Consultation surfaceDoctor never tabs through a wizard.
- Audit-clean
- Patient timelineEvery clinical event is an entry on the same patient record.
- 9-week
- Foundation phaseProduction-ready scope shipped on the agreed timeline.
MethodologyArchitectural outcomes reflect the deployed codebase and shipped product surface. Operational impact is observed in the clinic's daily use; metrics will be reported as the platform accumulates operational data.
I can take a day off. That sentence wasn't true at this clinic for six years. Now it is. Everything I used to hold in my head is on the system.
06 — What’s next
An offline-first patient app for follow-ups and prescription refills. WhatsApp integration for appointment reminders (the channel the clinic's patients actually use). And a small analytics surface for the doctor — patient-mix shift, most-prescribed medications, lab turnaround time.
Stack
- Next.js 16
- React 19
- Tailwind
- shadcn/ui
- Turborepo
- Supabase
- Postgres
- TypeScript
Running a small clinic on paper and goodwill?
Enterprise EMRs are not for you. A scoped multi-portal platform — coordinator, doctor, pharmacist, lab — that fits the way your clinic actually runs is. We can scope and ship a foundation in 9–12 weeks.