The Trust

What SAGE Connect is, and is not

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.

Clinical decisions and emergency escalation remain with the treating clinicians and RACF care team. SAGE does not diagnose, determine urgency or make care conditional on billing evidence.

Your residents' information

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.

Verified Data Flow v1.1, reviewed 20 September 2026 against application commit 9fe9ce3, reports core AWS application, private RDS PostgreSQL, KMS, secrets, workload logs and backups in Sydney (ap-southeast-2). Global edge and external suppliers are separate; this is not an assurance that all information stays in Australia.

Resident profiles, GP assignment artefacts, attachments and retained referral material use AES-256-GCM envelope encryption, with wrapped data keys protected by KMS. Encrypted blobs are held in RDS. Other operational fields rely on encrypted storage and access controls. Authorised downloads create copies outside the service boundary.

Application audit records are append-only for the runtime role. Operational records can be corrected; neither the whole database nor application audit is WORM or cryptographically chained. AWS CloudTrail is a separate control-plane log.

When something goes wrong

The v1.1 evidence records RDS point-in-time recovery of 35 days for production and 7 days for staging, plus weekly encrypted logical backups to S3. Production is Single-AZ. Successful restoration and recovery timings have not been evidenced.

Production application DNS remained unresolved in the review. WAF rules were counting, not enforcing blocking. These are open release gates, not completed protections.

The RACF and clinicians must keep emergency and downtime procedures. Incident contacts, notification duties, restore tests and operational ownership must be agreed and exercised before real-data use.

Who else is involved

AWS provides core hosting, RDS, KMS, secrets, workload logging and backups. Cloudflare DNS and AWS CloudFront provide the reviewed application edge path; edge processing is global.

Clerk provides workforce sign-in and invitations. Staff identity and organisation/site metadata may leave Australia; resident profiles are not intentionally sent in identity claims. MFA enforcement, webhook verification and deprovisioning evidence remain open.

Kudosity is the selected SMS provider. It receives mobile numbers, message bodies and link metadata. Staging is configured; production secret seeding, SenderID registration and rollout remain pending in v1.1. Provider acceptance is not proof of handset delivery; no receipt callback was verified. Supplier countries, retention and contractual evidence remain required.

The separate website enquiry form sends facility name, role, current workflow and work email to Google Apps Script and Sheets, with email copies to nominated SAGE personnel. Google may process this outside Australia. Do not submit resident or clinical information. This website flow is additional to the app marketing pages reviewed in v1.1.

Stripe code is present in the application but its secrets were not injected into the reviewed AWS deployment. Self-onboarding and payments are disabled. No live practice-management-system integration was verified.

A completed supplier register, subprocessors, contracts and processing locations remain real-data launch requirements.

What we have proven, and what we have not

Current: synthetic-only environments and the dated v1.1 deployed evidence. Target: the RACF-root remediation candidate implementing the approved product scope. A source-code change is not proof that a control is deployed.

Evidence required: RACF migration and negative isolation tests; exact-commit staging verification; production DNS and rollback; WAF enforcement; restore drills and availability decisions; Clerk and MFA controls; supplier due diligence; production SMS and alarm tests; retention approval; PIA and independent penetration testing; operational sign-off.

Verified Data Flow v1.2 must be generated against the release commit actually deployed and tested. Until then, the new architecture is a candidate and the real-data hold remains in place.

Documents & requests

Request the product-scope decision, PIA v0.2 working assessment, Procurement v1.0 controlled review copy and the verified v1.1 baseline at security@sageconnect.au. Each has a different evidence status; none is a certification or a completed procurement approval.

Contract terms, insurance and service commitments require the signed agreement and current supporting evidence. Accessibility has not been independently audited. Contact hello@sageconnect.au for an accessible copy or to report an issue.

Report vulnerabilities to security@sageconnect.au without including resident information. Avoid disruptive testing. The machine-readable security contact is at /.well-known/security.txt.