AI in Australian Healthcare Practices

The Sector at the Top of the Breach Table

In every recent OAIC Notifiable Data Breaches report, one sector keeps appearing at the top of the league table: health service providers. The OAIC's Notifiable Data Breaches Report: January to June 2024 placed health at the top with 102 notifications, ahead of finance, and the pattern has been consistent across reporting periods. Health records are sensitive information under the Privacy Act, the cost of a breach is high, and the public scrutiny is higher again.

Now layer AI on top of that base.

An Australian healthcare provider, whether a multi-site GP group, allied health network, specialist group, day surgery, diagnostic imaging chain, or aged care operator, never deploys plain "AI". What arrives is AI that touches sensitive health information, AI that may be a medical device under TGA rules, AI that supports decisions a registered practitioner is professionally accountable for under AHPRA, and AI that almost always sends data offshore for processing.

That is four regulators in one workflow. It is also the reason this is the second regulated industry article in our AI agents series, after financial services and APRA/ASIC. The earlier articles cover what any organisation needs to think about before, during, and after AI deployment. Three are particularly relevant here: why AI agents are not a DIY project without understanding, vendor selection questions for Australian buyers, and the 50-point AI security checklist.

This article maps the four-regulator stack for healthcare, identifies the four highest-risk AI deployments in a practice, and provides a decision tree and readiness checklist your Practice Manager or CIO can use this week.

Part 1: Where the TGA Line Actually Falls

The first question on any healthcare AI procurement should be: is this product a Software as a Medical Device (SaMD)? If it is, the Therapeutic Goods Administration regulates it, and you cannot simply roll it out because a vendor says it is "AI-powered" and "approved overseas".

Under the Therapeutic Goods Act 1989 and the Therapeutic Goods (Medical Devices) Regulations 2002, software is a medical device when it is intended for one or more of: diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease, injury, or disability. The TGA reformed its rules for SaMD in February 2021, and clinical decision support tools sit in a carved-out boundary zone with specific exemption criteria. The Australian Digital Health Agency and TGA have continued to publish guidance for AI-enabled medical devices through 2024 and 2025.

Classification runs from Class I (lowest risk) through Class IIa, Class IIb, and Class III (highest risk, life-supporting or life-sustaining). The higher the class, the more pre-market evidence and post-market surveillance is required, and the more likely the AI cannot lawfully be used in Australia until it is included in the Australian Register of Therapeutic Goods (ARTG).

This is the bright line that most procurement teams miss. A vendor brochure that says "FDA cleared in the US" or "CE marked in the EU" does not give you a pass in Australia. Inclusion in the ARTG is the relevant question.

The dangerous middle of this table is ambient scribing. A tool that simply transcribes a consultation verbatim is typically administrative. A tool that produces a "suggested clinical impression" or codes a diagnosis ICD-10 from listening to a consultation has likely crossed into SaMD territory and must be assessed accordingly. What decides the line is the clinical claim the software makes.

If you cannot determine on which side of the line a product sits, do not deploy it. Ask the vendor for their TGA position in writing, and check the ARTG yourself.

Part 2: AHPRA and Clinical Accountability

Even when a tool is lawfully on the market, the registered practitioner using it remains professionally accountable.

The Medical Board of Australia and AHPRA have been clear, in successive editions of the Good Medical Practice: A Code of Conduct for Doctors in Australia and in telehealth and digital health guidance, that introducing technology into a clinical encounter does not transfer responsibility for the clinical decision. The same logic applies across the National Boards for nursing and midwifery, psychology, pharmacy, dental, and allied health practitioners.

For AI specifically, this means:

• The practitioner is responsible for the clinical decision even when the AI made a recommendation
• The clinical record must set out the practitioner's reasoning alongside the AI output
• If the AI was wrong and the practitioner relied on it uncritically, the practitioner is still accountable to the regulator and the patient
• Documentation must be sufficient for retrospective audit by AHPRA, the practitioner's professional indemnity insurer, or in litigation

The Moffatt v Air Canada decision (2024 BCCRT 149) in British Columbia confirmed, in an entirely different context, that an organisation is liable for the representations made by its AI on its behalf. The principle that the deploying organisation owns the agent's outputs applies just as forcefully where the deploying organisation is a healthcare provider. We covered this principle in detail in the ACCC consumer guarantees article and again in the AI agent governance article.

For a practice, that means three concrete things. First, your clinical governance committee must sign off on AI tools before they are introduced into a clinical workflow, not just the IT or operations team. Second, your documentation standards have to be updated so that the clinical record makes clear what the AI suggested and what the practitioner decided. Third, your professional indemnity insurer needs to know what AI tools you are using, because they may have policy conditions, exclusions, or reporting obligations attached.

Part 3: Privacy Act and Sensitive Health Information

Health information is "sensitive information" under section 6 of the Privacy Act 1988. That triggers heightened obligations under the Australian Privacy Principles (APPs):

• APP 3 requires consent for the collection of sensitive information in most circumstances, and collection must be reasonably necessary
• APP 6 restricts use and disclosure for secondary purposes more tightly than for ordinary personal information
• APP 8 requires the entity to take reasonable steps to ensure overseas recipients do not breach the APPs, and the entity remains accountable
• APP 11 requires reasonable steps to protect against unauthorised access, modification, disclosure, loss, or interference

State and territory health records laws layer on top. In New South Wales the Health Records and Information Privacy Act 2002 (HRIP Act) and its Health Privacy Principles apply to public and private sector providers. In Victoria the Health Records Act 2001 applies. Queensland, the ACT, and other jurisdictions have parallel arrangements. A provider operating across states deals with several of these regimes at once.

The Notifiable Data Breach scheme adds the obligation to notify the OAIC and affected individuals where there is unauthorised access or disclosure of personal information that is likely to result in serious harm. The OAIC's published statistics show health service providers consistently topping the table of notifiers. The reasons are structural. The records are unusually sensitive, the threshold for "serious harm" is more readily met, and many providers have several systems and vendors handling the same patient information.

AI changes the picture in two specific ways. First, AI usually processes data offshore. Most AI model providers route requests through the United States or other jurisdictions. That engages APP 8 cross-border disclosure, and it means a Privacy Impact Assessment is the bare minimum due diligence. Our data sovereignty in Australia guide covers the practical questions to ask. Second, AI tools often retain conversation history, prompts, or model fine-tuning data, which means a breach at the vendor can expose patient data months after the original consultation.

If a practice cannot answer, in writing, where its AI vendor stores data, how long it retains it, and which sub-processors touch it, the practice cannot meet APP 8 or APP 11 obligations.

Part 4: The Four Highest-Risk AI Deployments in Healthcare

Most providers are evaluating vendor products rather than building bespoke AI. Four categories carry the highest regulatory and clinical risk.

Two patterns are worth calling out. Ambient AI scribing is now widely marketed to Australian practices, and the question of whether a particular product is SaMD or out-of-scope depends on what the product outputs, not what its marketing claims. Get a written position from the vendor. The administrative category, by contrast, is genuinely lower clinical risk, but the Privacy Act and APP 8 obligations are identical to the other three. Administrative does not mean unregulated.

Part 5: The Liability Flow When Things Go Wrong

Healthcare boards are rightly cautious about AI, because an adverse event sets off more parallel processes than in most other sectors. Here is what actually happens when an AI-supported clinical workflow produces an incorrect outcome.

The single most important practical lesson from this flow is that vendor contracts written for software-as-a-service do not handle clinical liability well. Many vendor terms cap liability at fees paid in the last 12 months, exclude consequential loss, and disclaim fitness for clinical purpose. A provider needs to negotiate clinical-specific terms, including audit rights, breach notification timelines that match the NDB 30-day clock, and clear allocation of indemnity for AI-caused errors.

Part 6: The Control Stack for Healthcare AI

Healthcare AI does not get safer because the vendor is large or the demo was impressive. It gets safer because the deploying organisation has a control stack covering pre-deployment, live operation, and incident response. The principles here are the same as in the operating AI agents in production article and the AI staffing gap article, but the controls are specialised.

A practice that deploys AI without these controls carries regulatory, professional, and financial risk that will eventually crystallise, and the controls cost far less than the crystallisation.

Part 7: Which Regulator Do You Need to Plan for First?

For a Practice Manager or CIO sitting down with a vendor brochure on a Tuesday morning, the practical question is: where do I start? This decision tree maps the inputs to the first regulator your project needs to engage with.

Most providers will have several of these running concurrently, and that is the real reason a healthcare AI portfolio needs central governance rather than department-by-department procurement.

Part 8: 10-Question Readiness Checklist for Practice Managers and CIOs

Before signing or renewing any AI vendor contract, every healthcare provider should be able to answer yes (or have a documented mitigation) to these ten questions.

1. Have we determined in writing whether this product is a Software as a Medical Device, and if so, is it included in the ARTG?
2. Has our clinical governance committee reviewed and signed off on the use of this AI in the relevant clinical workflow?
3. Have we completed a Privacy Impact Assessment, and does it specifically address APP 3 consent and APP 8 cross-border processing?
4. Do we have a complete list of the vendor's sub-processors and where each one processes data?
5. Does the vendor contract include audit rights, NDB-aligned breach notification, and AI-specific indemnity provisions?
6. Have we notified our professional indemnity insurer and confirmed coverage is not excluded or conditioned?
7. Is the documentation standard for clinicians updated so that the clinical record shows the clinician's reasoning alongside the AI output?
8. Are we monitoring override rates, exception logs, and accuracy samples, and reporting them to clinical governance monthly?
9. Do patients know AI is used in their care, with consent or opt-out where applicable under APPs and state health-records laws?
10. Do we have an adverse-event playbook that integrates clinical incident management, the OAIC 30-day NDB clock, AHPRA notification, and insurer notification?

If your team cannot get to ten yeses, the gap is the work plan. Treat each unanswered question as a deliverable owned by a named person with a deadline.

The Regulator Map Is the Strategy

There is a temptation in healthcare to treat AI procurement as a technology decision and to bolt compliance on at the end. The pattern in the OAIC's healthcare breach numbers, in the AHPRA notifications data, and in vendor contract clauses suggests the opposite. The regulator map is the strategy. Pick the tools that fit the map, deploy them with the controls described above, and the productivity wins are real and durable. Pick tools that look impressive in a demo but cross regulatory lines, and the cost arrives later, usually in an OAIC notification, an AHPRA complaint, or both.

The four-regulator stack (TGA, AHPRA, Privacy Act and OAIC, state health-records laws) is the operating environment, whether or not a project plan acknowledges it. The providers that work with it, rather than around it, are the ones who will reach the productivity benefits AI promises without the regulatory cost most rushed deployments incur.

For a structured conversation about where your AI portfolio sits on this map, the AI strategy service page and the managed AI services page outline how we approach this work. To talk through a specific deployment or vendor selection, book a 30-minute consultation: calendly.com/solve8/30min.

Related Reading (Series):

• Why Australian Businesses Should Not DIY AI Agents Without Understanding - The foundation for AI deployment thinking
• Operating AI Agents in Production: The Australian Business Reality - What live AI operation actually requires
• The AI Agent Staffing Gap in Australian Business - Who you need internally
• Financial Services AI Compliance: APRA and ASIC - The other regulated-industry deep dive in this series
• AI Vendor Selection Questions for Australian Buyers - The procurement-side companion
• ACCC Consumer Guarantees and AI Implementation - The ACL and Moffatt v Air Canada principles applied
• AI Security Checklist: 50 Points for Australian Businesses - The security control set referenced in Part 6
• AI Agent Governance: Data Access, Privacy, and Human Override - The governance frame for any AI deployment
• Data Sovereignty in Australia: A Guide for Australian Businesses - APP 8 and cross-border processing in depth

Sources: Therapeutic Goods Administration regulation of Software as a Medical Device (TGA, current guidance); Australian Health Practitioner Regulation Agency code of conduct and digital health guidance; Privacy Act 1988 (Cth) and the Australian Privacy Principles; OAIC Notifiable Data Breaches Report, January to June 2024 and successive periods; NSW Health Records and Information Privacy Act 2002; Victorian Health Records Act 2001; DISR Voluntary AI Safety Standard 2024; Moffatt v Air Canada 2024 BCCRT 149.