Information Management & Security Policy

Effective: 22 June 2026 · Last reviewed: 22 June 2026

Indicator Pro is an AI-assisted platform that helps Australian aged-care providers analyse de-identified clinical progress notes to produce quality-indicator dashboards and board-pack reports. The information that flows through the Service includes health information about care recipients, which is among the most sensitive personal information under Australian law. This policy describes how Boucher Advisory Group Pty Ltd (ABN 36 685 315 477), which operates Indicator Pro, manages and secures that information, and how those practices align to the standards expected of aged-care information systems in Australia.

1. Purpose & scope

This policy sets out the controls we apply to the collection, storage, processing, transmission, retention and disposal of information held in Indicator Pro. It applies to:

  • all care-recipient health information uploaded to the Service by provider staff (progress notes and the classifications derived from them);
  • provider-staff account information (names, work email, role, authentication identifiers and activity logs);
  • the systems, sub-processors and operational practices used to run the Service.

It is written to be read alongside our Privacy Policy, which covers individuals’ rights and our obligations under the Privacy Act 1988 (Cth) in more detail.

2. Governance & accountability

We process care-recipient information on the provider’s behalf as a service provider. The provider remains the entity with primary responsibility for that information under the Privacy Act; our role is to handle it securely once it reaches us, under the terms of a Data Processing Agreement with each customer.

  • A nominated Privacy Officer (Jordy Fung) is accountable for information-management practices and is the point of contact for privacy and data-access requests — see the Privacy Policy(§ 13).
  • A sub-processor register is maintained and reviewed whenever a sub-processor is added or changed (see § 9).
  • Changes to the Service are security-reviewed before release, with a focus on authentication, authorisation and tenant isolation.
  • We do not buy or rent personal information from third parties, and we do not use care-recipient information to train AI models.
  • Classifications are generated by AI and are designed to be reviewed and corrected by a registered nurse. No decision that significantly affects an individual is made solely by automated means — see the Privacy Policy(§ 4.4) for detail.

3. Data classification

We classify information so that the strongest controls are applied to the most sensitive data.

ClassificationExamplesHandling
Health / sensitive informationProgress-note text, care-recipient identifiers, outcome / action / comment fields, care-event dates, AI-derived classificationsTreated as “sensitive information” under s.6 of the Privacy Act. Stored only in Australia; de-identified before AI processing; excluded from logs.
Account / staff informationStaff name, work email, role, authentication identifiers, activity logsAccess-controlled and tenant-scoped. Authentication identifiers are managed by our identity provider.
Operational metadataInternal record IDs, batch metadata, status flagsNon-identifying. The only data permitted to cross to overseas workflow infrastructure.
PublicMarketing-site content, this policyNo restrictions.

We do notcollect care-recipient financial information, government identifiers (Medicare, tax file numbers), or location / biometric data. Where government identifiers appear in note text, they are redacted before any note is sent to an AI processor (see § 7).

4. Access control & tenant isolation

Each provider organisation’s data is logically separated from every other tenant’s, and access is granted on a least-privilege basis.

  • Authentication everywhere: every route except the public marketing pages requires an authenticated session. We do not roll our own authentication; we use a dedicated identity provider.
  • Multi-factor authentication: access to production data requires authenticated single sign-on plus multi-factor authentication, and is limited to the small number of authorised operators.
  • Tenant isolation:each provider organisation can access only its own data. A provider’s read-only viewer is constrained to that provider’s own records and cannot read another provider’s data.
  • Append-only clinical records: classification records are never overwritten — corrections create new records, preserving a full, auditable history of every change.

5. Encryption

  • In transit: all data is encrypted in transit using TLS 1.2 or higher.
  • At rest: all data is encrypted at rest using AES-256 with cloud-provider-managed keys.
  • Backups: database backups are encrypted at rest and retained for 7 days.
  • Credentials: credentials are held in an encrypted secrets store, never in source code.

6. Australian data residency & cross-border handling

All progress-note text and care-recipient health information is processed within Australia. Specifically:

  • Progress notes and classifications are stored in the Sydney region (ap-southeast-2).
  • AI inference runs on the AWS Bedrock au.* Australia-only inference profile, keeping inference traffic within Australia.
  • Application functions execute in the hosting provider’s Sydney runtime (syd1).
  • Workflow-orchestration metadata sent to overseas infrastructure contains internal record IDs only — never note content.

Cross-border handling (APP 8). Provider-staff authentication identifiers are held by a sub-processor in the United States; this is disclosed in our customer agreements, and staff consent to that overseas storage of their own account information under APP 8.2(b). Care-recipient health information is never sent to those services. If a sub-processor adds an Australian region, we will migrate as part of our normal vendor review.

7. De-identification before AI processing

Before any progress-note text is sent to an AI processor, an automated de-identification pass replaces personal identifiers with placeholders (such as [CLIENT], [PHONE], [EMAIL]) so that the clinical content remains usable for analysis but the identifiers do not leave Australia. The pass targets:

  • the care recipient’s name, expanded to its honorific, surname, and common shortened or nickname forms;
  • any other care-recipient name from the same upload batch;
  • phone numbers (mobile, landline, +61 forms);
  • email addresses;
  • Medicare card numbers;
  • dates of birth;
  • street addresses with an Australian postcode.

As with any automated de-identification, this reduces rather than wholly eliminates the chance that an identifier remains in free text, which is why all note content stays within the secured Australian environment described in this policy.

8. Retention & disposal

We keep personal information only for as long as we need it, then delete or de-identify it — except where law requires retention (for example tax records or Aged Care Quality and Safety Commission audits).

CategoryRetention
Progress notes + classificationsFor the lifetime of the customer’s account; deleted within 30 days of contract termination.
Audit logs of AI calls7 years to support clinical-decision review. Hashed payloads only; no progress-note text.
Staff authentication identifiersLifetime of the user’s account; 30 days after deactivation.
Marketing-site analyticsUp to 26 months (Google Analytics 4 default), where website analytics are enabled.
Backups7 days, encrypted at rest.

9. Sub-processor management

We maintain a sub-processor register listing every third party that processes customer data, its purpose, its location, and whether it touches care-recipient health information. The list below is current as at 22 June 2026. Each sub-processor is bound by written contract to process data only for the purpose we engage them for, to apply security measures appropriate to the sensitivity, and to notify us of any security incident within 24 hours of discovery.

Sub-processorPurposeRegionHealth information?
Amazon Web ServicesAI inference (Bedrock), compute, storageSydney (ap-southeast-2)Yes — de-identified only
Anthropic (via AWS Bedrock)Claude AI model inferenceSydney via Bedrock au.* profileYes — de-identified only
SupabaseManaged Postgres databaseSydney (ap-southeast-2)Yes
VercelApplication hosting (functions in Sydney syd1)Sydney runtime; US build pipelineNo health information in build pipeline
ClerkAuthentication / user managementUnited StatesNo — staff identifiers only
InngestWorkflow orchestrationUnited StatesNo — only non-identifying record IDs cross the boundary
SentryError monitoringUnited StatesNo — note text redacted before logs ship

When a sub-processor is added or its role changes, we update the register and the privacy policy, notify customers under existing agreements, and bind the new sub-processor to the substantive obligations of our agreement template.

10. Incident response & breach notification

Indicator Pro operates under the Privacy Act 1988 (Cth) Notifiable Data Breaches scheme. If we suspect a breach likely to result in serious harm, we assess it within 30 days and, where the scheme requires it, notify the affected individuals and the Office of the Australian Information Commissioner (OAIC) as soon as practicable. Sub-processors are contractually required to notify us of any security incident within 24 hours of discovery, so that we can assess and respond within that window.

11. Audit logging

  • Every AI call is logged with hashes of the request and response, so any classification the AI produced about a record can be audited. These logs contain no progress-note text and are retained for 7 years.
  • Changes to clinical records — classification edits, batch lifecycle actions, and background job status transitions — are recorded in an audit log alongside the change.
  • Progress-note text, raw rows and AI reasoning are excluded from application logs by redaction, so they never enter our error-monitoring pipeline.
  • Error responses returned to clients are generic and never contain progress-note content.

12. Alignment to standards

This section maps our practices to the standards that govern aged-care information systems in Australia.

Australian Privacy Principles (APPs)

PrincipleHow we meet it
APP 1 — Open & transparent managementThis policy and our published Privacy Policy describe how information is handled, retained and secured.
APP 3 — Collection of sensitive informationProgress notes are classified as sensitive information; we rely on the provider’s consent and lawful basis (provision of a health service), warranted under the Data Processing Agreement.
APP 6 — Use & disclosureInformation is used only to categorise and analyse notes, authenticate staff, and operate the Service. It is not used for AI model training.
APP 8 — Cross-border disclosureHealth information stays in Australia; only staff account data is held overseas, with disclosure and consent (see § 6).
APP 11 — Security & retentionEncryption in transit and at rest, tenant isolation, defined retention periods, and disposal at end of retention.

Aged Care Act 1997 & Aged Care Quality Standards

Indicator Pro supports providers’ obligations to keep accurate, retrievable records and to report against the National Aged Care Quality Indicator Program. The platform keeps an auditable history of every AI-assisted categorisation and human correction (append-only classifications and audit logging), retains AI-call audit logs for 7 years to support clinical-decision review, and aligns its data model to the program’s indicator definitions and required data points. Compliance with the quality-indicator program is overseen by the Aged Care Quality and Safety Commission.

ISO/IEC 27001

We are working towards ISO/IEC 27001 certification. Indicator Pro is not yet ISO/IEC 27001 certified — certification is in progress. The controls described in this policy — access control and tenant isolation, encryption, sub-processor management, retention, audit logging and incident response — form the auditable control set we are building toward certification. We will update this page once certification is achieved.

13. Review of this policy

This policy is reviewed periodically and whenever a material change to our information-management practices occurs. The effective and last-reviewed dates appear at the top of this page.