All resources
Field notes · 12 min read · March 19, 2026

Designing Adicare for the Indian OPD

High volume, short consults, many languages. What it takes to build software that survives a real outpatient department.

An Indian outpatient department is one of the most demanding software environments we've ever designed for. Not because of edge cases — because of the average case. High patient volume, very short consultations, multiple languages in the same waiting room, and connectivity that comes and goes. Software that assumes a calm desk and a stable connection simply doesn't survive here.

Design under real constraints

When a doctor may see dozens of patients in a session, every second of friction is multiplied. A two-second delay per prescription isn't a UX nitpick — it's minutes lost across a day, and patients still waiting outside. So our first design rule is brutal: nothing the doctor does should get slower because Adicare is in the room.

  • Time per consult is short — the tool has to keep pace with the pen, not interrupt it.
  • Connectivity is unreliable — the system has to keep working offline and sync when it can.
  • Many languages coexist — instructions, reminders, and records have to meet patients where they are.
  • The front desk is overloaded — anything we can automate (reminders, refills, records) buys back real time.

Offline is the default, not the fallback

We treat patchy connectivity as the normal condition. The pad and the app are built to function fully without a network and reconcile later. A dropped connection should never mean a dropped prescription. This single decision shapes a surprising amount of the architecture — and it's non-negotiable for the settings we're building for.

Giving time back to the front desk

The doctor's room is only half the OPD. The other half is the front desk — appointments, follow-up calls, refill requests, lost reports. A lot of that is repetitive work that quietly eats the day. Pushing prescriptions, reminders, and records to patients automatically over channels they already use takes that load off people who are stretched thin.

If the software only helps the doctor and ignores the queue outside the door, it hasn't really helped the clinic.

Meeting patients in their language

A reminder a patient can't read is a reminder that doesn't work. Records and instructions that land in the patient's own language aren't a nice-to-have in India — they're the difference between a prescription being followed and being misunderstood. Multilingual support is built into the foundation, not bolted on at the end.

We're writing these down as field notes rather than conclusions. The OPD has a way of humbling assumptions, and we expect to keep revising as we learn from real practices. But the principles above — keep pace with the pen, assume no network, give the front desk its time back, meet patients in their language — are the ones we keep coming back to.

See Adicare in your own clinic.

Book a 15-minute walkthrough and we'll show you how the prescription pad, records, and AI fit your practice.

More reads
Product · 6 min read
Why we built Adicare on paper, not screens
Research · 9 min read
Teaching AI to read a doctor's handwriting