Case study · Healthcare

Synclo

Synclo Complete Care was a suite of hospital products, one for each person in a visit: the patient at the helpdesk, the doctor, the nurse at the station and the lab technician. I designed all of it as the only designer, and helped build it.

Role: The only designer across the product line, as an individual contributor. I also helped build the system.
Team: I was the only designer, alongside engineers including Vinay Kumar (senior software engineer) and Akhil Ravilla (software engineer), under our CEO, Ajit.
When: 2020–2022, at Detrix, which became Synclo

Read as MarkdownUpdated 18th October 2026

Synclo QMS home on iPad, showing patients registered, patients in the queue and average waiting time above consultation and patient-engagement panels — The QMS for Doctors on iPad: the day as one board. Who is registered, who is waiting, how long they wait, and where consultation time goes.

The products

Six products, one for each person in a visit. I designed all of them, and a test run in real hospitals removed two.

CheckInWebPatients at the hospital helpdeskCheck in by scanning a QR code, in the patient's own language.
QMS for DoctorsiPadOPD doctorsRun the day's patient queue and consultations, with AI diagnostic support and e-prescriptions.
MDsynciOS and AndroidDoctorsOversee consultations, with a full view of each patient's profile.Removed after the hospital test run
PatientSynciOS and AndroidPatientsView reports, book and manage appointments, and track maternity care.
LabSyncWindowsLab techniciansHandle lab report requests and billing.Removed after the hospital test run
NPmSDesktop and webHead nurses at the nursing stationMonitor patients, assign work and keep the station productive.

Why we started with medium-sized hospitals

The size of a hospital changed the problem, so we chose a size before we designed a screen.

We sorted hospitals into three sizes by who works there and how many patients they see. Turn the knob on the clinic model to compare them.

Small clinics had little reason to change. Large hospitals keep patient data inside the hospital; for them we planned the suite on their own servers, managed by us. Medium hospitals were willing to experiment and had a budget, and we needed somewhere to build, test and change the product. We started there.

3–5 doctors
6–12 nurses
1 head nurse
2 at reception

Building the medium clinic

Tap or hover a room to see who works there.

A faded figure fills a range to its top. Each figure is one person, at the low end of the team's range; waiting patients are one for every ten seen a day.

Medium clinic

What they had: A medium team with some digital process, not streamlined.
What they asked for: A streamlined process, and departments that connect to each other.

Why we started here

Often run by a doctor couple, with two different sets of patients' needs. They had enough coordination to need a connected suite, were willing to experiment, and had a budget. A startup needs somewhere to build, test and change a product, and they were that place.

Medium clinic role structure: two at reception, four doctors, six nurses, with OPD and IPD — The team's role map for this size, from the research deck.

Synclo challenges slide: clinics of different levels function differently, and Synclo wants to reduce consultation time, over small, medium and large target clinics — Our research deck's brief: clinics of different sizes work differently, and consultation time is the thing to cut.

Arriving: the patient checks themselves in

Check-in starts with the patient's own language and ends with the patient confirming what the doctor will read.

A patient scans a QR code at the helpdesk and checks in on their own phone. Before sending, they read back exactly what the doctor will see. That is the first of two checks a person makes before anything moves on; the second is the doctor's.

Synclo Check In asking the patient to choose a preferred language before anything clinical, co-branded with the hospital — Language first, then their concerns in their own words, then follow-ups. The last screen is the check: the patient confirms what reaches the clinician.

Check In asking what is your concern, with searchable categories and a checklist of common symptoms — Language first, then their concerns in their own words, then follow-ups. The last screen is the check: the patient confirms what reaches the clinician.

Check In waiting area screen counting down the wait with the queue position and a visit overview from check-in through to discharge — Then the wait: where they are in the queue, how long, and what the visit will include.

Patient waiting screen showing minutes until a room is allotted, above an hourly chart of how busy the clinic usually is — Then the wait: where they are in the queue, how long, and what the visit will include.

The consultation

The doctor's day is one board, and the AI's suggestions wait for the doctor's choice.

In a consultation the AI only suggests, and the doctor decides: treatment stays locked until the doctor picks one of its diagnoses.

So a person stands at both ends of the model: the patient confirms the symptoms before it sees them, and the doctor confirms the plan after.

We built the AI but never fully tested it, so these screens show how it was designed to reach the doctor, not a proven model.

Synclo QMS custom space, a doctor-composed board mixing an anatomy reference image, notes and a break timer with the standard consultation widgets — Every panel is a widget, so each doctor composes the board their day needs.

Consultation capture, with suggested symptoms and suggested diagnoses the doctor selects from, and a panel to mark each one as to rule out, suspected or follow up — Suggestions, then three candidate diagnoses at 80, 50 and 30 percent with treatment locked until the doctor picks, then medicines the doctor curates, with the patient's instructions in plain words.

Three candidate diagnoses from Synclo AI with probability scores of 80, 50 and 30 percent, as radio options the doctor must choose between before treatment unlocks — Suggestions, then three candidate diagnoses at 80, 50 and 30 percent with treatment locked until the doctor picks, then medicines the doctor curates, with the patient's instructions in plain words.

Where the model sits: between the patient's check and the doctor's.

The nurse station

NPmS was designed for the head nurse: the same queue, with the actions that belong to the station.

Several products write to one patient record, so each block names the product that last updated it, and when. A nurse can see where a fact came from before trusting it.

NMS live queue showing current queue length, average wait and throughput above a searchable, reorderable patient list with a hold-queue control — The live queue: its length, the average wait and patients seen per hour, a hold control, and each patient one click from no-show, reschedule or vitals.

NMS patient summary where each block of details names the product that last updated it and when — One record, several products. Each block names which one last touched it, and when.

Between visits: maternity care

Maternity care runs across many visits, so the patient and the doctor need one history.

For the 9M maternity vertical of Ankura Hospitals, one of the hospitals we onboarded, we designed PatientSync: an iOS and Android app, connected to the doctor's QMS, that follows a mother through 16 months or more of visits. Every consultation starts from the whole history.

A patient's home showing the next appointment with its hospital and doctor, recent prescriptions as documents, and a book-an-appointment action — PatientSync: the next appointment and recent prescriptions at home, visits marked virtual or walk-in, reports to open, and the family's records beside the patient's own.

Upcoming appointments marked virtual or walk-in, with a join-call control that says it enables fifteen minutes before, above past appointments — PatientSync: the next appointment and recent prescriptions at home, visits marked virtual or walk-in, reports to open, and the family's records beside the patient's own.

What the hospitals changed

Real hospitals removed two of our six products, both because of how those hospitals worked.

After the first QMS demo, two to three multi-speciality hospitals agreed to a test run, and we onboarded three, Ankura among them. The average consultation fell from about 30 minutes to about 20.

MDsync went first. Doctors declined it: in maternity care, patients' messages are many and often urgent, and they belong in the QMS with the secondary doctor or nurse, not on the consulting doctor's phone.

LabSync went too. Most of these hospitals used partner labs, so there was no in-house lab for it to serve.

A doctor's dashboard showing patient satisfaction, incoming against outgoing referrals, patients split across examination, investigation, treatment and discharge, and a work-scope of wards and ICUs by room — MDsync, removed after the test run: the doctor's day by stage and ward, a profile from provisional to final diagnosis, examination as a checklist, and referrals.

LabSync dashboard on Windows: counts for advised by doctor, patients visited, advised but not visited, direct walk-ins and referrals to other labs, above trending tests, weekly sales, coupons and payment methods — LabSync on Windows, removed after the test run: tests advised against patients who came, walk-ins and referrals, then trending tests, sales and payments.

What this page does not claim

The clinic sizes are the team's planning segments, not a survey of real hospitals.
The AI was built but never fully tested. Its screens show how the review steps were designed, not diagnostic accuracy or clinical validation.
The drop from about 30 to about 20 minutes per consultation comes from the hospital test run, not a controlled study.
The clinic model is drawn for this case study, not a Synclo screen. Its furniture shows what a room is for, not how many it holds.