One Platform, Three Workflows: What Building a Multi-Role EMR Taught Me
One Platform, Three Workflows: What Building a Multi-Role EMR Taught Me
At Cloudnine I designed and launched an EMR platform that had to serve three very different people at once: a doctor running a consultation from a clinical dashboard, a nurse recording vitals through a role-based login, and a pharmacist generating prescriptions through an integrated pharmacy interface. One patient journey, three professions, three completely different definitions of "done."
A multi-role platform is not one product with three logins
The trap is to build the doctor's experience first and then bolt on views for everyone else. That produces a system where two of the three roles feel like second-class users, and those two roles are the ones who touch it most often.
A doctor wants depth on one patient. A nurse wants speed across many. A pharmacist wants an unambiguous, unchangeable instruction. Those are not skins on the same screen, they are separate products sharing one record. The platform's job is to make the handover between them lossless, so the nurse's vitals show up in the doctor's context and the doctor's decision arrives at the pharmacy without anyone retyping it.
Clinical software gets judged in seconds, not sessions
I had the advantage of having been on the other side of the chair. As a paediatric dentist I knew exactly how much patience a clinician has for software during a consult: almost none. If a screen costs a doctor thirty seconds, that cost is multiplied by every patient, every day, and the workaround appears within a week.
That's why the metric I cared most about on the Consults app wasn't sign-ups, it was average consultation time. We scaled to over a thousand consults a day at a 95% conversion rate, and the number I was proudest of was cutting four minutes off each consultation. Four minutes is the difference between a tool the clinic tolerates and a tool the clinic defends.
Ten days is a real constraint, not a heroic story
We shipped Cloudnine's first teleconsultation platform in 10 days at the peak of COVID-19. People like that as a war story, but the useful lesson is what the constraint forced us to admit: almost nothing in the original spec was actually required for a doctor and a patient to talk and for a prescription to be issued digitally.
A brutal deadline is a very good scoping instrument. It only works if someone in the room genuinely knows the domain, because the person who has to say "this can wait" needs to be right. Speed without domain knowledge just ships the wrong minimum.
Productising internal tools is a different job
Turning our internal clinical platform into Clinics on Cloudnine, a SaaS product for doctors outside our own network, was the sharpest lesson of that period. Internal tools can lean on tribal knowledge, on a WhatsApp group, on the fact that everyone shares one process. External customers have none of that.
Everything implicit had to be made explicit: onboarding, configuration, defaults for a clinic whose workflow we'd never seen. The code carried over. The assumptions didn't. If you are productising something internal, budget most of the effort for the assumptions, not the features.
Disha skipped presentations and built real AI products.
Disha Somra was part of the June 2026 cohort at Curious PM, alongside 20 other talented participants.