Platform Overview#

This page describes Qliva's platform architecture from the perspective of an integration partner — what you need to understand about how Qliva is built in order to design an effective integration. It does not describe internal implementation details.

Multi-tenant architecture#

Qliva operates as a multi-tenant SaaS platform. Each clinic is a separate tenant — a fully isolated unit with its own:

• Subdomain ({clinic}.qliva.com.au)
• Patient records, clinical data, and billing history
• Configuration, integrations, and branding
• User accounts and access controls

All data access in Qliva is tenant-scoped. There is no cross-tenant data access — a practitioner at one clinic cannot see data from another clinic, and an integration partner cannot receive data for a tenant that has not configured and authorised that integration.

Australian data sovereignty#

All patient data processed and stored by Qliva resides exclusively in AWS ap-southeast-2 (Sydney, Australia). This includes:

• Patient records and clinical documentation
• Pathology results and clinical correspondence
• Prescriptions and medication data
• Wearable data and biometric information
• Communications and messaging

No patient data is transferred to infrastructure outside Australia. This is an architectural commitment, not a configuration option.

Built for Australian clinical compliance#

Qliva is designed from the ground up for Australian clinical regulatory requirements:

• Privacy Act 1988 — all data handling complies with the Australian Privacy Principles (APPs). Patient consent is explicit, data access is audited, and patients have rights over their information.
• AHPRA — practitioner identity and registration are verified at the platform level. Practitioner type determines clinical feature access.
• TGA awareness — features involving clinical decision support are designed to fall outside TGA Software as a Medical Device (SaMD) classification. AI features produce drafts for practitioner review — never autonomous clinical recommendations.
• Medicare and private health — billing infrastructure supports MBS item coding, Medicare Online claiming, and HICAPS private health fund integration.

Integration partners operating within the Qliva ecosystem are expected to maintain equivalent compliance standards.

Event-driven architecture#

Qliva is event-driven. Clinical events — appointments booked, notes signed, prescriptions issued, results received — flow through the platform as structured events. These events can trigger notifications to approved partner systems in real time.

This enables integrations that stay in sync with what is happening in the clinic without polling or manual data extraction. See Events & Webhooks for a description of event categories and patterns.

Authentication model#

Qliva uses two distinct authentication contexts:

Practitioner sessions — authenticated via email and magic link. Session tokens are short-lived and scoped to the practitioner's tenant. Practitioners can only access data for patients within their clinic.

Patient sessions — authenticated via magic link through the patient portal ({clinic}.qliva.com.au/portal). Patient sessions are scoped to the individual patient's record. Patients cannot access data for other patients.

Partner access — approved integrations receive dedicated credentials scoped to the specific data flows they are authorised for. There is no global API access — every integration is scoped to a specific tenant and data category.

Subdomain-per-tenant routing#

Every clinic has a unique subdomain. All requests are resolved to the correct tenant based on the subdomain before any data access occurs. This means:

• A partner integration for Clinic A cannot accidentally receive data intended for Clinic B
• Partner webhook endpoints must be configured per-tenant
• Event notifications include a tenant identifier so partners can route data correctly in multi-clinic deployments

What this means for partners#

When designing a Qliva integration:

1. Expect tenant isolation — your integration will be configured separately for each clinic that uses it. Design for multi-tenant operation from the start.
2. Expect event-driven data flow — Qliva pushes data to partners when events occur, rather than partners polling for changes.
3. Expect Australian infrastructure requirements — if your integration stores or processes patient data, it must do so within Australia.
4. Expect a compliance review — before going live, Qliva reviews data handling, authentication, and privacy practices for all integrations.