Telehealth platform
Patients request an online consultation and see a registered doctor by video; four portals (patient, doctor, admin, practice management) run on one platform, live in production.
- Role
- Full-stack engineer
- Status
- Live in production
- Client
- Australian telehealth provider
- React
- Node.js
- REST APIs
- AWS
The problem
- Context
- Patients in Australia request an online consultation and see a registered doctor by video, without booking an appointment: they make a request and the first available doctor connects. Most requests are not appointments at all: medical certificates, prescriptions, referrals and test results. The platform has four portals: patient, doctor, admin and practice management.
- Constraints
- It runs on demand, so patients need to see whether doctors are online and how long the wait is before they start. Requests carry documents and Australian health identifiers, and many patients consult for a family member from one account, mostly from a phone.
- What was at stake
- Patients rely on it for certificates, scripts, referrals and results, so the path from request to consultation to the document coming back has to be clear, and the platform must steer emergencies away from a video queue.
What I built
Requesting a consult
Seven typed request categories
A request starts by choosing one of seven types (certificate, prescription, referral, pathology, radiology, results, or other) so the doctor knows what is needed before the call.
Context travels with the request
Patients attach images and documents and add notes, so the doctor has everything when the consultation starts. An emergency warning sits above the confirm button.
Availability before commitment
Whether doctors are online, and the current wait, are visible on every screen, so a patient knows what to expect before requesting.
Patients and families
Health identifiers on the profile
Profiles hold Medicare and individual healthcare identifier numbers and two emergency contacts, captured once instead of at every consult.
Family profiles
A parent can consult on behalf of a child from the same account.
After the consult
An inbox for what comes back
Prescriptions, referrals and results arrive in an inbox that can be searched, filtered by date and starred, with a separate history of past consultations.
A connection test before the call
Patients can test their camera and connection before a doctor is engaged, rather than discovering a problem during the consultation.
Payments and help
Saved cards and clear costs
Patients store payment cards and see what a consultation costs, including bulk-billing eligibility, before they request one.
Self-service answers
A help centre answers the common questions (prescriptions, referrals, consulting for someone else, technology requirements) so support time goes to real problems.
Platform
Four portals, one platform
Patient, doctor, admin and practice-management portals run over one set of REST APIs on AWS, each built for its own audience, and the whole platform is live in production.
How it works
Four portals
Patient, doctor, admin, practice
REST APIs
Node.js
Integrations
AWS
Hosting and deployment
Tell me what you’re building and where it’s stuck.
I’ll tell you the cleanest path forward, including if it’s “don’t build that.”
Or write tocontact@alihassan.dev
