Rolling out AI into 20+ hospitals, clinics and health camps.

Every OPD is different

A large hospital in Mumbai, a municipal health drive, a police health camp, a single-doctor clinic in a smaller city. On paper they all run an outpatient department. In practice each one has its own queue, its own paper trail, its own idea of who does what, and its own reasons to resist a new tool.

The product does not adopt itself. Someone has to stand in the OPD, watch how work actually flows, and figure out where an AI that listens to consultations fits without breaking anything. For our first rollouts, that someone was me.

What I did on site

The rollout ladder

From the first visit to a team that rolls out without me.

1. 01 · Observe Map the OPD workflow Including how people behave in that setting.
2. 02 · Plan Plan digitization Which touchpoints go digital, and where the product fits.
3. 03 · Fit Customize templates Prescriptions and case sheets, per site.
4. 04 · Launch Train doctors directly Schedule, go-live criteria, hardware and room setup.
5. 05 · Run Daily feedback and bug triage With each site, plus data migration decisions.
6. 06 · Scale Train sales and support Who ran the later deployments.

• Visited every site and mapped its OPD workflow, then customized the product to fit.
• Planned digitization: for sites still on paper, mapped which touchpoints had to go digital and how the product fits.
• Decided the rollout schedule and who tests first, and helped define go-live criteria.
• Chose hardware and room setup for the first sites, until our implementation SOPs took over.
• Decided what data to migrate and how. Engineers executed it.

Pilot terms were set by the CEO, our chief growth officer and the sales head. My job was making the product work once the door was open.

Introducing service blueprinting

The company did not use service design when I joined. I introduced it, starting with a service blueprint for AI-powered mobile health camps in tier 3 and 4 towns in Telangana. It showed, in one picture, what the patient sees, what staff do, what the doctor does and what the AI and backstage systems must do at each moment.

Service blueprint · AI-powered health camp

Simplified and generic

01 Arrive02 Wait03 Intake04 Consult05 After Patient Arrives, registersWaits in queueTalks to AI intakeSees the doctorGets Rx, follow-up Camp staff Token + basic vitalsGuides to a kioskHelps if stuckCalls next patientExplains the Rx Doctor Sees the intake summaryConsults; AI listensReviews, signs AI system Profile createdLanguage detectedSymptom intakeCase sheet draftedFollow-up scheduled Backstage Device + network checkQueue syncGuardrails, red flagsEMR storageFeedback to evals

That first blueprint grew into a living map of both apps’ touchpoints and of how our health camps run. It now drives features in both apps.

One metric, two stories

At Bhaktivedanta Hospital in Mumbai, the move was from an existing digital system. Doctors used to type the full record after every consultation, which took 10+ minutes. With Pranik, they review and correct the AI’s case sheet in under 2 minutes, a change that has held for 3 to 4 months. The deployment started with one doctor and grew to an entire department.

At Praja Hospital in Nellore, documentation time initially went up. That looked like failure until I understood why: there had been no documentation before. Prescriptions were on paper, and nothing was digitized. We had added a task that did not exist, and in return the hospital got structured records for the first time.

Same metric, two sites

Qualitative sketch, not to scale

Documentation time per consult, after go-live.

Then time eased. The doctors had designed their own workflow around the product, mostly routing the AI-output check to an assistant. Nobody on our team designed that. The doctors did, and the lesson was to notice it, and to treat it as product feedback rather than a workaround.