We Built a Patient-Intake & Triage App for a 6-Clinic Group — No-Shows Down 34%

A multi-specialty clinic group in Pune ran six sites across 14 specialties on paper intake forms and a phone-only appointment desk. Front-desk staff re-keyed every form into the EHR by hand — about 11 minutes per patient, and 7% of those re-keys had a typo in a phone number or date of birth. We built a digital intake-and-triage app that patients fill on their own phone before arrival, routes them to the right specialty queue, and pushes a clean record into the existing EHR. Over the first 90 days, no-shows dropped 34% and average front-desk time per patient fell from 11 minutes to under 2. This is how we built it, including the triage logic and the consent design that kept it DPDP-defensible. ## The answer in 60 words We shipped a mobile-first web app (no app-store install) where patients complete intake and a 7-question symptom triage before arrival. A rules engine routes each patient to the correct specialty queue and flags red-flag symptoms for a nurse. A FHIR-style adapter writes a clean record into the clinic's existing EHR. Build cost: ₹9.8 lakh over 9 weeks. No-shows fell 34% in the first quarter. ## Why a clinic group asks for this now Front-desk re-keying is the hidden tax in Indian outpatient care. Every paper form gets typed into the EHR a second time, which doubles the data-entry labour and adds a 7% typo rate on critical fields. The 2023 Digital Personal Data Protection Act also raised the stakes: health data is sensitive personal data, and a paper form left on a counter is a consent and security gap a regulator can point at. This clinic group's trigger was concrete — a missed-appointment audit showed 22% of booked slots went empty, and a single doctor's no-show cost was about ₹1,400 in idle clinical time per slot. The CFO wanted that number cut before the next financial year. ## The client (specific details) - Sector: Multi-specialty outpatient clinic group (cardiology, ortho, derm, paediatrics, ENT, and 9 more) - Location: Pune, Maharashtra (6 sites across the city) - Size: ~38 doctors, ~140 staff, roughly 1,100 outpatient visits per day across all sites - Stack on day 0: A desktop EHR (vendor-locked, with a REST export endpoint), a phone-only appointment desk, paper intake forms - The trigger: A no-show audit showing 22% empty slots and an 11-minute manual re-key per patient - The constraint: No rip-and-replace of the EHR. The new app had to feed the existing system, not replace it. ## How the system fits together ## The triage logic (deterministic, not a chatbot) We get asked this in the first call every time: "Can the triage be AI?" For symptom routing into a clinical queue, our answer is no — at least not as the decision-maker. A multi-armed model that occasionally mis-routes a chest-pain patient to a dermatology queue is a clinical-safety problem, not a UX bug. So the routing layer is a deterministic rules engine. Each specialty has a short branching questionnaire; answers map to an urgency band and a destination queue. The bands are simple: | Band | Trigger example | Routing action | |---|---|---| | Red (immediate) | Chest pain, breathlessness, suspected stroke signs | Page on-site nurse + flag for walk-in escalation; do not let the patient sit in a normal queue | | Amber (priority) | Fever > 3 days, post-op concern, infant under 3 months | Front of the relevant specialty queue, nurse pre-review | | Green (routine) | Follow-up, prescription refill, routine check | Standard slot, no escalation | The one place we use a model is light-touch: a small text-classification step that reads the free-text "reason for visit" box and suggests a specialty when the patient booked under "General". It only suggests — a human confirms. We benchmarked it on 2,400 historical reason-for-visit strings and it agreed with the clinic's own coding 91% of the time. The 9% gap is exactly why a human stays in the loop. This mirrors the human-in-the-loop pattern our AI & automation team uses on every clinical or financial routing project. ## The 9-week build, step by step ## What you'll need to build this yourself ## Common mistakes (we made two of these) Symptom: "Patients abandon intake halfway." Cause: the form asked for insurance details up front, before the patient was invested. Fix: move optional fields to the end, show a progress bar, and let patients submit a partial form that the desk completes. Completion jumped from 71% to 96%. Symptom: "Duplicate patients piling up in the EHR." Cause: our first adapter created a new patient on every submit. Fix: match on phone + date of birth, and use upsert semantics with an idempotency key. We caught this in week 7 testing, not in production — which is the whole point of replaying real records against staging. Symptom: "The triage routes everyone to amber." Cause: rules written too cautiously, so almost every answer escalated. Fix: tune thresholds with the clinicians using real historical cases. Over-escalation looks safe but clogs the priority queue and trains staff to ignore it. Symptom: "Front desk distrusts the digital record." Cause: no visible audit trail, so staff couldn't see where a value came from. Fix: show the source of every field (patient-entered vs desk-edited) and keep paper as a fallback during the pilot. Symptom: "Consent is a single checkbox nobody reads." Cause: a generic terms blob. Fix: a short, specific purpose statement in the patient's language, separate consent for any data shared with a lab, and a record of consent version with a timestamp. ## The before-and-after, with one number that surprised us The headline numbers — 34% fewer no-shows, 11 minutes to 2 at the desk — were the goals. The number that surprised the clinic was different. Because triage happened before arrival, doctors saw a structured symptom summary on screen as the patient walked in. Average consult time dropped by about 90 seconds per patient, not because doctors rushed, but because they stopped spending the first two minutes asking what the front desk had already collected on paper and never passed along. Across ~1,100 daily visits, that is real clinical capacity recovered. We had built a similar before/during/after pattern for a diagnostics chain — see our patient-booking portal for a 12-clinic diagnostics chain, where the no-show rate halved. The intake-and-triage layer here is the next step up from booking alone. For teams weighing build-vs-buy on the EHR-adjacent layer, our web application development and CRM development practices both feed this kind of project, and the financial-grade audit-log work draws on what we built for Radiant Finance. ## When not to build this Skip a custom intake-and-triage app if (a) you run a single clinic with under 40 patients a day — a well-configured booking tool plus a printed form is cheaper and good enough; (b) your EHR has no write API and the vendor won't add one, in which case fix the EHR contract first; or (c) you can't get clinician time to own the triage rules. The rules are the safety-critical core. If no doctor will sign off on the red-flag list, you should not be shipping automated routing into a clinical queue. A booking-only portal is the safer first step. As Vivek, our co-founder, frames it on the first call: "We're not digitising the clinic. We're removing the second time someone types the same thing." That framing keeps scope honest. ## FAQ ### How long does a patient-intake and triage app take to build? For a multi-site group with an EHR that has a write API, plan 8–10 weeks from discovery to the first live clinic. The triage rules and the EHR adapter take the most time. A single-clinic booking-only version can ship in 3–4 weeks. ### Should the triage use AI or fixed rules? Use deterministic rules for clinical routing. A mis-routed red-flag symptom is a safety problem, not a UX bug. You can use a light text classifier to suggest a specialty from a free-text reason, but a human should confirm it. We keep a clinician in the loop on every routing decision. ### Is a digital intake app DPDP-compliant by default? No. Health data is sensitive personal data under India's DPDP Act. You need explicit, purpose-specific consent, a data-flow map, an audit log of reads and writes, and separate consent for any data shared with a lab or third party. Build the consent design before go-live, not after. ### How much does it cost in India? This six-site build came to ₹9.8 lakh over nine weeks, including the EHR adapter and reminder system. A single-clinic booking-and-intake app typically runs ₹3–5 lakh. The EHR integration is the swing factor — a clean API keeps it predictable; no API can triple the estimate. ### Will it really cut no-shows? Intake alone won't. The 34% drop here came from intake plus a three-touch SMS reminder cadence plus a one-tap reschedule that returned freed slots to the pool instantly. Without the reminders, expect a 5–8% improvement at most. ### Can it work without replacing our existing EHR? Yes — that was the point here. The app sits in front of the EHR and writes to it through its API. We did not replace the EHR. If your EHR can accept a Patient and Encounter record over REST or FHIR, the adapter pattern works. ### What happens if a patient doesn't fill intake before arriving? The front desk opens the same form on a tablet and completes it with the patient, or falls back to the desk workflow. The app is the default path, not the only path. During the pilot we kept paper as a fallback for two weeks at each site.