Healthcare
How Techparser Built a Four-Portal Telehealth Platform Live in Production in Australia
Techparser built a telehealth platform where patients see a registered doctor by video across four portals, live in production in Australia.
- Client
- Australian telehealth provider
- Industry
- Healthcare
- Timeline
- Live in production
- Team
- 1 senior full-stack engineer
Results
- 4 portals
- Patient, doctor, admin and practice management
- 7 request types
- Certificate, prescription, referral, pathology, radiology, results, other
- 2 contacts
- Emergency contacts captured on every patient profile
The problem
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 but medical certificates, prescriptions, referrals and test results. The platform runs four portals for patients, doctors, admins and practice management. Because it runs on demand, patients need to see whether doctors are online and the current wait 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.
Patients rely on it for certificates, scripts, referrals and results, so the path from request to consultation to the document coming back has to stay clear. The platform also has to steer emergencies away from a video queue, since a video consultation is the wrong place for an emergency.
What Techparser built
- Seven typed request categories (certificate, prescription, referral, pathology, radiology, results or other) so the doctor knows what is needed before the call.
- Patients attach images, documents and notes with a request, and an emergency warning sits above the confirm button.
- Whether doctors are online and the current wait are visible on every screen, so patients know what to expect before requesting.
- Profiles hold Medicare and individual healthcare identifier numbers and two emergency contacts, captured once instead of at every consult. A parent can also consult on behalf of a child from the same account.
- A connection test lets patients check their camera and connection before a doctor is engaged, rather than discovering a problem mid-consultation.
- Prescriptions, referrals and results arrive in an inbox that can be searched, filtered by date and starred, with a separate history of past consultations.
- Patients store payment cards and see what a consultation costs, including bulk-billing eligibility, before they request one.
- A help centre answers the common questions so support time goes to real problems.
- Patient, doctor, admin and practice-management portals run over one set of REST APIs on AWS, and the whole platform is live in production.
Decisions that mattered
Four portals on one set of APIs
The platform serves four audiences: patients, doctors, admins and the practice-management team. Techparser built them as four portals over one set of REST APIs on AWS rather than four separate systems, so a request made in the patient portal, the doctor who answers it, and the admin who oversees it all read and write the same records. The trade-off is a shared contract that every portal depends on: a change to the request model touches all four. In return there is one source of truth for a consultation, and no reconciliation between separate back ends.
Requests before appointments
Most people do not want an appointment. They want a certificate, a prescription, a referral or their results. Techparser modelled the product around that: a patient makes a typed request, choosing one of seven categories, and the first available doctor connects, instead of booking a slot. Each request carries its documents, notes and health identifiers so the doctor arrives knowing what is needed. The cost is that availability has to be visible and honest, because there is no calendar to set expectations. The platform shows whether doctors are online and the current wait on every screen before a patient commits.
On demand, with a safety valve
Running on demand means a patient could reach a video queue with an emergency, or start a call on a device that cannot hold one. Techparser addressed both before the consultation begins. An emergency warning sits above the confirm button to steer urgent cases to the right place, and a connection test lets a patient check their camera and connection before any doctor is engaged. The decision was to spend effort on the moments before the call, where a wrong turn is cheap to prevent, rather than recover from a failed consultation after a doctor's time has already been spent.
Outcome
The platform is live in production in Australia at instantconsult.com.au. Patients request an online consultation and see a registered doctor by video across four portals: patient, doctor, admin and practice management.
Because requests are typed and carry their documents, context, identifiers and consent travel with each one, so a doctor arrives at a consultation already knowing what is needed. The same design lets the platform run on demand, show availability before a patient commits, and keep the path from request to returned document clear without turning every interaction into an appointment.
Questions about this project
- What technology stack does the telehealth platform use?
- The platform is a React front end over Node.js REST APIs, hosted and deployed on AWS. The four portals, patient, doctor, admin and practice management, share that one set of APIs, so a consultation is read and written as the same record wherever it is touched. The stack was chosen to keep one source of truth across all four audiences rather than running separate back ends that would need reconciling.
- Why is the platform built around requests instead of appointments?
- Most patients need a certificate, prescription, referral or results, not a scheduled visit. Techparser modelled the product around typed requests: a patient chooses one of seven categories and the first available doctor connects. Each request carries its documents, notes and health identifiers, so the doctor knows what is needed before the call. Because there is no calendar, the platform shows whether doctors are online and the current wait on every screen before a patient commits.
- Can Techparser build a four-portal telehealth platform like this for us?
- Yes. Techparser built this platform end to end: the patient, doctor, admin and practice-management portals, the REST APIs behind them, the consult-request flow with its documents and health identifiers, the inbox for returned prescriptions and referrals, payments and the pre-call connection test, live in production on AWS. We can build the same for your service, on your rails and your compliance needs. Book a call to talk through what you need.
