Clinic management SaaS
One system for beauty and cosmetic clinics across several locations: bookings, patient records, practitioner consents, stock and reports, live in production.
- Role
- Full-stack engineer
- Status
- Live in production
- Client
- Beauty and cosmetic clinics
- React
- Node.js
- MongoDB
- AWS
- Twilio SMS
The problem
- Context
- Beauty and cosmetic clinic chains run several locations under one brand. Each location books treatments, keeps patient records and holds its own stock, while the chain sets the treatments, paperwork and products every location uses. The system includes a staff app and a public online-booking site over one API.
- Constraints
- Many cosmetic treatments use prescription-only injectables, so each treatment has to be tied to a prescribing practitioner's authority and the patient's consent, under Australian healthcare-identifier rules. Stock is regulated medicine that expires and can be recalled, and it moves between locations.
- What was at stake
- The system is live in clinics treating real patients. A missing or expired consent, or medicine used past its expiry, is a clinical and regulatory failure, and patient records are sensitive health data.
What I built
Multi-location model
Chain-level settings, location-level operations
Treatments, consent and medical-history templates, products and payment types are set once for the chain and shared by every location, while each location keeps its own hours, address and stock. A new location starts with the chain's paperwork.
Patients across locations
A patient can belong to several locations, with a credit balance and payment log, and every view of their record is logged with who opened it and when.
Stock control
Batches tracked to expiry
Stock is tracked per batch and location, with received and expiry dates, balance, and a status that can be in stock, out, expired or recalled.
A full trail for every unit
Every use, reversal, status change and transfer between locations is logged with the user, the patient and the booking, so any dose can be traced.
Expiry handled automatically
Scheduled jobs mark expired batches, consents and medical histories, so expired items stop being offered without anyone remembering to check.
Consent and prescribing
Practitioner consents tied to protocols
Each practitioner consent links the patient, location, prescribing practitioner, treatment protocol and script, with its own expiry date and signature, so treatment can only follow a valid authority.
Signed, expiring patient paperwork
Consent forms and medical histories are generated as signed PDFs from the chain's templates and expire on schedule.
Healthcare-identifier integration
Practitioners' national healthcare identifiers are verified through a signed SOAP integration with the Australian healthcare-identifier service.
Operations
Automatic reminders and follow-ups
Booking reminders and treatment follow-ups go out by SMS and email on schedule, with marketing opt-outs respected, and only one server instance sends them so nobody gets duplicates.
Reports and practitioner payouts
Reports export to CSV, and practitioner payouts can be exported as bank direct-entry files, guarded so the same day's file is never generated twice.
Roles that match clinic work
Nurses, dermal therapists and doctors each have their own roles, with administrator variants, rather than one generic staff role.
Tell me what you’re building and where it’s stuck.
I’ll tell you the cleanest path forward, including if it’s “don’t build that.”
Or write tocontact@alihassan.dev
