The patient card · the patient app · the clinic console

ClinicApp

One platform joining the clinical record to the commercial one, and finally reporting on both.

3clinics live
2,619patients under management
7,783prescriptions synced
123,835grams dispensed & measured

Representative figures, not a client’s actuals

The short version

One place for the patient, one place for the clinic

For the patient it is a card and an app. The card proves they are a legitimate patient. The app carries their prescription status, their orders, their bookings and a copy of the card, so a lost card is not a crisis.

For the clinic it is one console instead of five browser tabs. Patients, cards, orders, medicines, staff, reporting and the full audit trail, in one place, with the procedures attached to the screen you are standing on.

Underneath it joins two systems that never spoke to each other. Elixir holds the clinical record. GoHighLevel holds the commercial one. Neither is replaced. Each stays the authority on what it owns.

Three clinics run on it today, each with its own patients, own branding, own store and own reporting. None can see another's.

2,619patients under managementacross the three clinics
7,783prescriptions syncedevery line priced
4,475consultations mirroredbooked, attended, missed
123,835grams dispensedmeasured from the scripts
1,067patients live in the appsigning in and ordering
12written proceduresinside the console
01

How it is built

Two services, two systems of record

The app sits between the clinical system and the commercial one. It is the only thing either a patient or a staff member has to learn.

Elixir Practice management Patients · appointments Prescriptions · medicines CLINICAL RECORD GoHighLevel CRM & commerce Contacts · products · stock Invoices · payments · comms COMMERCE RECORD ClinicApp Two services on Fly.io, Sydney Patient app + clinic console Card issuing & verification Sync engine + reporting mirror POSTGRES · SUPABASE AP-SOUTHEAST-2 reads writes scripts raises invoices reads payments PatientPhone app + printed card Clinic teamConsole + handbook Anyone verifyingScans the QR, no login
Hosted in SydneyTwo Fly.io services and a Supabase Postgres database, all in ap-southeast-2. Patient data does not leave the region.
Nothing is replacedElixir stays the clinical record. GoHighLevel stays the commercial one. ClinicApp is the layer patients and staff actually touch.
One-way where it mattersClinical data flows out of Elixir. The only thing written back is a draft prescription, which a doctor still has to sign.
02

Where the data comes from

Every field has one owner

The most common question about this app. The answer is that nothing has two owners.

WhatLives inHow it reaches the app
Who is a patientGoHighLevelMirrored in. Staff never type a patient in from scratch.
Date of birth, NHIElixirClinical record. GoHighLevel does not hold these reliably.
PrescriptionsElixirSynced out continuously. 7,783 to date.
ConsultationsElixirAppointment history, refreshed hourly.
Shop products & pricesGoHighLevelThe store shelf is the GHL product list. Nothing is duplicated.
Stock levelsGoHighLevelSold out in GHL means invisible in the app. One place to manage.
Invoices & paymentsGoHighLevelEach order raises a real GHL invoice on the patient's contact.
Card & photoClinicAppThe one thing the app itself owns.
Which medicine a product isClinicAppDecided once by a person. See Products & medicines.
Reporting figuresClinicAppComputed from a nightly copy of Elixir. See Reporting.

If two systems disagree, the owner in this table wins. That rule is what stopped the app quietly inventing a third version of the truth.

03

The patient card

Proof, without oversharing

clinicname.clinicapp.co.nz/clinic-admin
What actually prints onto the card
What prints: only this ink goes onto the card. The dashed box marks the photo area and is not printed.

Every card carries a unique QR. Scanning it opens a verification page. No app, no login, nothing to install for whoever is checking.

What a scan shows: the patient's name, photo and that they are a current patient of the clinic. What it never shows: their NHI, their medicines, their dosage or their conditions.

A card can be reissued the moment one is lost. The old QR stops verifying immediately. That is the difference between a card and a printed letter.

Cards are generated automatically when a patient is onboarded. The clinic's only manual step is adding the photo and printing.

04

For the patient

Status first, everything else after

Patient home screen
Home: prescription status front and centre.
Scripts
Scripts: what they are on and when it expires.
Card in the app
Their card, live in the app.
Sign-in
Sign in once, then a PIN.

The first question every patient asks is "am I still covered?". It is the first thing on the screen, in plain words, with the expiry date, not buried in a document.

05

For the patient

Ordering, tied to a current prescription

The in-app shop
Only stocked, priced products appear.
Past orders
Past orders and anything outstanding.

A patient can only order if they hold a current prescription and the clinic has opened their shop access. Both conditions, every time.

Checkout raises a real invoice against their GoHighLevel contact: the same invoice the clinic would have raised by hand, with the same numbering.

The order does not become a prescription until it is paid. Card payments confirm in seconds; invoice payments wait until the payment is recorded. Nothing reaches the doctor unpaid.

Patient orders in the app Invoice raised in GoHighLevel Payment confirmed card or manual Draft script waiting in Elixir Doctor signs nothing is guessed
06

Getting it on a phone

No app store, no download

ClinicApp installs straight from the browser. There is nothing in the App Store or Play Store to find, no update to chase and no review process between us and a fix.

Patients are sent a link and a temporary password. They sign in and set their own password and a PIN. The app then offers to install itself.

The welcome text message a new patient receives
The message a patient receives: sign-in link, temporary password and what happens on first login.
iPhone
  1. Open the clinic link in Safari
  2. Tap Share at the bottom
  3. Tap Add to Home Screen
  4. The app appears with the clinic's own icon
Android
  1. Open the clinic link in Chrome
  2. Tap Install on the card the app shows
  3. Confirm the prompt
  4. The app appears in the app drawer

Once installed it runs full-screen with no browser bar. Patients treat it as a normal app and most never realise it was a web page.

07

For the clinic

The morning screen

clinicname.clinicapp.co.nz/clinic-admin
The clinic console overview

Six numbers, all live. They are chosen to answer one question: what needs doing today?

  • Cards to print: the daily job. Work it to zero.
  • Reviews overdue: last consult more than 12 weeks ago.
  • Scripts expiring soon: contact them before it lapses.
  • Orders this week: placed through the app, with the value.

Below the numbers is the live activity feed: sign-ins, orders, payments, prescriptions raised, cards scanned and failed sign-in attempts.

08

For the clinic

Everyone, in four states

clinicname.clinicapp.co.nz/clinic-admin
The patient list with its filters

Every patient sits in exactly one state and the badge on the row says the same thing the filter does.

  • Active: signed in and using the app.
  • Invited: sent their login and never signed in. Worth chasing.
  • Inactive: known to us from GoHighLevel, never contacted.
  • Disabled: switched off; cannot log in or verify a card.

Alongside those: review due, expiring soon and no current script, so the list doubles as the recall worklist.

Opening anyone shows their status, milestone dates, full activity history and every action available on them.

09

For the clinic

The print queue

clinicname.clinicapp.co.nz/clinic-admin
The card print queue
New cards are waiting; Printed is your history.
clinicname.clinicapp.co.nz/clinic-admin
Batch printing
Select several: print them and mark them printed in one go.

Cards are minted automatically. The clinic adds the photo, prints and marks them done. Single or batch, the console produces a print-ready file at card size, so what comes out of the printer needs no trimming by eye.

10

For the clinic

Orders and the shelf

clinicname.clinicapp.co.nz/clinic-admin
The store page
Orders and the live shelf patients see.
clinicname.clinicapp.co.nz/clinic-admin
Orders detail
Every order placed through the app.

The shelf is not a second product list. It is GoHighLevel's, read live. Price, stock and availability all come from there, so there is one place to manage stock and no chance of the two drifting apart.

11

Products & medicines

Decided once, right every time

clinicname.clinicapp.co.nz/clinic-admin
Mapping a product to a medicine
Each product: the medicine, the pack size and the directions that print.

A shop product is a trade name: "FLOWERMAN OMGO 10g Jar". A prescription needs an Elixir medicine, a supply quantity and directions. This page is where a person joins the two.

Set once. After that every order for that product raises a correct draft. A choice the team has confirmed is never overwritten by a later sync.

If a product has not been decided yet, the app writes no medicine code. The order still reaches the doctor, arriving as an unmatched line they resolve themselves. Nothing is ever guessed on a prescription.

182 products are mapped across the clinics today. Opening a new clinic copies a mapped catalogue across in one step rather than starting from a blank page.

12

Reporting

The report a clinic could not run before

Two systems, neither of which could answer "how is the clinic actually doing?"

The full reporting page
The whole page. Eighteen sections, thirteen charts, one screen.

Elixir has no reporting: it answers one patient at a time and pages appointments twenty to a row, so a live query across a year would take hours. GoHighLevel reports on commerce and knows nothing clinical.

So the app keeps its own copy. Every night it harvests appointments, prescriptions and every line and quantity into a reporting mirror, then computes the figures in SQL. The page says when it last looked, so nobody mistakes it for live.

The facts are stored raw and the metrics computed on top of them, so changing the definition of churn is a query change, not another year of harvesting.

10,032 prescription lines, every one priced — retired products priced by hand, once, and remembered.

Date, gender and age filters
Filter by date range, gender and age band. The filters run in SQL — not in the browser, where every total would look right and be wrong.
13

Reporting

Where the money actually comes from

The headline figures
Revenue split by stream
Daily revenue
Daily grams dispensed

Revenue is split three ways: product, measured line by line from the prescriptions; consultations, counted as attended appointments at the clinic's own initial and follow-up fees, which are editable on the page because Elixir bills consults outside its API; and courier. Daily revenue and daily grams sit side by side because the question is never just "how much did we take" — it is "how much did we move".

14

Reporting

Who comes back, and who quietly stops

Patient journey
Renewal outcome
Customer activity by recency
Average spend per cycle

Every patient is measured on their own clock, starting at their first purchase, not on the calendar. A cycle is 98 days — the same fourteen-week window the clinic uses clinically — so purchase behaviour and renewal behaviour are read on one ruler. A patient who reached a cycle and spent nothing counts as zero, not as missing: dropping them would turn this into "average spend among people who are still buying", which climbs reassuringly as a clinic loses its patients.

15

Reporting

What sells, and who is buying it

Top products by volume
Patient demographics
Script size distribution
Did-not-attend rate by weekday

The same filters apply to all of it. Ask what a 45-to-59 cohort buys, or which weekday loses the most appointments, and the whole page re-answers. Did-not-attend is counted only over appointments actually marked arrived or missed, so an unmarked diary does not flatter the number.

16

Reporting

What next year looks like

Twelve-month cohort forecast
Every input is editable. Change the bookings, the did-not-attend rate or any cycle’s spend and the twelve months recalculate.
Payback curve

The forecast does not start from a guess. Its default spend per cycle is what these clinics have actually achieved, and it subtracts a real acquisition cost for every patient booked, which is why the first two months are negative by design. Beside it, the page states how complete its own numbers are — because a figure whose coverage you cannot see is not a figure you can plan with.

17

Running more than one clinic

Three clinics, one platform, no bleed

The separation between clinics is the feature a group buys. It has to be real.

Each clinic gets its own subdomain, its own branding and card design, its own product catalogue, its own staff logins and its own reporting. Adding one is configuration, not a new deployment.

Separation is enforced, not assumed. Reporting, patient lists, team management and support tickets are all scoped to the clinic making the request, and the rule fails closed: an unrecognised caller is shown nothing rather than everything.

There is no cross-clinic view, for anyone. The group-wide option was removed rather than hidden — a switch the interface no longer offers but the API still honours is not removed, only harder to find.

Clinics can share one practice-management account or hold their own; the platform routes to whichever each clinic uses, and a patient seen at two clinics stays one patient.

Clinic one1,006 patients · 4,169 scriptsfull stack: app, cards, store, reporting
Clinic two1,590 patients · 3,595 scripts1,602 contacts reconciled, zero duplicates
Clinic threeown practice accountonboarded with an 88-product catalogue copied across
Onboardingsubdomain, branding, catalogueno code, no separate deployment
18

Configuring the app

What the clinic controls

clinicname.clinicapp.co.nz/clinic-admin
Settings
Clinic details, branding, team and advanced options.
clinicname.clinicapp.co.nz/clinic-admin
Card template
The preview is the real renderer, not a mock-up.
GeneralName, contact details, subdomain, referral text, booking calendar.
BrandingColours and logos. The patient app and the card follow them.
Card templateLayout and what prints, previewed with the real renderer.
MedicinesThe product-to-medicine decisions and the sync.
TeamInvite staff, reset a password, remove a leaver. Managers only.
StoreTurn ordering on or off for the whole clinic.
19

The procedures

The handbook is inside the app

clinicname.clinicapp.co.nz/clinic-admin
The support page with every procedure

Twelve written procedures, reachable from the screen you are standing on. One document, one click per procedure. It prints cleanly if you would rather have it on paper.

  1. Onboarding a new patient
  2. Patient cards, start to finish
  3. Printing cards
  4. Reissuing & revoking a card
  5. Prescriptions & shop access
  6. Orders & payments
  7. Repeat requests
  8. Editing & disabling patients
  9. Managing staff logins
  10. Setting up your card design
  11. Raising a support ticket
  12. Products & medicines

The handbook is checked against the app on every release. If a procedure no longer matches the screen, the release does not ship.

20

Getting help

Raising a ticket

clinicname.clinicapp.co.nz/clinic-admin
The Get help tab
Support → Get help. Goes straight to the platform team.

Support → Get help, pick a category, write it, send. You get a ticket reference back immediately and the clinic can see all of its own tickets.

  • QuestionHow do I…?
  • Something is wrongIt isn't behaving as the handbook says
  • RequestA change, or something new
  • UrgentPatients affected right now

If it is urgent and patients are affected right now, phone as well. Do not wait on a reply to a ticket.

Check the handbook first for a "how do I". The answer is usually already written and you will have it faster.

21

How it stays up

Nothing ships that has not been run

What a clinic is actually trusting when it puts its day on one system.

Correct in principle is not the same as proven in production. So no release is trusted on the strength of the code alone. It has to prove itself against the real thing first.

Before any deploy, a set of smoke tests exercises the live paths against production services: create a patient, render their card, load the shop, check every product resolves to a medicine, confirm the handbook still matches the app.

Eleven checks, and the deploy is blocked if any of them fail. A clinic runs its day on this; a release that has never been run is not a release.

  • Every action is attributable. Sign-ins, card scans, edits, orders, payments and failed sign-in attempts, all recorded against a person and a time.
  • Data stays in the region. Both services and the database run in Sydney.
  • A dead integration cannot lose data. Sync failures are recorded per patient and replayed by reconciling against the source, never by blindly re-running the queue, which is how you get duplicates.
  • Payments are reconciled, not trusted. A charge that arrives without its invoice is matched back to it and flagged if it cannot be, rather than silently dropped.
  • Failures are visible. Unresolved sync errors are surfaced in the console instead of waiting for someone to notice a missing patient.
22

The economics

Two hours of admin per patient, and 37% more who stay

What the software is worth before anyone talks about software.

40 minsaved onboarding a patientwork the software does instead
20 minsaved per 12-week cycleevery cycle, every patient
$100per patient in year onetwo hours at $50 an hour
+37%past the first cycleearly estimate, clinics running it now
PATIENTS ON THE BOOK ADMINISTRATORS' WORK ABSORBED IN YEAR ONE AT $50 AN HOUR 500 patients 1,000 hours $50,000 1,000 patients 2,000 hours $100,000 2,500 patients 5,000 hours $250,000 5,000 patients 10,000 hours $500,000
PAST THE FIRST 12-WEEK CYCLE Before 100 With ClinicApp 137 An index, not a rate: 37% more of them carry on.

Both ends of the same equation. Less administration lowers what a patient costs to take on. Better retention raises what they are worth once taken on. The forecast earlier in this deck moves on both.

At a thousand patients the saving is 2,000 hours a year, which is one full-time administrator, and it is not a redundancy: it is the same team carrying several times the book without the wheels coming off.

How this is worked out. 40 minutes saved once at onboarding and 20 per patient per 12-week cycle, four cycles a year, at $50 an hour: 2 hours and $100 per patient in year one, 1 hour 20 and $66 every year after. One administrator is taken as 2,000 working hours. Retention is an early estimate, given as an index so it claims no baseline rate we have not measured.

23

The value

What it is actually worth

To the patient

  • Proof they can carry. A card that can be checked in seconds and a copy in their pocket if the printed one is lost.
  • A straight answer. Whether they are covered and until when, without phoning.
  • Ordering that cannot go wrong. They can only order against a current script.
  • Privacy by default. A scan proves legitimacy without exposing their conditions or medicines.

To the clinic

  • One screen, not five tabs. Patients, cards, orders, medicines, reporting and audit in one place.
  • Fewer phone calls. Status, orders and bookings answer themselves.
  • Prescriptions that are already right. Medicine, pack size and directions decided once.
  • The procedure is on the screen. New staff are productive without shadowing someone for a week.

To the business

  • Two hours of admin per patient, per year. $100 each at $50 an hour, and one full-time administrator's work absorbed at every thousand patients.
  • 37% more patients past their first cycle. Early estimate from clinics running it: lower cost to acquire, more cycles to earn from.
  • Figures nobody could get before. Revenue by stream, churn, payback and a twelve-month forecast, from records that were never reportable.
  • A full audit trail. Every action, every scan, every failed sign-in, attributable.
  • Revenue that does not leak. Orders are invoiced automatically and reconciled against payment.
24

In one line

The clinical record stays in Elixir. The commercial record stays in GoHighLevel. The patient, the clinic and the numbers only ever touch ClinicApp.

Running today3 clinics · 2,619 patients · 7,783 prescriptions · 10,032 priced lines · 18 reporting sections
Adding a clinicSubdomain, branding, catalogue and staff logins. Configuration, not a deployment.
QuestionsSupport → Get help, or ask now
25