Skip to content
SAGE ConnectCare connected clearly
Talk to us →
← Back to the argument

Legal

Privacy policy

Australian Privacy Principles · Privacy Act 1988 (Cth) · Health Privacy Principles · Health Records Act 2001 (Vic)

In short

SAGE Connect is an RACF-centred clinical communication and assurance platform. The RACF organisation is the customer and payer; homes are sites. GPs, practices and permitted specialists participate as invited clinicians. Clinical concerns move through a closed-loop communication workflow. The existing RACF and clinician systems remain the primary clinical records. SAGE may hold limited identifiable health information required for that workflow. GP enduring AoB is a separate billing-evidence function; its absence does not prevent clinical review, and SAGE does not determine Medicare eligibility or claim validity. Specialist communication may occur, but specialist AoB and specialist claim-readiness are outside scope. Representative authority is decision-specific and is not inferred from family/NOK status.

The currently deployed synthetic-only environment still uses practice-level RLS with facility/object checks. The RACF-root tenancy remediation is the next release candidate and remains subject to migration, negative isolation testing and deployment verification.

The v1.1 review records core AWS services in Sydney. Identity, SMS, edge and website-enquiry suppliers are separate processing boundaries; their locations and contracts remain subject to verification.

Residents and their families do not have accounts with us and are not our users. Section 09 explains who to ask to see or correct information. Section 11 explains how to complain.

  1. 01Who we are

    SAGE Connect is operated by SAGE Connect Pty Ltd, ABN 78 699 224 176 · ACN 699 224 176, of 112/78 Doncaster Road, Balwyn North, Victoria 3104. Contact privacy@sageconnect.au about personal information.

    SAGE Connect is an RACF-centred clinical communication and assurance platform. The RACF organisation is the customer and payer; homes are sites. GPs, practices and permitted specialists participate as invited clinicians. Clinical concerns move through a closed-loop communication workflow. The existing RACF and clinician systems remain the primary clinical records. SAGE may hold limited identifiable health information required for that workflow. GP enduring AoB is a separate billing-evidence function; its absence does not prevent clinical review, and SAGE does not determine Medicare eligibility or claim validity. Specialist communication may occur, but specialist AoB and specialist claim-readiness are outside scope. Representative authority is decision-specific and is not inferred from family/NOK status.

    The RACF organisation directs its authorised workflow use. Participating clinicians remain responsible for their own clinical records and professional duties. SAGE processes information to provide and secure the service and has its own privacy obligations. Contractual allocations do not remove any party’s statutory duties.

    The currently deployed synthetic-only environment still uses practice-level RLS with facility/object checks. The RACF-root tenancy remediation is the next release candidate and remains subject to migration, negative isolation testing and deployment verification.

  2. 02What information we collect

    The clinical workflow may hold limited resident identifiers, date of birth, site and room, review reason, urgency entered by staff, messages, response, acknowledgement, follow-up and necessary attachments. These can be identifiable health information. Existing historical referral material must also be covered by access and retention controls.

    The separate GP enduring AoB function may hold relevant Medicare identifiers, GP/service scope, signer identity, relationship, decision-specific authority evidence, wording version, signature and timestamps. Family or next-of-kin status alone is not authority. Specialist AoB and claim-readiness are outside scope.

    Workforce information includes name, work email, role, RACF organisation, site and clinician associations, credentials, authentication metadata and access events. Operational information includes audit, security, support and provider-acceptance metadata. Website enquiries collect facility, role, current workflow and work email.

    Only information needed for the stated purpose should be entered. Internal identifiers do not make linked personal information anonymous. Current environments are restricted to synthetic information.

  3. 03How we collect it

    Information comes from authorised RACF staff and invited clinicians, and from residents or appropriately verified representatives for the separate GP assignment workflow. Workforce users and website enquirers provide their own details; suppliers return necessary service metadata.

    The relevant party must establish a lawful basis for collection and sharing and provide the applicable collection notice. Authority to make one decision must not be assumed to cover treatment, information sharing or Medicare assignment generally.

  4. 04Why we collect it, and how we use it

    The primary purpose is to communicate a clinical concern, route it to an authorised clinician, record a response and support care-team acknowledgement and follow-up. Relevant clinical content must be recorded in the existing RACF and clinician systems.

    GP enduring AoB is a separate evidence function. It does not determine Medicare eligibility, entitlement or claim validity, and its absence does not block, hide or delay clinical review. Specialist communication is permitted; specialist AoB and billing readiness are outside scope.

    Other purposes are account administration, access control, security, support, responding to business enquiries and meeting legal obligations. Resident health information is not used for advertising, sale or training AI models.

  5. 05Who we disclose it to

    Access is limited to authorised RACF and clinical participants according to organisation, site, role and assignment. A person’s membership of a practice or family does not create unrestricted resident access. RACF administration must not expose detailed GP assignment artefacts without a specific authorised purpose.

    Operational suppliers receive information required for their service. Optional family updates require a separately recorded recipient and communication preference; they are not bundled with GP AoB signing.

    Information may also be disclosed where required or authorised by law, or to professional advisers under appropriate confidentiality controls. See the Trust page for the reviewed supplier status and open evidence requirements.

  6. 06Whether information goes overseas

    The v1.1 review records core application, RDS, KMS, secrets, workload logs and backups in AWS Sydney. Global edge services and external suppliers are separate processing boundaries.

    Clerk receives workforce identity and account metadata. Kudosity receives destination numbers, SMS bodies and link metadata; production enablement and supplier due diligence remain pending. Google processes the separate website enquiry and email copies, potentially outside Australia.

    Supplier and subprocessor countries, retention, access and contractual safeguards must be confirmed before real resident data is enabled. This page does not claim that all processing stays in Australia. Stripe code is present but payments are disabled in the reviewed deployment.

  7. 07How we hold and protect it

    The currently deployed synthetic-only environment still uses practice-level RLS with facility/object checks. The RACF-root tenancy remediation is the next release candidate and remains subject to migration, negative isolation testing and deployment verification.

    The v1.1 review reports KMS-backed AES-256-GCM envelope encryption for selected profiles and artefacts, held as encrypted blobs in RDS, with infrastructure encryption for other operational fields. Authorised downloads leave the controlled service boundary.

    Clerk provides workforce identity. Enforcement of MFA, invitation lifecycle and deprovisioning remains an evidence requirement. Application audit entries are append-only for the runtime role; they are not an immutable or WORM record.

    The review records encrypted backups and point-in-time recovery, but a successful restore drill has not been evidenced. WAF was count-only and production app DNS unresolved. See the Trust page for the full open-gate position.

  8. 08How long we keep it, and deletion

    Retention must be approved by record class, purpose, applicable law and signed agreement. GP enduring evidence, clinical communication, authority records, audit, security logs, enquiries and backups require separate decisions. A blanket two-year disposal rule is not appropriate.

    Automated disposal coverage, legal holds and backup expiry must be tested. Candidate safeguards and source configuration do not establish a completed disposal programme.

    When information is no longer needed and no lawful retention requirement applies, destruction or de-identification must follow the approved schedule. Backup disposal follows its verified lifecycle. Access and deletion requests can be made to privacy@sageconnect.au.

  9. 09Access and correction

    Residents and appropriately authorised representatives can ask to access or correct information. Contact the RACF organisation first for its clinical-communication records, or the treating practice for its primary clinical and GP assignment evidence. SAGE will assist the responsible party and can be contacted at privacy@sageconnect.au.

    For account, enquiry, support or security records managed by SAGE, contact SAGE directly. Identity and authority for the specific request will be checked. We aim to respond within 30 days and explain any refusal and complaint route. Corrections may preserve a restricted audit history.

  10. 10Data breach notification

    We have a documented plan for responding to a data breach. If one occurs we contain it, assess what happened and who is affected, and act on that assessment.

    We take all reasonable steps to complete an eligible-data- breach assessment expeditiously and within the statutory assessment period. Where notification is required, the responsible entity notifies the OAIC and affected individuals as the Notifiable Data Breaches scheme requires.

    We coordinate with affected customers. Contractual customer-notification periods and responsibility are set by the signed agreement and applicable law.

  11. 11Complaints

    If you are unhappy with how we have handled personal information, tell us first.

    Email privacy@sageconnect.au, or write to our Privacy Officers at the address in section 01. We acknowledge complaints promptly and aim to provide a substantive response within 30 days.

    If you are not satisfied with our response, you can complain to the Office of the Australian Information Commissioner — oaic.gov.au, 1300 363 992, GPO Box 5218, Sydney NSW 2001.

    For Victorian health information, the Health Complaints Commissioner may also have jurisdiction. Another state or territory health privacy regulator may apply depending on where the information was handled.

  12. 12Changes to this policy

    This is version 1.2, updated 20 September 2026 for the approved RACF-centred model. It is a controlled review copy pending legal approval and publication. It does not alter signed agreements or represent approval for real-data use.

    Material changes to information handling must be assessed and communicated to affected organisations and individuals as appropriate. Earlier versions are retained as historical records.