An AI use policy for
a medical practice

An AI use policy earns its place when it answers the questions staff have mid-session: whether a discharge summary can be pasted into a chatbot to shorten it, whether the transcription app a colleague recommended can be trialled next week, and who gets told when a drafted note describes an examination that never happened. A policy that recites principles answers none of those and stays unopened between accreditation visits. Write it so a new receptionist and a locum GP can each find their answer in under a minute.

No Australian law names an AI policy as a mandatory practice document, which is why writing one gets treated as optional. APP 1 requires reasonable steps to implement practices, procedures and systems that will ensure compliance with the Australian Privacy Principles, and where staff put health information through AI tools, a written rule about those tools is the ordinary way that obligation is met. Health service providers are covered by the Privacy Act whatever their turnover, so the small business exemption is not available to a practice. AHPRA and the National Boards have published guidance on using artificial intelligence in healthcare, and it keeps the practitioner accountable for the care delivered and the record kept whatever tool produced them.

The document that gets used stays short and is specific about seven things: the tools in use, who approves a new one, what may never go into a general purpose tool, who reviews and signs clinical output, what patients are told, what happens when something goes wrong, and when the document is next opened. Whether it lives as a standalone policy or as a section inside the existing privacy and information security policy matters less than it being cross-referenced from the induction pack. A standalone version is easier to hand to a surveyor and easier to revise when a vendor changes its terms.

The tool a practice procured is rarely the one creating the exposure, because it arrived with a contract and at least one person who read the privacy terms. The exposure is the browser extension a doctor installed to summarise specialist letters, the consumer chatbot a receptionist uses to rewrite recall messages, the transcription app on a personal phone, and the meeting assistant that switched itself on inside the practice's video conferencing account. None of them appear in the minutes.

Running the first pass as an audit produces a thin register, because someone who has found a tool that saves them time will not hand it to a process that looks designed to take it away. Run the discovery round as a standing item in a staff meeting rather than by email, have the principals name their own tools first, and say plainly that nothing disclosed in that round carries a consequence. Write down what comes back during the meeting itself, because a list rebuilt afterwards loses the tools mentioned in passing.

A short technical sweep finds the rest: browser extensions on shared consulting room machines, applications installed on practice devices, third-party connections and API tokens authorised inside the clinical software, add-ins on the practice mailbox and video conferencing account, and personal subscriptions appearing on expense claims. Anything undeclared goes onto the register the same way, with no disciplinary step the first time, and the policy should say when that amnesty closes.

One person keeps the register current, and six columns do most of the work:

• The tool and the plan or tier in use, since free and paid tiers carry different data terms.
• Who uses it, for what, and whether patient information goes into it.
• Where the data is stored and processed, and whether anything leaves Australia.
• Whether inputs train the vendor's models, and whether that can be switched off.
• Retention and deletion periods, including consultation audio.
• Who approved it, on what date, and when it is next reviewed.

Write the rule so it catches trials: no tool touches patient information until it is approved and on the register, and a free trial counts as use. Trials are where this fails, because they cost nothing and do not feel like procurement, and by the time anyone asks about data handling weeks of consultations have gone through an unassessed product.

Approval does not need a procurement function. It needs one person writing down, before the tool sees a patient, the register columns above plus two more: what the vendor commits to on breach notification, and what happens to the practice's data when the practice stops using the product. The OAIC's guidance on privacy and the use of commercially available AI products, published in October 2024, covers this category of tool and recommends a privacy impact assessment, which at practice scale is a short written assessment rather than a project. Keep the completed answers with the register entry, because the approval decision is what a surveyor or an insurer asks to see.

Two of those answers carry legal weight. Where a tool generates or infers information about a patient, the OAIC's position is that this is a collection of personal information to which APP 3 applies, and in a practice it is health information, which is sensitive and carries a higher bar. Where information is disclosed to an overseas recipient, APP 8 and section 16C of the Privacy Act generally leave the practice answerable for what that recipient does with it.

One rule should carry no qualifiers: patient information does not go into general purpose chatbots or consumer AI tools, including de-identified cases put up for a second opinion, letters with the name removed, and a discharge summary pasted in for tidying. De-identification is weakest on exactly the material clinicians most want help with, because an unusual presentation, an age, a suburb and a referring specialist together identify a patient to anyone who knows the area. Write the permitted uses down as well, and name the approved tool for each common task, since a policy that only prohibits leaves staff guessing.

A line saying clinicians should review AI-generated content changes nothing, because everyone already agrees with it, so write it as a standard with a test attached. The clinician who signs a note is its author, signs only after reading it in full, and checks it against their own recollection of the encounter rather than against whether it reads well. A draft the clinician can no longer verify from memory gets rewritten rather than signed.

Name the failure mode in the document rather than instructing people to check carefully. What survives a quick read is content that is plausible and absent from the consultation: a systems review that was never taken, a normal finding for an examination that was not performed, a dose that has drifted by a decimal place. Two or three examples from the practice's own drafts do more than any general instruction.

Name one accountable role and the person currently holding it, usually the practice principal or a clinical governance lead, with a delegate for leave. That person owns the register, the approval decisions, the incident log and the review date, and the name goes in the document rather than the role alone. What the policy cannot do is move clinical responsibility onto that person or onto the vendor, since AHPRA's guidance leaves the practitioner using the tool responsible for the care and the record.

A practice policy binds employees through their employment. Where doctors work under service or facility agreements rather than employment, which is the ordinary arrangement in general practice, the policy binds them only if the agreement picks it up, so it needs a clause taking up practice policies as varied from time to time, and the approval gate has to reach any tool used against the practice's records. Settle in the same document whether the practice entity or the individual practitioner holds the health information for Privacy Act purposes, because that decides who carries the APP obligations and who makes a breach notification. State where registrars sit as well, because a supervisor countersigning notes drafted by a tool the registrar did not compose is reviewing something other than the registrar's own work.

Two obligations get conflated. Consent to record a consultation happens in the room, usually once per patient, shaped by clinical courtesy, professional guidance and state and territory surveillance and listening device legislation. Privacy transparency is a practice level obligation, discharged through the privacy policy required by APP 1 and the collection notice required by APP 5. A practice can run the consent conversation well and still have a privacy policy that says nothing about AI, and that is the more common gap.

The privacy policy needs to state that AI tools are used in producing clinical records and practice correspondence, what categories of information they handle, where that information is stored and processed, whether any of it leaves Australia, how long audio and drafts are retained, and how a patient declines. A shorter version belongs on the waiting room notice and the website. Name who updates those documents and require the update whenever a tool joins the register, or the register and the patient-facing wording drift apart within a year.

The automated decision-making transparency requirement that starts in December 2026 lands on the privacy policy rather than on the clinical work. It reaches computer programs used in decisions that could reasonably be expected to significantly affect a person's rights or interests, and the policy then has to describe the kinds of personal information used and the kinds of decisions involved. Settle it on the register: classify each entry against that description and write the answer beside it, because a triage or risk-scoring tool can fall inside it while a scribe drafting a note for a clinician to review usually does not.

An incident route that only activates for a confirmed data breach is set too high, because most of what goes wrong with AI in a practice is smaller than a breach and is the early warning for one. Define the reportable events in the practice's own words, make the reporting step trivial, and send whatever lands on the list to the accountable person the same day, in writing.

Where there are reasonable grounds to suspect an eligible data breach under the Notifiable Data Breaches scheme, the practice must carry out a reasonable and expeditious assessment and take all reasonable steps to complete it within 30 days of becoming aware. Where the threshold is met, the practice prepares a statement for the OAIC and notifies the affected individuals as soon as practicable. Incidents involving My Health Record carry a separate mandatory notification to the System Operator, which is the Australian Digital Health Agency, so the policy should name who makes that call.

Where a clinical record is affected, contact the practice's medical defence organisation, and the treating clinician's own, before touching the record. Do not quietly overwrite it. Correct it with a dated addendum that leaves the original visible, because clinical software keeps its own audit trail of amendments and an unexplained change is visible to anyone who later reads that trail.

Log the incidents that go nowhere as well, because near misses show which tool keeps producing the same defect and which part of the policy is unclear:

• A drafted note attached to the wrong patient, whether or not it was signed.
• Patient information entered into a tool that is not on the register.
• Signed content describing something that did not happen in the consultation.
• A recording that continued after the consultation ended, or a device left capturing an empty room.
• A patient asking what tool was used and nobody being able to answer.

If a surveyor asks how staff know the rules, the answer has to be more than the document sitting on the shared drive. What gets kept is proof of reach: a dated attendance record for the session that introduced it, a short signed acknowledgement from each staff member, and coverage in the induction pack. Reception and administrative staff need their own one page version carrying the permitted tool list and the escalation contact rather than the review and sign standard. Locums, registrars on rotation and after-hours cover are the standing gap, so hand that page over at the start of the shift and record the handover.

Give the document a review date with a name against it and attach the review to a meeting that already happens, because a policy written during an accreditation push and never reopened names tools that have since changed their terms or been withdrawn. Some events should force a review before the date falls due: a new tool being approved, a vendor changing its terms, its sub-processors or where it processes data, a regulator publishing new guidance, any incident of the kind above, and a change of clinical software, which changes the authorised third-party connections.

At the review, test the register against reality instead of reading it back. Re-run a short discovery round and take off the tools no longer in use, because entries that are wrong in either direction cost the register its credibility. Close out every incident on the log, and confirm that everyone who joined since the last review has acknowledged the policy. Version and date every release and keep the superseded copies, so a practice asked to show its AI governance hands over dated revisions with an incident log behind them.