Thrive Rx — Telehealth Platform (Australia)

The problem

Most healthcare is reactive: you go when something is wrong. Thrive Rx sells the opposite — comprehensive blood panels, biomarkers tracked over time, and a practitioner who reads them and adjusts a protocol before anything has gone wrong.

That is a long chain to hold together in software. A member orders or uploads pathology; results land and have to be made legible; an AHPRA-registered practitioner reviews them and writes a protocol; a prescription may or may not follow, at their discretion; a partner pharmacy dispenses it. Every step has a different actor, and most of them are regulated.

What I owned

I joined as a full-stack developer, one of four developers and a designer, and worked across the Next.js front end and the Express and Kysely back end — 113 commits to the front end and 109 to the back end. Three areas were mine end to end:

A custom forms platform. Practitioners build their own questionnaires — steps, conditional visibility, date bounds, answer validation — send them to an audience, and read responses back against the version of the form each patient actually filled in.

Prescription lifecycle integration. Prescriptions live in the Parchment portal, and their state changes arrive as webhooks. I built the webhook handling, the manual resync for when the two sides drift apart, and the prescriber attribution that keeps a resynced prescription credited to the practitioner who wrote it.

Voice and SMS. Twilio Verify on signup, Twilio voice, and SMS templating through Courier with the template variables generated as types rather than hand-written.

Constraints

This is regulated healthcare in Australia, and the rules are not decoration around the software — they are its shape.

Practitioners are AHPRA-registered and independently verifiable. The platform operates under Australian privacy legislation, which makes access scoping a requirement rather than a feature: who may see a patient record, a form submission, or a prescription is a legal question before it is a product one. Prescriptions are issued only where clinically appropriate, at practitioner discretion — so the software can present the option and must never imply the outcome.

The practical consequence is that "mostly correct" is not a state the system is allowed to be in.

Key decisions

Webhooks over polling for prescriptions. Prescription state lives in the Parchment portal, not in our database, so the platform has to learn about every change from outside. Polling was the obvious alternative and the wrong one: it is a choice between checking often enough to be current — which means a constant load of requests that almost always report nothing — and checking rarely enough to be cheap, which means the platform shows a stale prescription state to a clinician. Webhooks put the update on the event instead of the clock.

The cost is that webhooks are not a guarantee. A delivery can be missed, arrive out of order, or arrive twice, so the handler has to be idempotent and there has to be a way back to the truth. That is what the manual resync is for — not a workaround, but the deliberate second half of choosing webhooks.

Courier over templating notifications in-house. Voice, SMS and email all needed templated content, and message templates are the kind of thing that looks like a morning of work and becomes a small product: versioning, per-channel variants, and a non-developer wanting to change wording without a deploy. Courier owns that, and template variables are generated as types, so a template expecting a field the code does not send fails at compile time rather than in someone's inbox.

Where it got hard

A form looks like one thing to the person building it and is many rows to the database — the form, its steps, its fields, the conditions that show or hide them, and the audience it was sent to. Saving one is therefore several writes, and the first version treated them as if they were one.

They are not. A write could fail halfway, which left a form that was partly saved and — worse — could still publish. Retrying made it worse rather than better: the retry created a second copy of what had already succeeded, because the client was generating the ids and had no way to know which of its writes had landed.

Fixing it meant changing who owns identity. The server issues the field ids now, so a failed edit can be retried against the same rows instead of duplicating them. A save that cannot complete fails loudly and publishes nothing rather than leaving a half-built questionnaire in front of patients, and conditions that point at fields which no longer exist are pruned instead of dangling.

What I'd do differently

Start with compliance rather than arriving at it.

Australian rules around personal health information are strict, and on this project they were mostly met as they came up — a question about who may see what, answered when a feature needed the answer. Writing those data-access rules down at the outset, as rules the system enforces rather than intentions each feature honours, would have moved that thinking to where it is cheap. In a regulated domain that is not process overhead; it is the specification.