Practice growth
Delegating to a secretary without giving away the record
How granular permissions let your front desk do more, while the clinical chart stays yours.
7 min read
A cardiologist and a dermatologist need very different tools. They do not need different records of the same patient. Getting that distinction right is the whole design of how Doctopass supports twenty specialties without splintering into twenty disconnected apps.
The trap of building twenty products
The obvious way to serve many specialties is to build a tailored system for each. It demos beautifully and falls apart in practice, because patients don't stay inside one specialty. The same person sees their GP, a cardiologist, and an endocrinologist, and if each runs separate software, the patient's history fractures into pieces that never quite line up.
The result is the thing every clinician has lived through: re-asking the same questions, re-ordering tests already done, and making decisions with half the picture.
A shared core, specialty modules on top
Doctopass inverts the usual order. At the centre is one patient record, demographics, history, medications, allergies, results, every prior consultation. That core is identical for every specialty and every role. On top of it sit specialty modules that change what tools and templates a clinician sees, not what record they're writing into.
- The core holds the truth about the patient and never forks.
- A module adds the specialty's vocabulary, fields, templates, and AI behaviours, the cardiology module knows about ECGs; the dermatology module knows about lesion mapping.
- Switching specialties changes the lens, not the underlying data.
Tailored tools, shared truth. The specialty decides how you work; it never decides what's real about the patient.
The architecture in one line
One canonical patient record at the centre; specialty modules layered on top that change the tools, templates, and AI prompts, but write into the same shared chart.
Why this is harder than it looks
A shared core sounds simple until you try to build it. Every specialty wants its own fields, its own structure, its own way of describing a finding. The engineering work is keeping the modules expressive enough to feel native to each specialty, while ensuring everything they capture lands in a record the next clinician can actually read.
We do that by treating the core data model as sacred and the presentation as flexible. A module can render a finding however its specialty expects, but the finding itself is stored in a shared, structured form. The cardiologist's note and the GP's note are different on screen and compatible underneath.
What the patient gets out of it
The payoff lands on the person, not the software. When a patient moves between the specialists in a practice, their record moves with them intact. Allergies entered once are known everywhere. A medication a cardiologist prescribed is visible to the GP checking for interactions. Nobody re-asks what's already on file.
Twenty specialties, one record. The modules are what make each clinician feel at home. The shared record is what makes the whole thing safe.