Privacy Policy

v1.2 · effective 28 June 2026

This policy explains how Clinically handles personal information when a medical practice uses our platform to capture a patient's electronic Assignment of Benefit (AoB) consent for a Medicare bulk-billed service. We handle personal information in accordance with the Australian Privacy Principles (APPs) under the Privacy Act 1988 (Cth).

For routine questions about your own information, your first port of call is the practice that sent you the link — under the APPs they are the entity that collected the information and Clinically processes it on their behalf.

1. Who we are

The platform is operated by CCMX PTY Limited t/a Clinically (ABN 24 693 129 056) ("Clinically", "we", "us"). We provide an electronic Assignment of Benefit consent tool to Australian medical practices. We do not provide medical advice and we are not a party to the doctor–patient relationship.

2. What we collect

We collect two categories of personal information:

Practice details — the registered practice name, administrator name and email, billing details, provider names and Medicare provider numbers, the services the practice configures, and practice branding (logo, colour, favicon).
Patient consent records — the patient's name, date of birth, the Medicare item or items being billed, the date of service, the servicing provider and their practice address, the patient's signature image, the moment the link was opened, the moment the patient signed, the source IP address, a browser identifier (user agent), and (when someone signs on the patient's behalf) the signer's name and their relationship to the patient.
Patient contact details (only where the practice has enabled patient communications) — the patient's mobile number and email address. These are supplied by the practice from its existing patient records and held so the practice can send the consent link by SMS or email and search its own patient directory. We use them only to deliver the practice's messages, never for marketing.

The patient's date of birth is entered by the patient on the consent screen — it is deliberately never carried in the SMS or email link. Where a practice sends the link from its own appointment or messaging system, we never receive the patient's mobile number. Where a practice instead enables Clinically's patient communications, we hold the patient's mobile number and email address so we can send the link on the practice's behalf — see "When your practice sends the link through Clinically" below.

3. Why we collect it

We collect this information so the practice can capture a Medicare-compliant electronic Assignment of Benefit and so the signed record can be retained as evidence of the patient's consent. This is the primary purpose under APP 6, and the regulatory basis is the bulk-bill assignment regime under the Health Insurance Act 1973 (Cth), as amended by the Health Insurance Amendment (Assignment of Medicare Benefits) Regulations 2025. We do not reuse the information for marketing or for any unrelated purpose. The patient is notified of the collection at the point it occurs — on the consent screen, before they sign — consistent with APP 5.

4. How we store and protect it

We take the following reasonable steps under APP 11 to protect personal information from misuse, loss, and unauthorised access:

Connections to the consent page are forced over a TLS-encrypted channel for at least one year, including all subdomains, so browsers refuse to fall back to plain text.
The patient consent page is marked non-cacheable and configured so its URL is never sent to any external site, so practice-side identifiers do not leak through browser cache or referrer headers.
Patient identifiers placed in the link sit in the part of the URL that browsers never transmit to any server, so they do not appear in our server-side logs.
Personal information is held in a secure encrypted database hosted on trusted cloud infrastructure, with role-scoped access controls.
Camera, microphone, and geolocation are disabled at the browser level for every page, and pages cannot be embedded in third-party frames or MIME-sniffed into a different content type.
Each practice's data is locked to its members at the storage layer, so staff from one practice cannot reach another practice's records, providers, services, or branding.
Only one administrator can be linked to a practice, so a single account cannot pivot across multiple practices' data.
Sign-in is passwordless via a one-tap email link, so there are no passwords to phish, leak, or reuse.
Public endpoints are throttled per source IP so an attacker cannot script-submit a flood of fake consents.
Each signed consent records the moment the link was opened, the moment the patient signed, a device fingerprint, and a cryptographic fingerprint of exactly what the patient was shown — so any later tampering with the stored record is detectable.
Practice-supplied branding is filtered on our servers before storage to block stored cross-site scripting via tampered images or links.

A summary of our security controls is published at /security.

Why a patient's name appears in the consent link

When a patient taps the link their practice sends, they will notice their first name and surname appear in the address bar of their browser. That is intentional and worth explaining in plain English.

What's happening

The link the practice's appointment system sends is a template. When the practice's system fills it in for the patient, it puts the patient's first name and surname into a special part of the link called the fragment — the part after the # symbol. The fragment lets the consent screen greet the patient by name and confirm what's being signed without us at Clinically having to know anything about that patient in advance.

What that means for us

By a long-standing technical rule of the web, the fragment is never sent to any server. The patient's browser keeps it locally and uses it only to display the page. So when the patient opens the link, Clinically's servers learn nothing about who they are — not their name, not their date of birth, not the appointment. We cannot even tell whether it was the patient or someone else who opened the link.

What that means for the patient

The trade-off is that anyone who can see the link itself — for example, someone holding the patient's phone, looking over their shoulder, or reading the SMS if it has been forwarded — would be able to read the patient's first name and surname in the address bar. The link does not carry the patient's date of birth, Medicare number, or any clinical detail. The patient still has to enter their date of birth on the consent screen before they can sign.

Why we designed it this way

The SMS the patient receives is sent by their practice's appointment system — a verified, healthcare-grade platform the practice already uses to send appointment reminders, with the patient's prior consent to contact them at that number. The message itself starts with the patient's first name in the body, just like every other reminder their practice sends. The link is part of that same SMS — so the patient's name in the link is no more exposed than the rest of the message: both sit on the patient's device, and the parts of the link that identify the patient do not travel to Clinically until they actively submit a signed consent. Until that moment, our servers know nothing about who opened the link.

What happens once the patient signs

When the patient taps "Sign and submit", their name, date of birth, the Medicare items being billed, the date of service, their signing time, their signature image, and a small device fingerprint are sent to our servers over a TLS-encrypted connection. They are then stored in our encrypted database, where they are accessible only to the practice's authorised staff. That stored record is what the practice — and, if asked, Services Australia — rely on as the evidence of the patient's consent.

When your practice sends the link through Clinically

A practice can send the consent link from its own appointment system, or it can enable Clinically's patient communications and have us send the SMS or email on its behalf. The section above describes the first case. When a practice uses our messaging instead:

We hold the patient's mobile number and email address that the practice has recorded, so we can address the message and so the practice can search its patient directory.
SMS is delivered by an Australian SMS aggregator and email by our transactional email provider — both listed at /sub-processors. The message carries a tokenised consent link and the practice's name; it does not carry the patient's date of birth, Medicare number, or any clinical detail, and the patient still enters their date of birth on the consent screen before they can sign.
These messages are transactional — sent to capture a Medicare consent the practice is already entitled to seek. The practice is responsible for having a lawful basis to contact the patient at that number or address. We do not use patient contact details for marketing.
The practice controls these contact details from its dashboard — it can edit or delete any patient, or clear its whole directory, at any time. A patient who wants their mobile number or email removed can ask the practice, or contact us at privacy@clinically.com.au. The contact details are held only to send the message and to let the practice find the patient again, and the link itself expires about seven days after it is sent.

5. Who can access it

A signed consent record is visible only to authorised members of the practice that captured it. Clinically support staff may access a record only on a strict need-to-know basis (for example, to diagnose a fault the practice has reported), and that access is audit-logged. We do not sell, rent, or trade personal information.

6. How long we keep it

Practices are required under Services Australia guidance to retain the completed Assignment of Benefit for at least two years from the date the claim is made. Clinically retains the signed record for at least that period so the practice can meet its retention obligation. Beyond the regulatory floor, retention and destruction settings are being formalised — please contact us at privacy@clinically.com.au for the current schedule or to request earlier deletion of practice-owned records.

Patient contact details and unsigned links. Where a practice enables patient communications, the patient's mobile number and email address are held only while they remain in the practice's patient directory. The practice controls those records directly — it can edit or delete any patient, or clear its entire directory, from its dashboard at any time, and all patient contact details are deleted when the practice closes its account. A consent link sent by SMS or email expires about seven days after it is issued; an unsigned link that expires captures no consent record. We do not retain patient contact details for any purpose beyond letting the practice send the consent message and find that patient again in its own directory, and we never use them for marketing.

7. Access and correction

Under APP 12 and APP 13, an individual may request access to, or correction of, their personal information. Because the practice is the entity that collected the information, please make routine access and correction requests to the practice directly — they can produce the signed record from their dashboard. If the practice is unable to assist, you may contact us at privacy@clinically.com.au. We do not charge a fee for making an access or correction request.

Under the bulk-bill assignment regime, a copy of the signed Assignment of Benefit is available on request — please ask the practice in the first instance.

8. Complaints

If you believe we have mishandled your personal information, write to privacy@clinically.com.au or Suite 2, 710 Hunter Street, Newcastle West NSW 2302. We will acknowledge your complaint and respond within a reasonable period. If you are not satisfied with our response, you may complain to the Office of the Australian Information Commissioner — see oaic.gov.au.

9. Data breach response

We comply with the Notifiable Data Breaches scheme under Part IIIC of the Privacy Act 1988 (Cth). If we become aware of a suspected eligible data breach affecting personal information we hold, we will assess it and, where the scheme requires, notify the Office of the Australian Information Commissioner and the individuals at likely risk of serious harm as soon as practicable. Practices using the platform will be notified within 72 hours of confirmation of an eligible data breach affecting their records.

10. Cross-border transfers

We host personal information on cloud infrastructure located in Australian regions and we design the service to keep personal information onshore. Some operational sub-processors we rely on (for example, transactional email delivery or document rendering services) may process information outside Australia. Where that is the case, we take reasonable steps under APP 8 to ensure the recipient handles the information consistently with the APPs. The current list of sub-processors and their processing locations is published at /sub-processors.

11. Changes to this policy

We may update this policy from time to time. Material changes will be communicated to practice administrators by email and reflected in the in-app onboarding flow. The version number and effective date at the top of this page indicate when the policy was last revised; prior versions are archived on request.

12. Contact

Privacy enquiries: privacy@clinically.com.au.
Postal address: Suite 2, 710 Hunter Street, Newcastle West NSW 2302.

Informational only — not legal advice. This policy describes how Clinically handles personal information; the practice that sent you the link is the APP entity that collected the information and is your first port of call for routine access or correction requests.