projects/

Addison

Personal product · Ongoing

Practice management for clinicians in New Zealand and Australia, built around the one part of a solo practice that the practitioner cannot cover: their own absence.

Where it sat

Addison is practice management for clinicians in New Zealand and Australia. It holds three things: the schedule, the funded work, and the contingency plan. Sessions arrive from a public booking link or from a referral partner and land in one calendar. Funded blocks of sessions or hours are tracked against whoever is paying, an ACC contract, an EAP provider, an insurer, an employer, or a client funding their own care, with completed and forecast income kept current as sessions complete. It is built against the New Zealand Privacy Act 2020 and the Health Information Privacy Code, and it is deliberately not a clinical notes system.

What made it hard

A solo clinician is the entire operational surface of their own practice. The schedule is in their head or on paper, what each funder has approved is in a spreadsheet they last counted on Tuesday, and if they are unwell tomorrow, the answer to what happens next exists nowhere outside them. That is not a missing feature in a calendar. It is a category of risk that calendars do not address, and it lands on the funder or the referral partner as a continuity obligation at exactly the moment nobody can reach the person who holds the information.

The call I made

I made contingency a first class object rather than a document. The plan is a short list of actions written once in plain language, each switched on deliberately: notify clients with sessions in the next fortnight using your own template, notify remaining active clients on day three, pause the booking links, redirect new enquiries, and check in if the account goes quiet for a set number of days. A nominated trusted contact can start it, and everything after that runs on its own. What I turned down was the obvious implementation, which is to make the trusted contact a restricted user of the practice system. The cost I accepted is a second permission model to build and maintain, one that does not inherit from the clinical one.

The subtle part

Activation authority and data access are completely separate, and keeping them separate is the reason the feature can exist at all. The trusted contact can start the plan and that is the entire extent of what they can do. There is no screen anywhere that shows them a client list, a note, or a session record, because the moment there is one, a clinician is being asked to hand a third party a window into health information in order to buy themselves continuity, and no reasonable practitioner takes that trade. The second half is the twenty four hour hold. When the plan is activated, nothing sends. The system tries to reach the practitioner first, the whole thing can be cancelled with one tap, and the plan can be rehearsed as a dry run that shows exactly who would be emailed and what they would receive without sending anything. A mid level engineer builds the activation path, tests that it fires, and ships it. But the failure that kills this feature is not that it failed to fire. It is that it fired when it should not have, and told a clinician's clients that they were unwell when they were on a plane. Everything expensive in this design exists to make the false positive survivable.

Where it ended up

Live at withaddison.com. Scheduling with month, week and day views, working hours with date overrides and timezone handling, and iCloud, Google and Outlook calendar sync so personal commitments block out availability. Allocations across any funder with completed and forecast income. The contingency plan with rehearsal and a printable emergency document. Client information is stored in New Zealand and Australia, encrypted at rest, and never used to train anything. One plan at NZ$29 a month per organisation, with the contingency planning included rather than sold as a tier.

Stack

  • Laravel
  • PHP

Links