Is Heidi (or Any AI Scribe) Privacy Act Compliant in Australia?

The question every practice manager should be asking

AI medical scribes — Heidi Health, Lyrebird Health, and a growing field of competitors — have moved from novelty to near-default in Australian general practice and allied health in the space of about two years. The pitch is simple: the tool listens to (or transcribes) a consult and drafts a clinical note, saving the clinician minutes per patient that used to go into typing.

The question we get asked most often by practices considering one of these tools isn't "which one works better" — it's "is this actually compliant with the Privacy Act?" It's the right question, and it doesn't have a one-line answer, because "compliant" isn't a checkbox any vendor can tick on your behalf. Compliance sits with the practice as the entity handling patient health information, not with the software vendor.

This piece lays out the actual regulatory surface — APP 8 cross-border disclosure, data residency, TGA's treatment of software-as-a-medical-device, and the RACGP's public position — and gives you a checklist to run against Heidi, Lyrebird, or any other scribe you're evaluating. We're vendor-neutral: we don't sell scribes, and we hedge anything that isn't publicly confirmed by the vendors themselves. If you want a deeper structural comparison of two of the market leaders, see our Heidi vs Lyrebird head-to-head.

Start with what an AI scribe actually does

Functionally, most ambient AI scribes follow a similar pipeline:

1. Audio capture during (or sometimes after) the consult, with patient consent.
2. Transcription, usually via a cloud-hosted speech-to-text model.
3. Summarisation and structuring into a clinical note format (SOAP or similar), usually via a large language model.
4. Clinician review and edit before the note enters the patient record.

Every step in that pipeline after step 1 typically involves sending audio or transcript data to a third-party processing service — which is where most of the actual Privacy Act questions live. The clinician-review step at the end (step 4) matters too, but it doesn't retroactively fix a data-handling problem upstream; the disclosure has already happened by the time the clinician reviews the draft.

APP 8: the cross-border disclosure obligation

Australian Privacy Principle 8 governs cross-border disclosure of personal information — and health information is "sensitive information" under the Privacy Act 1988, which attracts a stricter standard than ordinary personal information.

In plain terms: if a scribe (or its subprocessors — the cloud speech-to-text or LLM provider it uses under the hood) sends patient audio or transcripts to a server located outside Australia, that's a cross-border disclosure, and APP 8 requires the disclosing entity (your practice, as the entity that collected the information, and functionally the vendor as your service provider) to take reasonable steps to ensure the overseas recipient doesn't breach the Australian Privacy Principles — unless a specific exception applies (for example, informed patient consent to the overseas disclosure, or the overseas recipient being subject to a substantially similar privacy law with enforcement mechanisms).

This is not a hypothetical concern for AI scribes specifically. Many general-purpose transcription and LLM APIs are hosted in US regions by default, and a scribe vendor's use of them — even if the product is Australian-founded — can create an cross-border data flow that needs to be accounted for. The fact that a company is headquartered in Melbourne says nothing on its own about where the underlying processing actually happens; you have to check the vendor's specific documentation, not just its physical address.

What to actually check, per vendor, before you sign:

• Where is audio processed and stored — specific region, not just "cloud"?
• Which third-party subprocessors (speech-to-text provider, LLM provider) are in the pipeline, and where are they hosted?
• Does the vendor's privacy policy make an explicit APP 8 representation, or does it lean on a US-centric framework (HIPAA) as a substitute? (It isn't a substitute — HIPAA and the Australian Privacy Act are different regimes with different tests.)
• Is there a data processing agreement you can review, not just a public trust page?

We'd note here explicitly: as of the time of writing, we have not independently verified the current hosting architecture of Heidi Health or Lyrebird Health beyond what each publishes on its own public privacy/trust pages, and those pages can change. Verify directly with each vendor's current documentation before relying on any third-party summary — including this one — for a compliance file.

Data residency isn't the same as compliance

A practice can get data residency right (audio processed entirely within Australia) and still fall short on other Privacy Act obligations — consent language that doesn't clearly disclose AI processing, retention periods that aren't documented, or a lack of a clear process for patients to request access to or correction of the AI-drafted note.

Conversely, a vendor that does process some data offshore isn't automatically non-compliant — APP 8 has exceptions, and a well-drafted DPA plus informed consent can bring an offshore-processing arrangement within the Act. The point is that "is my data offshore" is a necessary question but not a sufficient one. A full Privacy Act assessment for an AI scribe deployment covers collection notices, purpose limitation, security safeguards (APP 11), retention and destruction, and the cross-border question together — not any single one in isolation.

TGA and the "is this a medical device" question

The Therapeutic Goods Administration regulates software that meets the definition of a medical device — including a category often referred to as Software as a Medical Device (SaMD) — where the software's intended purpose includes diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease. TGA has published specific guidance addressing clinical decision support software and where it does or doesn't fall inside the regulatory framework, generally turning on whether the software provides a recommendation that could directly influence a clinical decision without meaningful clinician judgement in between, versus tools that simply organise or transcribe information for a clinician who remains the decision-maker.

Most AI scribes, as publicly marketed, are positioned as documentation tools — they draft a note from a consult; they don't offer a diagnosis or treatment recommendation, and the clinician reviews and edits every note before it's finalised. On the face of current public positioning, that framing keeps most scribe products outside the SaMD register in the way a diagnostic algorithm would sit inside it. But this is exactly the kind of classification question that shifts as vendors add features — clinical coding suggestions, differential diagnosis prompts, risk flagging — that start to look more like decision support than pure documentation.

Practical takeaway: don't assume a scribe's current "just a documentation tool" framing is permanent or automatically true of every feature the vendor ships. If a vendor adds a feature that suggests codes, flags a possible diagnosis, or recommends a next clinical step, ask directly whether that feature has been assessed against TGA's SaMD guidance — and treat that as your practice's own diligence question, not something to take on faith from a product changelog.

Where the RACGP sits

The Royal Australian College of General Practitioners has engaged publicly with the rise of AI scribes in general practice, generally landing on a position that echoes the framework above: these tools can genuinely reduce documentation burden, but practices need to do their own due diligence on privacy, security, and clinical governance rather than treating vendor marketing as a compliance sign-off — and clinicians remain responsible for the accuracy and completeness of anything that enters the patient record, regardless of how it was drafted. We'd encourage checking the RACGP's current published guidance directly, since positions and specific recommendations evolve as the technology and regulatory environment move.

A checklist: evaluating any AI scribe for Privacy Act fit

Use this against Heidi, Lyrebird, i-Scribe, or any other scribe on your shortlist — vendor-neutral, applies equally to all of them:

1. Data flow map. Get, in writing, exactly which systems (including subprocessors) touch patient audio, transcript, and the drafted note, and where each is hosted geographically.
2. APP 8 representation. Does the vendor's documentation make a specific, current representation about cross-border disclosure handling — not just a general "we take privacy seriously" statement?
3. Consent language. Does your patient-facing consent notice specifically disclose that an AI tool will process the consult recording, and does it name (or accurately describe) the processing chain?
4. Retention and destruction. How long is raw audio retained, who can access it, and can you get audio deleted on request while retaining the finalised clinical note?
5. Security safeguards (APP 11). Encryption in transit and at rest, access controls, and breach notification process — ask for the vendor's current documentation, not a sales deck summary.
6. TGA/SaMD posture. Confirm the vendor's current classification position and ask specifically whether any feature (coding suggestions, risk flags) might change that classification.
7. Clinician review workflow. Confirm the product genuinely requires clinician sign-off before a note enters the record — and that your own practice workflow enforces that step rather than treating AI drafts as final.
8. DPA, not just a trust page. Get an actual data processing agreement you can put in a compliance file, reviewed against your practice's specific state and Commonwealth obligations.
9. Re-check periodically. Vendor architecture, subprocessors and hosting regions change. A compliance assessment done at signup should be revisited at renewal, not treated as permanent.

None of the above is a reason to avoid AI scribes — for many practices, the documentation-time savings are real and the underlying risk is manageable with the right diligence. It's a reason to do the diligence yourself, in writing, rather than accepting a vendor's marketing page as your compliance file.

Where this fits alongside voice AI

Cadence's core focus is AI voice agents for ANZ healthcare networks — phone-answering and triage tools evaluated against our CAPR framework, which covers Compliance, Accuracy, Performance and Reliability for call-handling specifically. AI scribes are a genuinely different category solving a different problem (in-consult documentation, not phone calls), and we don't force them onto the same rubric — see how we approach methodology generally at our diagnostic methodology page. If you're comparing two of the market's AU-founded scribes directly, our Heidi vs Lyrebird comparison walks through the same categories — data residency, PMS fit, privacy posture — in a head-to-head format.

Whichever scribe (or voice vendor) you're evaluating, the underlying discipline is the same: get the vendor's current claims in writing, map the actual data flow, and don't let a polished trust page substitute for your practice's own Privacy Act and TGA assessment.

This article reflects publicly available information as of the time of writing and is provided for general informational purposes, not legal advice. Privacy Act and TGA guidance evolve; verify current requirements and vendor-specific representations directly before making a procurement decision.