Back to case studies
How a phone call books the right doctor
Patients describe what is wrong out loud. The system works out what they need and books it, and the record goes into India's national health programme.
- ABDM
- the national health programme every record is filed into
- One call
- from a patient describing a problem to a booked provider
- Company
- Undisclosed
- Industry
- Healthcare
- Company size
- Under 20
- Location
- India
Challenge
Two hard problems sat on this build. Software was only one of them. A national health programme decides what the platform is allowed to do, and a patient on the phone decides whether any of it gets used.
The government owns the specification
Ayushman Bharat Digital Mission sets the rules a health platform in India has to meet. Nothing here was ours to decide. The programme says what a record looks like and how it moves, and a build that disagrees with it does not go live.
Audits stand between the build and the patients
Acceptance is not a date somebody picks. Quality and security get examined first, and the standard is set by people who have never met the product. An ordinary internal review is a much lower bar than this one, and finding that out late costs a release.
The records belong somewhere else
Patient data does not stop at the client's database. It has to reach the national system in the shape that system expects, which is a harder problem than storing it well. A mismatch there is not a bug any user reports. It is a record the country cannot read.
A patient in trouble will not fill in a form
The people who most need this are the least likely to work through a booking screen. They know what is wrong and would rather say it out loud than type it. A form asks them to translate that into fields and dropdowns first, and plenty of them will not.
Nobody asks for the right service by name
A patient describes a problem rather than a product. Some of what arrives needs a specialist, some of it needs a home care visit, and the caller has no reason to know which. Something has to read the request and decide, before a booking can happen at all.
A finished call is not a booking
Details collected in a conversation do nothing on their own. Somebody still has to find a provider who can take the case and send the request to them. That step is where a system like this usually gives up and pushes the work back to a human queue.
Two front doors, one set of rules
The client wanted a website and a mobile app. Both write to the same records. A feature that behaves differently in one of them is not a difference in polish. It is two versions of a patient's history.
What we built
Everything here was built inward from the rules rather than outward from a feature list. The answers run in the order the problems were listed.
Built to the programme, not adapted to it
We designed the integration against the mission's own requirements before writing the product around it. The slow part came first, and that is the trade this kind of work rewards. A platform retrofitted to a government standard has to be opened up again everywhere, and the parts opened first have already moved on.
The audits were scheduled, not survived
Quality and security work sat in the plan next to the features rather than after them. The evidence an auditor asks for was produced as the thing it describes was being built. The platform is in production and carrying real patient records, which is the only proof that any of this landed.
The record is written where the country keeps it
A patient's history goes into the national system rather than sitting in one company's database. The next clinician they see can find it, and that is the whole reason the programme exists. Most of the work was in matching what that system expects rather than in storing anything.
The intake is a phone call
A patient starts an audio call and says what is wrong in their own words. The assistant keeps asking follow up questions until it has everything a booking actually needs. Nothing about it asks the caller to know the vocabulary, which is what a form quietly does.
The request is classified before it is routed
The system works out what kind of request this is before it looks for anybody to send it to. A specialist appointment goes one way. A home care visit goes another. That decision is made once and in one place rather than at every point the request passes through.
The booking is placed by the system
When the call ends the automation goes and finds a provider who can take it. The request reaches them without anybody at the client having to rekey a word of it. A person is still there for the cases that need one, which is a much smaller pile than it was.
One platform behind both
Website and app are two doors into one system. Rules live in one place and both surfaces read them, so neither can drift into a version of the truth the other does not have. On an ordinary product that is tidy engineering, and here it is a patient's medical history.
What changed
The platform is live, and the people it was built for reach it by talking rather than by typing.
In production, inside the national system
The system runs in production and every record it creates goes where the programme says it goes. That was the condition the whole build answered to, and it held all the way through.
A patient talks and a booking appears
Somebody who would never have finished the form gets to describe the problem out loud instead. What arrives at the provider is a request with all the detail already in it. Nobody at the client touched it on the way.
The routing decides, not a queue
Requests reach the right kind of provider, and nobody has to read each one first. A doctor and a home care team get sent the cases that belong to them. The client runs it with under twenty people.
Next stepYour first release could be live
Your first release could be live
next month.
Tell us about the app you want to build. We send back a costed plan with a fixed price and a launch date, free and yours to keep.
