ABDM-linked booking and teleconsult across six clinics

FHIR R4 as the internal model — not a translation layer

The clinical record is saved as FHIR R4 resources natively. We thought about a custom database design with a FHIR export added on, and said no. ABDM's HIP and HIU rules are FHIR bundles. If your own model is something else, you are stuck with a translation layer that loses data and drifts apart over time. Every change in the network rules then becomes a big data move. Using FHIR from day one meant that answering a record request was just packaging the data, not changing it.

Consent enforced at the repository layer, not the controller

Every read of a clinical record goes through one data layer. It needs a valid consent that has not expired, for that purpose and that requester. No code can reach the clinical records without 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. Permission checks placed on each page of code fail sooner or later; someone adds a new endpoint in a hurry and forgets one. Make the unsafe thing impossible to write and it stops happening.

Every access is written to an audit log that can only be added to, and each entry is linked to the one before it. If a row is changed or removed, the chain breaks and the nightly check tells us.

We did not build a WebRTC SFU

Building and running a selective forwarding unit is a full product in itself, and a bad one is worse than no video at all. We used a managed WebRTC provider and spent our build effort on the part that really set this apart: graceful degradation. The app keeps measuring the available bitrate. Below ~150 kbps it drops the video and keeps the audio. It tells both people plainly what happened and keeps the consult going. Doctors get a one-tap "switch to audio" button that they use often and easily.

Slots that cannot double-book

Doctor times are saved as real slot rows, not worked out from rules each time someone asks. Booking uses a lock, so if two people try the same slot, one fails at once and clearly, and both never seem to succeed. A short Redis hold covers the time between "patient picked a slot" and "patient paid", so a slot is never lost to a booking that was left half done.

Attacking the no-show rate directly

A reminder in two steps — WhatsApp Business API at T-24h and T-2h, with SMS if the WhatsApp message is not delivered — 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 easy way to say so. Give them a button and they will use it, and the slot goes back on sale while it can still be sold.