Patient data security built for clinical practice.
ApolloScribe processes sensitive clinical information every day. No patient PII is ever sent to an AI model — anonymised before processing, re-injected only in the final document. Australian-hosted. Privacy by design.
PII to AI
Hosted
Access
How ApolloScribe uses AI without exposing patient identity
Every AI-assisted action in ApolloScribe passes through a strict anonymisation pipeline. Patient details are never part of the AI request — they are re-injected after the AI response is returned.
No patient PII is ever sent to an AI model. Not once.
When ApolloScribe generates a Patient Letter, Consult note, Clinical Snapshot, or risk assessment, the patient's name, date of birth, Medicare number, address, and contact details are stripped before any content leaves the clinical record.
The AI model processes only anonymised clinical content. Patient identifiers are re-injected from the original record into the final output — after the AI response is returned.
- PII fields stripped at the application layer before dispatch
- AI receives: clinical history, transcript, symptoms — never identity
- Re-injection uses the original record held within ApolloScribe
- Applies to all AI-assisted actions: letters, consults, snapshots, risk flags
Name · DOB · Medicare · Address · Phone
Identifiers stored in ApolloScribe — not forwarded
Clinical history · Symptoms · Transcript only
Draft letter · Risk flags · Consult note
Complete document — AI never saw the patient's name
Clinical data hosted in Australia. No exceptions.
Patient records, transcripts, documents, and clinical snapshots are stored within Australian-based infrastructure. Data does not transit offshore, is not processed in foreign jurisdictions, and is not subject to overseas data access regimes.
This supports practice obligations under the Australian Privacy Act 1988 and the Australian Privacy Principles.
- All persistent patient data stored within Australian jurisdiction
- Supports compliance with Australian Privacy Act 1988 and APPs
- Encrypted at rest and in transit — TLS 1.2+ enforced on all connections
- Backups retained within Australian infrastructure on a defined schedule
Role-based access controls with a complete audit trail.
Every user in ApolloScribe operates within a defined access scope. Clinicians access only records within their practice. Administrative staff can be granted limited scopes by the practice administrator. Every access event is logged.
Sessions expire automatically. Credentials are never stored in plaintext. The audit log is available to practice administrators at any time.
- Role-based access: clinician, admin, and practice owner tiers
- Scoped permissions — admin staff access only what they need
- Full audit log: who accessed which record and when
- Automatic session expiry; re-authentication required after inactivity
What underpins ApolloScribe security
A set of non-negotiable security principles applied across every part of the platform.
Zero PII to AI
No patient name, DOB, Medicare, address, or contact details ever reaches an external AI model. Anonymisation happens at the application layer before dispatch.
Australian data residency
All patient data stored in Australian-based infrastructure. No offshore transit, no foreign jurisdiction access, no data centre routing outside Australia.
Encryption everywhere
Data encrypted at rest using AES-256 and in transit over TLS 1.2+. Credentials are never stored in plaintext.
Full audit trail
Every record access, document generation, and authentication event is logged with user ID and timestamp. Available to practice owners on demand.
Role-based access
Clinicians, admin staff, and practice owners each operate within defined scopes. Access is least-privilege by default.
Privacy Act alignment
Designed to support practice obligations under the Australian Privacy Act 1988 and the Australian Privacy Principles.
Security & privacy FAQ
Does ApolloScribe send patient data to AI models?
No. ApolloScribe never sends personally identifiable information to any AI model. Before any clinical content is processed by AI, the system strips all identifying details — name, date of birth, Medicare number, address, and contact information. The anonymised clinical content is processed by AI, and patient identifiers are re-injected into the final generated document only after AI processing is complete.
Where is patient data stored?
ApolloScribe stores clinical data in Australian-based infrastructure. Data does not leave Australian jurisdiction. This supports compliance with the Australian Privacy Act 1988 and the Australian Privacy Principles (APPs).
How does the anonymisation pipeline work in detail?
When a clinical document or transcript is submitted for AI processing, ApolloScribe identifies and removes all PII fields — including patient name, date of birth, Medicare number, address, and contact details — before the content leaves the clinical record system. The anonymised content is sent to the AI model. The AI-generated result is returned and patient identifiers are then re-injected from the original record to produce the final clinical document. At no point during this pipeline does any AI model receive identifiable patient information.
What compliance frameworks does ApolloScribe align with?
ApolloScribe is designed to support compliance with the Australian Privacy Act 1988, the Australian Privacy Principles (APPs), and the My Health Records Act 2012. The platform is built for Australian clinical practice, with data sovereignty maintained within Australian infrastructure.
How is access to patient records controlled?
ApolloScribe enforces role-based access controls. Clinical staff access only records within their practice. Administrative staff can be granted limited access scopes by the practice administrator. All access events are logged. Sessions require authenticated credentials and expire automatically after a period of inactivity.
Questions about how ApolloScribe handles your data?
Talk to the team — a 30-minute walkthrough covers the full security architecture and answers any practice-specific compliance questions.
Book a demo