We understand that trusting a platform with protected health information is not a small decision. This page explains exactly where your data goes, who can access it, what the AI sees, and what controls you have. No ambiguity.
Australian Data Sovereignty
PHI Redaction at API Layer
APP & HIPAA Aligned
Zero AI Training on Your Data
1. Data Sovereignty
Your client data is stored in Australia, processed in Australia, and never transferred offshore. This is not a setting you can accidentally change — it is an architectural constraint.
Where Your Data Lives
All clinical data — client records, assessment results, uploaded documents, generated reports, and audit logs — is stored exclusively in AWS Sydney (ap-southeast-2). This includes database storage, file storage, and backups. There is no configuration option that routes data outside Australia.
Backups are replicated within the same AWS region for redundancy. No backup or replica exists in any non-Australian data centre.
Key Guarantee
Your client data never leaves Australian jurisdiction. This applies to storage, processing, backups, and disaster recovery. We do not use CDNs or edge caches that would route PHI through international nodes.
2. What the AI Sees
This is the question that matters most. When ADMRL sends data to the AI for analysis, what exactly leaves your environment?
PHI Redaction at the API Layer
Before any data reaches the AI model, ADMRL applies a redaction layer that strips personally identifiable information from the clinical payload. Client names, dates of birth, addresses, Medicare numbers, and other identifying fields are replaced with tokenised placeholders. The AI analyses clinical data — scores, observations, patterns — without knowing who the client is.
When the AI response returns, ADMRL re-associates the analysis with the correct client record on your side. The AI never had access to the identifying information.
No Training, Minimal Retention
ADMRL uses contracted AI processing services under agreements that prohibit training on customer inputs and outputs. De‑identified clinical data is processed solely to generate your requested analysis.
Our AI processing providers are configured to minimize retention and may only store request/response data for the brief period required to fulfill the request.
Your Client Data
Names, DOB, scores, notes
Redaction Layer
PHI stripped, tokens applied
AI Analysis
De-identified clinical data only
3. Regulatory Compliance
ADMRL is built for the regulatory environment Australian psychologists operate in. These are not aspirational targets — they are current operational requirements.
Australian Privacy Principles (APPs)
Designed to align with the Privacy Act 1988 (Cth) and the 13 Australian Privacy Principles governing the collection, use, disclosure, and storage of personal and sensitive health information. We focus on the enhanced obligations for health service providers under APP 3 (collection), APP 6 (use and disclosure), and APP 11 (security).
HIPAA
Designed to support HIPAA‑aligned controls for electronic protected health information (ePHI), including privacy, security, and breach notification expectations. This matters for practitioners with international clients or cross‑border referrals.
AHPRA Professional Standards
Aligned with AHPRA and the Psychology Board of Australia's standards for professional practice, clinical record‑keeping, informed consent, and supervision requirements. Report outputs are designed to meet AHPRA documentation expectations for registered psychologists.
OAIC Compliance
We comply with all Office of the Australian Information Commissioner guidelines including the Notifiable Data Breaches scheme. In the event of an eligible data breach, we notify affected individuals and the OAIC within the legislated timeframe.
ISO 27001 Infrastructure
ADMRL is hosted on infrastructure that holds ISO 27001, SOC 2 Type II, and IRAP (Information Security Registered Assessors Program) certifications. Our hosting environment meets the Australian Government's Information Security controls for PROTECTED-level workloads.
4. Encryption & Access Controls
Defence in depth. Multiple layers of protection from network edge to database row.
Encryption
At rest: AES-256 encryption for all stored data including databases, file storage, and backups
In transit: TLS 1.3 for all data transmission between your browser, our servers, and third-party APIs
Database level: Field-level encryption for sensitive health identifiers, separate from application-level encryption
Access Controls
AHPRA verification: All practitioner accounts require verified AHPRA registration before access is granted
Multi-factor authentication: Available for all accounts, enforced for enterprise
Role-based permissions: Granular access controls for multi-practitioner practices
Automatic session timeout: Configurable idle timeout with re-authentication required
Internal Staff Access to Data
Access to client data by ADMRL staff is strictly limited and governed by formal internal controls. Only a small number of authorised personnel can access production systems, and only where operationally necessary — for example, to investigate a reported technical fault or respond to a legal obligation.
Restricted by role: Internal access is granted based on job function. Staff do not have broad access to clinical data as a matter of course — permissions are scoped to what each role requires and no more.
Authorisation required: Any access to production data by ADMRL personnel requires documented justification and is subject to approval. Ad hoc or routine browsing of client records by staff is not permitted.
Fully logged and auditable: All internal access to production systems and data is recorded automatically. These logs capture who accessed what, when, and from where — and are retained for review, internal audit, or regulatory inspection.
Separation of duties: The people who build and maintain the platform are not the same people who can approve access to sensitive data. Controls are designed so that no single individual can access and act on clinical data without oversight.
These controls apply to all ADMRL personnel including developers, support staff, and company directors.
5. Audit Trails & Accountability
Every action in ADMRL is logged. Not as a feature — as a professional obligation. Complete transparency for clinical governance, peer review, and regulatory accountability.
What Is Logged
Clinical actions: Every document upload, assessment creation, score entry, test selection, and report generation — timestamped and attributed to the logged-in practitioner
AI interactions: Complete record of every AI request and response, including the exact prompt sent (post-redaction) and the analysis returned. You can review exactly what the AI was asked and what it said
Internal staff access: Any access to production data or systems by ADMRL personnel is logged automatically — recording who accessed what, when, and for what stated purpose. These logs are separate from practitioner audit trails and are reviewed periodically as part of our internal governance process.
Modifications: All edits to assessments, reports, and client records are versioned. Previous versions are retained, not overwritten
Access events: Login attempts, session activity, data exports, and permission changes
Internal staff access: Any access to production data or systems by ADMRL personnel is logged automatically — recording who accessed what, when, and for what stated purpose. These logs are separate from practitioner audit trails and are reviewed periodically as part of our internal governance process.
Retention: Audit logs are retained for 7 years, consistent with Australian healthcare record-keeping requirements
Export: Full audit trails are exportable in CSV and JSON for external compliance reporting, insurance audits, or legal proceedings
Why This Matters
If a report is ever questioned — by a client, a colleague, a board, or a court — you can produce a complete, timestamped record of every step: what data was entered, what the AI produced, what you changed, and what was finalised. The audit trail is your professional protection.
6. AI Governance & Clinical Authority
AI in clinical practice raises legitimate questions about professional responsibility. Here is how ADMRL addresses them.
You Are Always the Clinician
AI-generated content in ADMRL is always presented as a draft for your review. No report is finalised, no diagnosis is assigned, and no recommendation is made without explicit clinician approval. The registered psychologist retains full professional authority and responsibility for all clinical decisions.
Transparent AI Reasoning
When Alix provides clinical analysis in Supervisor mode, you can ask it to explain its reasoning. The AI interaction log shows exactly what was sent and returned. There is no opaque black box — every AI contribution is visible, reviewable, and auditable.
Clinical Documentation Standards
All reports generated by ADMRL meet the documentation standards expected by Australian regulatory and funding bodies:
DSM-5-TR and ICD-11 diagnostic coding and criteria referencing
Medicare billing and documentation requirements for psychological services
NDIS functional assessment and evidence requirements
Forensic reporting standards for court and tribunal submissions
AHPRA professional record-keeping obligations
7. Data Handling & Your Rights
You control your data. Here is exactly how it is collected, used, and — if you choose — deleted.
What We Collect and Why
Practitioner credentials (AHPRA number, contact details) — to verify your registration and maintain your account
Clinical data you upload (referral documents, test scores, notes) — to generate assessments and reports as you direct
AI-generated analysis — stored against your client records for audit and continuity purposes
Platform usage data — anonymised analytics to maintain and improve system performance
What We Do Not Do
We do not sell your data to anyone
We do not use your clinical data for marketing
We do not share data with advertisers
We do not use your data to train AI models
We do not access your client records without your explicit instruction — and where internal access is required for operational or legal reasons, it is restricted, documented, and audited
Deletion & Portability
Data export: Export all your client data at any time in standard formats
Account deletion: Request complete account and data deletion, honoured within 30 days
Legal holds: Deletion requests are subject to any active legal retention requirements
No lock-in: Your clinical data is yours — we will never hold it hostage
Third-Party Data Sharing
Clinical data is shared only with the following parties, and only for the stated purposes:
AI processing provider: De‑identified clinical data only, for AI processing. Contractually prohibited from training on inputs; minimal retention solely to process requests
Cloud infrastructure provider: Encrypted data stored in certified Australian data centres. The infrastructure provider does not access your data — they provide the physical and virtual hosting environment on which ADMRL operates
Clinical data backend: Clinical data is structured in a standardised health records format. Hosted on Australian infrastructure
Law enforcement or regulatory bodies: Only when compelled by valid Australian legal process (subpoena, court order). You will be notified unless legally prohibited
Questions About Our Security Practices?
We are happy to discuss any aspect of our data handling, compliance posture, or security architecture in detail.