building

What AHPRA's AI guidance means on a Tuesday shift

AHPRA has published guidance called Meeting your professional obligations when using Artificial Intelligence in healthcare, and it applies to every registered practitioner, pharmacists included. This post is not a compliance summary — plenty of law firms have already written those. It’s what the guidance actually changes about a specific decision on an ordinary shift: do I let an AI tool touch this task, and if so, how.

What does AHPRA’s AI guidance actually say?

Claim: The guidance sets five obligations — accountability, understanding, transparency, informed consent, and legal/ethical compliance — and puts the practitioner, not the tool or its vendor, on the hook for all of them.

Evidence: Per the guidance itself, practitioners “must apply human judgment to any output of AI” (accountability), should “review the product information about an AI tool including how it’s trained and tested on populations, intended use, and limitations” (understanding), should “inform patients and clients about their use of AI” (transparency), need to “obtain informed consent” from the patient before their data goes into an AI system or a conversation gets recorded (informed consent), and must handle data “in accordance with legal requirements” while “holding appropriate professional indemnity insurance arrangements” that cover AI use (ethical and legal issues). Meeting your professional obligations when using Artificial Intelligence in healthcare — Ahpra

Bottom line: None of the five principles is new professional obligation invented for AI. They’re the standard AHPRA obligations — sound judgment, informed consent, privacy compliance, adequate insurance — applied to a new class of tool. That’s the frame I use every time I decide whether something is fine to run through AI: not “is this allowed,” but “which of my existing obligations does this touch.”

Does this actually change anything about a normal shift?

Mostly it changes what I ask before I use a tool, not what tools exist. On a locum shift, “AI” mostly shows up as a scribing tool, a summarisation feature bolted onto dispensing software, or something I build myself for admin. For each one, the guidance means I now ask, out loud to myself: do I understand roughly how this was trained and tested, does the patient know it’s in the loop, and am I the one applying judgment to what it produces, or am I just accepting it.

That third question is the one that actually bites. It’s easy to nod along with an AI-drafted summary at the end of a long shift because it reads fluently and matches your general sense of the case. The guidance’s accountability principle is a direct answer to that: fluent isn’t the same as correct, and the practitioner who signs off is the one who’s answerable, not the model.

Do I need to tell a patient I’m using an AI tool?

Claim: Yes, where the tool is materially part of how their care is documented or decided — the guidance’s transparency and informed consent principles both point the same direction.

Evidence: The guidance says practitioners should “obtain informed consent from your patient, and ideally note the patient’s response in the health record,” and flags that AI tools recording consultations should “include an explicit consent requirement as an initial step before proceeding.” Meeting your professional obligations when using Artificial Intelligence in healthcare — Ahpra

Bottom line: In practice this is a low-friction conversation — “I use a tool to help draft notes, is that alright with you” — but it has to actually happen, and it has to be documented, not assumed. I hold a stricter version of this rule for my own AI work anyway: I don’t put real patient data through general AI tools at all, de-identified only, which sidesteps a chunk of the consent question before it comes up. That’s a boundary I’ve written about separately, not something the AHPRA guidance created — I’d hold it either way.

What does “understanding” a tool actually require?

Claim: Enough to judge fitness for purpose, not enough to audit the model’s training pipeline.

Evidence: The guidance describes the understanding principle as reviewing “the product information about an AI tool including how it’s trained and tested on populations, intended use, and limitations and clinical contexts where it should not be used” — the kind of information a vendor should be able to state plainly, not something requiring a data science background. Meeting your professional obligations when using Artificial Intelligence in healthcare — Ahpra

Bottom line: For most practitioners this is a reasonable bar and a useful filter. If a vendor can’t tell you, in plain language, what their tool was tested on and where it’s known to fail, that’s information worth having before you let it near clinical work — and it’s a fair question to ask regardless of what any regulator requires.

Does this apply the same way to something I build myself?

I don’t think the guidance treats “commercial tool” and “something I built” any differently, and I don’t either. When I build an AI system — for my own admin, or for a client — the same five obligations apply to me as the person deploying it, whether the model came from a vendor or I wired it together myself. Accountability doesn’t move to a subcontractor just because the code is mine.

Where building it myself changes things is that I actually can answer the “understanding” question in detail, because I know exactly what data went in and what the tool does and doesn’t do. That’s an advantage over a black-box commercial product, not an exemption from the principle behind it.

Where does this leave the “don’t automate this” line?

It confirms it rather than moving it. The line I already hold — no identifiable patient data through general AI tools, clinical sign-off always stays with me, nothing that fails silently gets to run unchecked — was set before this guidance existed, for the same underlying reason the guidance exists: the license is mine, and accountability doesn’t transfer to a model. AHPRA formalising that in writing doesn’t change the decision on a Tuesday shift. It just means I can point to the document when someone asks why I’m being careful.

This is a summary written for my own practice, not clinical or legal advice — read the guidance itself, linked above, before you rely on it for yours.

This same five-obligation lens is what I bring to client healthcare-AI work — the detail is on /work.

the build log

Get the build log.

One email when I ship something — a new AI system, a pharmacy workflow, a number from The 2040 Project.

No spam, no drip sequence, unsubscribe in one click.

The weekly dose: graded, sourced, 5 min.Subscribe