Dr Smart
A preventive healthcare platform for Pakistan: EMR, patient app and admin portal on one multi-org backend, serving 50 locations.
- My role
- Chief Technology Officer
- Duration
- Mar 2025 – Present
- Platforms
- iOS · Android · Web
- Status
- Live and maintained
Figures reported by the client
Preventive care fails when no one owns the record
Preventive healthcare in Pakistan is largely inaccessible. People have no practical way to monitor chronic conditions like diabetes and hypertension, or to reach a specialist without travelling to a clinic.
The deeper problem sits underneath that one. Clinics, labs and pharmacies each keep their own records, and none of them follow the patient. A blood test at one provider is invisible to the doctor at the next. Every visit starts from nothing, which is exactly the condition under which preventive medicine stops working: you cannot spot a trend in a patient you are meeting for the first time, every time.
So the brief wasn't an app. It was a record that outlives the appointment, and a way for three different kinds of organisation to write to it without being able to read each other's business.
One record, three kinds of organisation
One API over one schema
A single NestJS service owns every write. Clinics, labs and pharmacies are organisations inside it, not separate deployments, so a lab result lands in the same patient record a doctor reads from, with no sync job in between.
Two front ends, one contract
The React admin portal and the React Native patient app were built against the same API contract. Vitals, lab reports, episodes, allergies and medicines behave identically in both, because there is only one place they can come from.
Shipped, then kept shipping
CodeBuild and CodeDeploy push the API to AWS on merge; Firebase carries messaging and push. The portal went live in March 2025 and the mobile app followed in January 2026, against a schema that had to stay stable for both.
What it actually does
What I chose, and what it cost
A health record has a large, highly relational domain model. Structure and strong typing keep that model honest as it grows, and make onboarding a matter of reading types.
Health records are relational and query-heavy: episodes join to vitals join to labs join to prescriptions. Multi-org isolation is enforced in the schema rather than by running separate databases.
One codebase across iOS and Android, sharing types with the API. Two native codebases would have meant shipping one platform and promising the other.
The admin portal's value is in the data model, not in bespoke interface design. An off-the-shelf component library bought months of build time.
Automated pipeline from merge to deploy, so releases are routine rather than events.
Health data with three organisations reading it
Clinics, labs and pharmacies share one backend and must never share each other’s business. I read Information Security at NUST, so isolation and consent were schema decisions taken in the first migration rather than a hardening pass bolted on before launch.
- Organisation is a first-class entity: every readable row is scoped to one, and the scope is enforced at the query layer, not in the controller.
- Consent is data, not configuration: a patient grants an organisation access to a defined slice of their record, and revoking it is a write, not a support ticket.
- Least privilege by role: a lab technician, a clinician and an org admin see three different records from the same query.
- Auditability: who read what, and when, because in health data the read is as sensitive as the write.
Ten months from API to app store
API and admin portal live
The NestJS service and React portal shipped first, so clinics could work before there was an app to hand to patients.
DrSmartGo on both stores
The React Native app launched on iOS and Android against a schema already stable in production for ten months.
Maintained and extended
Both platforms are actively developed. Fifty locations are live and the record model keeps growing.
Shipping the portal ten months before the app is the decision I'd defend hardest. It meant the schema was proven by real clinic use before a single patient installed anything.
What I'd change: I'd model consent before modelling the record, not alongside it. Retrofitting permission boundaries onto a schema that already held data cost more than designing them first would have, and it's the advice I now give every team building anything multi-tenant.