Clinic Management System - Cannabiz Elite (Australia)

The problem

A cannabis clinic runs on tools that were never meant to meet: a scheduling app, a video call, whatever the prescriber writes scripts in, a storefront, and email to the pharmacy. Every gap between them is manual, and every manual step is somewhere a script gets lost or a repeat order never happens.

That is a revenue problem as much as an operational one. A patient who cannot easily reorder against a valid script does not reorder, and a clinic rarely finds out why.

What the platform does

Six things a clinic would otherwise buy separately: patient self-scheduling, built-in telehealth, prescription creation and tracking, a patient portal for viewing scripts and ordering against them, a commerce engine that understands intervals, limits and repeats, and a pharmacy portal giving fulfilment partners live order visibility.

The path is booking to consultation to script to purchase without the patient changing tool, with reminders before a script expires. Audit logs, encryption and 2FA are part of the platform rather than added later, because a clinical system is asked to prove who saw what.

What I owned

I worked on this as a full stack developer at SCSS Consulting, across the Next.js front end and the Node and PostgreSQL services behind it.

My main piece was the integration with Parchment, the prescription portal, along with the back-end APIs it runs through. I also built the shared component library the clinic-facing screens are assembled from, which took roughly 40% off the time a new screen costs.

Constraints

This is regulated healthcare in Australia, and the rules set the shape of the software rather than decorating it.

Prescribing is restricted to authorised prescribers, patient data sits under Australian privacy legislation, and a prescription is a clinical record with an audit trail rather than a line item. The practical effect is that access is a legal question before it is a product one: who may see a script, who may act on it, and what the system can prove about both.

Where the abstraction breaks

The commerce engine is built on Medusa v2, which is a good fit for most of what a clinic storefront does — a catalogue, carts, orders, fulfilment — right up until it is not.

A prescription is not a product. It requires an authorised prescriber, it cannot be freely reordered, it expires, and it carries a clinical audit trail no cart abstraction provides. Every one of those is a place where the obvious e-commerce behaviour is the wrong behaviour: an "add to cart" that would let anyone buy, a "buy again" that would bypass the prescriber, a quantity field with no notion of an interval.

The work is largely in deciding where the commerce model still holds and where it has to be constrained — keeping the parts that genuinely are a storefront, and refusing the defaults everywhere a script is involved.