HealthyHive: SaaS Clinic & Health Booking Platform
Multi-tenant practice isolation: each clinic operates as an independent tenant with its own settings, practitioners, and patient records

Background
HealthyHive needed a multi-tenant SaaS platform for clinics, from solo practitioners to multi-practitioner practices, covering the full patient journey from booking through to invoiced payment, with healthcare-grade data security. Serving both Australian and UK healthcare providers meant the schema had to hold up under two different regulatory regimes from day one, not be retrofitted for compliance later.
What We Built
A NestJS API with MongoDB covering:
- Practices
- multi-tenant onboarding with practice settings (timezone, invoice footer, branding)
- Practitioners
- profiles, schedules, and availability windows per practice
- Patients
- registration, medical history, and contact records
- Appointments
- booking with practitioner, time slot, and service; price snapshot captured at booking time
- Invoices
- generated from completed appointments with practice branding and line items
- Auth
- JWT with refresh token rotation; tokenHash indexed for O(1) lookup on every authenticated request; sensitive fields protected with select: false
Architecture
NestJS with Mongoose schemas and a carefully reviewed index strategy for query performance at scale. Multi-tenant scoping happens at the query layer with practiceId on every entity, so one clinic's data is structurally unreachable from another's session. Refresh token rotation uses a unique index on tokenHash to ensure idempotency, with a TTL index on expiresAt for automatic token cleanup.
Results
A single-tenant model would mix each clinic's settings and patient records
Full multi-tenant isolation, enforced at the query layer for every entity
Invoice prices could drift if a service's price changed after the appointment
Price snapshots at booking time keep every invoice accurate and audit-safe
Outcomes & Lessons Learned
- Multi-tenant practice isolation: each clinic operates as an independent tenant with its own settings, practitioners, and patient records
- Appointment booking with practitioner schedule management and availability windows
- Invoice generation with practice branding, price snapshots at time of appointment, and audit-safe immutable records
- Secure token management with hashed refresh tokens and TTL-based expiry
- Compliance-aware schema design with sensitive fields marked select: false and price snapshots on appointments
Healthcare SaaS requires treating schema design as a compliance artifact, not just a data model. Price snapshots on appointments (rather than live price lookups) ensure invoices remain accurate even when service pricing changes, which is both a regulatory requirement and a patient trust issue.
Questions, answered.
The things people ask us about this project. If yours isn't here, ask us directly, we reply like humans.
Ask us anything→How is one clinic's data kept separate from another's on a shared platform?
Multi-tenant isolation is enforced at the query layer: every entity carries a practiceId, so one clinic's data is structurally unreachable from another's session rather than relying on a permissions check that could be missed.
Why capture a price snapshot at booking time instead of just looking up the current price?
So invoices remain accurate even if a service's price changes after the appointment was booked; live price lookups would let an invoice drift from what the patient actually agreed to.
How does the platform handle sensitive patient and credential data?
Sensitive fields are marked select: false at the schema level so they're never accidentally returned by a query, and refresh tokens are stored hashed with TTL-based expiry for automatic cleanup.
Does the platform work for clinics in different countries with different regulations?
Yes, it serves both Australian and UK healthcare providers, which meant the schema had to satisfy two regulatory regimes, including GDPR and healthcare data handling requirements, from day one rather than being retrofitted later.
What does a practitioner or patient actually do in the system?
Practitioners manage their schedules and availability windows per practice, while patients book appointments against that availability; invoices are then generated from completed appointments with practice branding and line items.
Ready to craft tomorrow, today?
Where innovation meets execution, and ideas evolve into impactful solutions. Book a free consultation, no strings attached.