Events & Webhooks
Qliva is an event-driven platform. When a clinical event occurs — an appointment is booked, a note is signed, a prescription is issued — Qliva generates a structured event that can be delivered to approved partner systems in real time.
This enables integrations that react to what is happening in the clinic without polling, without manual data exports, and without lag.
Why events?
Clinical software has historically been siloed — data lives in one system and partners access it through batch exports or manual uploads. This creates delays, data inconsistencies, and administrative overhead.
An event-driven approach means:
- Labs know instantly when a result is received and processed
- Pharmacies know when a prescription is issued and can pre-stage dispensing
- Billing systems know when an invoice is paid without querying the database
- Wearable platforms know when a consult is completed and can push a relevant data summary
Events make the clinic's systems coherent and responsive.
Event categories
Qliva generates events across six clinical categories. Each event is associated with a specific clinical action and carries structured data about what occurred.
Appointment Events
Events that fire when appointments are created or change state.
| Event | Fires when |
|---|---|
appointment.created | A new appointment is booked (by practitioner or patient) |
appointment.rescheduled | An appointment is moved to a new time or date |
appointment.completed | An appointment is marked as completed |
appointment.cancelled | An appointment is cancelled |
appointment.no_show | An appointment is marked as no-show |
Clinical Record Events
Events that fire when clinical documentation is created or finalised.
| Event | Fires when |
|---|---|
note.signed | A practitioner signs a consult note |
treatment_plan.created | A new treatment plan is created for a patient |
Prescription Events
Events that fire throughout the prescribing lifecycle.
| Event | Fires when |
|---|---|
prescription.created | A new prescription is signed and issued |
prescription.erx_issued | An eRx token is generated via Parchment |
prescription.dispensed | A pharmacy confirms dispensing via Parchment |
prescription.cancelled | A prescription is cancelled before dispensing |
Pathology Events
Events that fire when pathology results arrive or are acted on.
| Event | Fires when |
|---|---|
pathology.result_received | A structured result is received from Medical Objects |
pathology.result_released | A practitioner releases results to the patient portal |
Billing Events
Events that fire across the invoice and membership lifecycle.
| Event | Fires when |
|---|---|
invoice.created | A new invoice is created |
invoice.paid | Full payment is received for an invoice |
invoice.payment_received | Any payment (partial or full) is recorded |
membership.activated | A patient membership becomes active |
membership.cancelled | A membership is cancelled |
Communication Events
Events that fire when patients interact with communications.
| Event | Fires when |
|---|---|
message.sent | A patient or practitioner sends a secure message |
form.completed | A patient submits a form assignment |
Event payload shape
All Qliva events follow a consistent envelope structure. The following illustrates the conceptual shape of an event — field names are illustrative:
{
"event_type": "appointment.completed",
"occurred_at": "2026-05-15T09:30:00Z",
"resource_type": "appointment",
"resource_id": "a1b2c3d4-...",
"tenant": "helixlongevity"
}| Field | Description |
|---|---|
event_type | The category and action, in dot notation |
occurred_at | ISO 8601 timestamp of when the event occurred (UTC) |
resource_type | The type of clinical resource this event relates to |
resource_id | The identifier of the specific resource |
tenant | The clinic identifier — used by partners to route events in multi-clinic deployments |
The field names and structure shown above are illustrative. Actual event schemas are documented during the technical onboarding process for approved partners.
Partner event delivery
Event delivery to partner systems is configured during the integration onboarding process. Partners specify:
- Which event categories they want to receive
- The endpoint(s) where Qliva should deliver events
- Authentication requirements for their endpoint
Qliva delivers events via HTTPS POST to the partner's endpoint. Partners acknowledge receipt with an HTTP 200 response. Failed deliveries are retried with exponential backoff.
Partner endpoints must respond within 10 seconds. Long-running processing should be handled asynchronously — receive the event, return 200 immediately, then process.
Getting started
To integrate with Qliva's event system, contact support@qliva.com.au with:
- Your company name and a brief description of your platform
- Which event categories you want to receive
- The clinical use case your integration addresses
Qliva's team will assess your use case, initiate a technical review, and — for approved partners — provide sandbox access and event delivery configuration.
Last updated 2026-05-15