FealDeal
Sanjeevan Health Network
ABDM-linked booking and teleconsult across six clinics
A FHIR-native booking and teleconsult platform linked to ABDM, with consent enforced at the repository layer and a video call engineered to degrade to audio rather than drop.
- Client
- Sanjeevan Health Network
- Industry
- Healthcare
- Location
- Delhi NCR, India
- Duration
- 18 weeks
- Published
- Nov 2023
- Updated
- Jul 2026
0%
No-show rate, down from 22%
0/mo
Teleconsults per month on a line previously written off
0%
Of visits now produce an ABHA-linked clinical record
0s
P95 time from tapping join to the doctor being audible
01
The challenge
Sanjeevan Health Network runs six multi-speciality clinics across Delhi NCR and had just started offering teleconsultation. Booking was a phone number. Doctor availability lived in a paper diary at each front desk. Prescriptions were handwritten and photographed.
Three problems, one of them existential
- A 22% no-show rate. On a specialist's calendar, a no-show is not a small loss — it is a 20-minute slot that could not be resold because nobody knew it was free until the patient failed to arrive. Across six clinics this was the single largest source of lost capacity in the business.
- Double-booking and phantom slots. Two receptionists, one doctor, one diary: the failure mode is obvious and it happened weekly. Patients arrived to find their appointment did not exist.
- ABDM was not optional. To participate as a Health Information Provider under the Ayushman Bharat Digital Mission — link records to a patient's ABHA number, respond to consent-based record requests through the Health Information Exchange — they needed to speak the network's language, exactly. And under the DPDP Act, they needed to be able to prove that no clinical record was ever read without a valid patient consent.
The constraint that shaped everything
A meaningful share of their teleconsult patients connect from outside the metro on a 3G-grade link. Their first vendor had built the video call to demand 720p or fail. On a weak connection it failed. Patients who could not get a doctor on video simply stopped booking, and the teleconsult line was declared "not working in India". It worked fine — in an office, on fibre.
The bar we set with the clinical team was blunt: a degraded consult must always beat a dropped consult. A doctor who can hear a patient can still practise medicine.
02
What we built
FHIR R4 as the internal model — not a translation layer
The clinical record is stored as FHIR R4 resources natively. We considered a bespoke relational schema with a FHIR exporter bolted on, and rejected it. ABDM's HIP and HIU contracts are FHIR bundles. If your internal model is something else, you own a lossy, permanently-drifting translation layer forever, and every network spec revision becomes a migration. Modelling in FHIR from day one meant responding to a record request was serialisation, not transformation.
Consent enforced at the repository layer, not the controller
Every read of a clinical record passes through a repository that requires a valid, unexpired consent artefact for that purpose and that requester. There is no code path to the clinical store that bypasses it — not because we asked developers to remember, but because there is no method that takes a patient ID without also taking a consent context. Controller-level permission checks fail eventually; someone adds an endpoint in a hurry and forgets one. Make the unsafe thing unwritable and it stops happening.
Access is written to an append-only, hash-chained audit log. If a row were altered or removed, the chain breaks and the nightly verifier says so.
We did not build a WebRTC SFU
Building and operating a selective forwarding unit is a full product in its own right, and a bad one is worse than no video at all. We used a managed WebRTC provider and spent our engineering budget on the thing that actually differentiated: graceful degradation. The client measures available bitrate continuously. Below ~150 kbps it drops video and holds audio, tells both parties plainly what happened, and keeps the consult alive. Doctors get a one-tap "switch to audio" control they use often and without ceremony.
Slots that cannot double-book
Availability is materialised into concrete slot rows rather than computed from rules at request time. Booking takes an optimistic lock; concurrent attempts on the same slot fail loudly and immediately rather than both appearing to succeed. A short-lived Redis hold covers the gap between "patient selected a slot" and "patient completed payment", so a slot is never lost to an abandoned booking flow.
Attacking the no-show rate directly
A two-stage reminder — WhatsApp Business API at T-24h and T-2h, with SMS fallback when the WhatsApp message is undelivered — plus a one-tap reschedule link in the reminder itself. Most no-shows were never people refusing to come; they were people who could not come and had no frictionless way to say so. Give them a button and they will use it, and the slot goes back into inventory while it can still be resold.
03
The outcome
Rolled out clinic by clinic over ten weeks, front desks running the new system alongside the paper diary for the first fortnight at each site. The diaries were not taken away; they were simply stopped being opened.
Results
- No-shows: 22% → 7.4%. Almost all of the gain came from the reschedule button, not the reminder. Reminding someone of an appointment they cannot attend does not create attendance; giving them a way to move it recovers the slot.
- 1,900 teleconsults a month, up from a line of business that was previously being written off as unworkable. The audio-fallback path is used in roughly 12% of consults — which is to say, 12% of those consults would previously have been dropped calls and refunds.
- 84% of visits produce an ABHA-linked record, and the network's consent-based record requests are served automatically because the record was FHIR to begin with.
- Consult start time, P95: under 9 seconds from tapping "join" to a doctor being audible — measured on real patient devices, not on an office network.
What we would defend in an audit
Every clinical read in the system's history has an audit row, and every audit row is chained to the one before it. Zero unconsented reads is not a policy statement here — it is a property of the code, and the nightly verifier would tell us if that stopped being true.
Double-bookings have not recurred. Not "have reduced". The slot lock makes them structurally impossible, and the front-desk staff, who had lived with them weekly for years, noticed that before they noticed anything else we built.
Under the hood
How it's built.
Technology
- Laravel
- FHIR R4
- ABDM HIP / HIE-CM
- PostgreSQL
- Redis
- React
- Managed WebRTC (SFU)
- WhatsApp Business API
- AWS KMS
- Docker
Services used
- Healthcare Software Development
- Custom Software Development
- API Integration
- Cloud & DevOps
- UI/UX Design
Our previous build insisted on HD video and then failed on a weak line. PRS asked our doctors one question — can you practise on audio alone? — and rebuilt the whole call around the answer.
