Remote consultation
Appointments, consultations and prescriptions where the patient and the doctor are not in the same room — booking, the consultation itself, what gets recorded, and what has to happen afterwards for any of it to count.
Talk about scopeA consultation is not a video call with a database attached
The call is the easy part and the part everyone demos. What decides whether the system is usable is everything around it: proving the person on the other end is who the record says, handling the consultation that has to become a physical referral, issuing a prescription that a pharmacy will actually accept, and recording a clinical judgement made without an examination in a way that is honest about that limit. A platform that treats the video as the product ships the demo and none of the system.
The only path a video-first build handles well.
Must be in a form a pharmacy will actually honour — an integration and a jurisdiction question.
Leaves the platform, and has to come back to the same record or it is lost.
A referral that vanishes is worse than none, because everyone believes it was made.
Needs a defined path that does not depend on the patient staying on the call.
What we would build
Proving who is on the call
In a clinic, identity is established by a person being in the room. Remotely it has to be established by the system, before anything clinical is said — and re-established for a follow-up months later, possibly on a different device. This is the requirement most telemedicine builds under-scope, and it is not solvable by a login alone.
The diary is the hard part
Real availability rather than published availability, overruns that push the next patient, no-shows that must release the slot, cancellation windows, and time zones as soon as either party travels. Get this wrong and no amount of video quality rescues the experience.
A record made without an examination
What the doctor could not do remotely is clinically relevant, so the note has to capture the limits of the consultation as well as its findings. A record that reads identically whether or not anyone was examined is misleading to whoever reads it next.
The handoff to something physical
A meaningful proportion of remote consultations end in "you need to be seen", a test, or a prescription. Those exits are the system, not an edge case — a referral that leaves the platform and vanishes is worse than no referral, because everyone believes it was made.
A prescription somebody will accept
Issuing one is trivial; issuing one a pharmacy will honour is an integration and a legal question that varies by jurisdiction. It has to be scoped before the estimate, because the answer changes what is being built rather than how long it takes.
Degrading honestly on a bad connection
Consultations happen on the connection the patient has, not the one the demo had. The system should fall back deliberately — audio only, then structured messaging — rather than failing mid-sentence and leaving neither side sure whether the appointment happened.
Scheduling is the whole product
Remote practice lives or dies on the diary: a doctor's real availability rather than a published one, appointments that overrun, no-shows that have to release the slot, cancellations inside a notice window, and time zones the moment either party travels. Most of the complaints about telemedicine platforms are scheduling complaints wearing another name, which is why we would build the diary first and the call second.
When not to build this
A packaged product is the right answer more often than a development company usually admits, and if your problem is an ordinary one that something off the shelf already solves, we will tell you so rather than quote for it. What follows is the case for the other answer — the conditions under which building is worth what it costs.
The workaround has become the process
A packaged system that mostly fits leaves a residue — the spreadsheet kept alongside it, the step done by hand every month, the field used to mean something it was not named for. When that residue is where the actual work happens, you are already maintaining custom software, just without any of the benefits of having built it.
The thing you do differently is the thing it cannot do
Every business has a few processes that are genuinely its own, and those are usually the ones it competes on. Off-the-shelf software is built for the average of a sector, so it handles the ordinary parts well and the distinctive part not at all. Building is worth it exactly where that overlap fails, and rarely anywhere else.
A vulnerability shared by every deployment
A vulnerability in a packaged product is a vulnerability in every deployment of it, and attackers only have to find it once. A system built for one business is not on that list.
More platforms
Other sectors we can build for.