How to build an AI implementation roadmap for healthcare

Busy and moving aren't the same thing. I ran a multidisciplinary clinic in New Zealand, and some of my busiest months changed nothing at all about how the work got done. The admin is the thing that stops anyone sitting back and looking at the workflow underneath it. That's the trap I see most, and it's why the AI project stays a good idea that gets mentioned every few months.

What usually breaks it is a nudge. Someone in the owner's network tried something and it worked. Or they read someone they trust. Or they've just had enough of the current process and want it gone.

Once the nudge lands, the question changes. It stops being whether AI is worth doing. It becomes what order to do things in.

The short version. Start from the outcome you want this quarter. Put the first tool in the back office. Pay for the follow-up before you pay for the software. The governance work is real and it still gets done. It just runs alongside the first rollout instead of six weeks ahead of it.

Which problem to solve first, and whether the spend pays for itself, is a different question. We answered that one in AI adoption in healthcare. This page assumes you've made that call. From here it's a running order. Who does what, in what sequence, and what breaks when you skip a step.

The order below is my own view, not a summary of anyone's framework. It comes out of running that clinic, and out of years spent selling technology into practices. Where the official guidance puts things in a different order, I say so and point you at it.

The order the guidance gives you isn't the order you'll follow

The Australian Government's own foundations guidance puts governance first. Pick a senior leader to own AI. Write an AI policy. Work out the impacts and screen the risks. Keep a register of what you're running, ask suppliers for proof, and keep a human in control (Department of Industry, Science and Resources). The templates for the policy, the risk screen and the register are free on the same site.

It's a sound list. Every item on it has to exist eventually. It's also not how a small practice starts.

Small practices run on revenue and growth goals. Nobody in a busy clinic opens a Monday by drafting an AI policy. What I see instead is simpler. The owner works out the outcome they want this quarter. Then they go looking for the workflow or the automation that gets them there. That's step 1 below. The governance work gets picked up from step 2 on.

So this sequence starts where an owner actually starts. It picks up the governance steps in the order they start to matter.

Step 1. Name the outcome, then work back to the workflow

Write the outcome down first, in your own words. More new patients. Fewer hours lost to notes. A clearer view of what the practice is actually earning. Pick the one that matters this quarter. Then find the bit of the week sitting between you and it. Only then go looking at what could do it differently.

The outcome picks the shortlist, which is why the order matters. If the outcome is more new patients, for example, the answer might not be a clinical tool at all. It might be how the practice shows up in AI search.

This sounds obvious and it's the step that quietly gets done backwards. A tool turns up first. Someone builds the case for it afterwards. Six months later nobody can say what it changed.

Who owns it: you, or your practice manager. Whoever owns the number.

Skip it and: you get a tool that works fine and can't be tied to anything you were trying to do.

Step 2. Give it an owner, and write the policy while you roll out

A governance owner is the one named person who is accountable for AI in your practice: what gets used, what doesn't, and who signs it off. In a clinic of three to ten people that's usually you or the practice manager. You don't need a committee. The point of naming someone is that the decisions land somewhere specific.

The policy comes after. It can be short. Have a look at the one an Australian practice, Village Medical Practice, publishes for its patients to read. Its generative AI policy covers what AI helps with, where the data sits, that a clinician checks everything, and how a patient can opt out. Good shape to borrow, because it was written for patients rather than for a regulator.

Who owns it: the named person, working from the free government template.

Skip it and: staff make their own calls about which tools go near patient information, and you don't find out until something goes wrong.

Step 3. Start in the back office

Dr Brent Richards is an adjunct professor of research at Griffith University and sits on the board of the Queensland AI Consortium. He put the sequencing plainly to the Medical Journal of Australia's news arm: "Running a general practice is just like running any other business aside from the clinical aspect... Look at your back office. What repetitive tasks could you automate? You can potentially find a tool that does it for you immediately. Start with your pain points and move on from there" (MJA InSight).

Back office first gives your team a low-stakes rehearsal. They find out what these tools are good at and where they fall over. Get it wrong there and you redo a task. Nobody's care is affected. That makes the next jump, anything touching the clinical record, a much smaller one.

Back office covers more ground than most owners expect. Reminders sit here. So does the billing reconciliation nobody enjoys, and the workflows and automations behind it. Here's an example people miss: the phones sit here too, which is why an AI receptionist for a clinic is such a common first project. Our guide to what AI actually does day to day in a clinic goes through the admin side properly.

Who owns it: whoever runs the front desk, with the accountable person signing off.

Skip it and: the first AI your team ever touches is also the riskiest one you run.

Step 4. Before you buy: proof, where the data sits, and the medical-device line

This is where the sequence earns its keep. It has to happen before money changes hands, and before the demo buzz sets in.

The government guidance is blunt about the first check: "Ask for proof. If you're buying an AI system, ask the developer or supplier to show proof that it's been properly tested" (Department of Industry, Science and Resources).

The Australian Commission on Safety and Quality in Health Care says the same thing for clinical tools. It also tells you what to do when the answer comes back thin. Confirm the evidence base for the tool "including its risks and limitations and how these are managed". And if "you are not satisfied with the evidence to support the accuracy, efficacy and safety of the AI tool, you should re-consider its use in consultation with your organisation" (ACSQHC AI Clinical Use Guide, version 1.0, August 2025). The same guide says this applies to small practices too: "Smaller organisations may need to establish appropriate governance and processes to ensure AI tools are deployed safely and responsibly and in line with their intended use."

Where the data sits is the other one to get answered in writing before you sign. So is whether the vendor uses your data for anything else.

Four questions, sent in one email, cover most of it:

• What proof of testing can you show for this product?
• Which country does our patient data sit in, and who else can get at it?
• Do you use our data to train anything, and can we opt out in the contract?
• Is the product a medical device here? If it is, what's its ARTG number?

Get the answers in writing. A vendor who'll say it on a call but not in an email has told you something. We go through the full buying checklist for one tool category in how to choose an AI scribe.

Is the tool a medical device?

One question decides whether a tool has a regulatory hurdle in Australia. Does it only transcribe, organise or move information around? Or does it interpret?

The TGA draws the line at interpretation. A software-based medical device is, in the TGA's words, software that "analyses or interprets" clinical information by "generating a diagnosis, differential diagnosis or treatment recommendation not explicitly stated by the healthcare practitioner". Software that meets that test has to be listed on the Australian Register of Therapeutic Goods (TGA). The rule is written up around digital scribes, and it carries over to nearly any clinical AI tool you'll be offered.

Ask the vendor where their product sits. If they say it's a device, ask for the ARTG number.

Who owns it: the accountable person, before you buy.

Skip it and: you find out what you bought once it's already in the consult room.

Step 5. Consent and transparency, before it goes live

Consent goes before the first patient meets the tool. Not after a few weeks of quiet trial.

Two rules from the ACSQHC guide sit here. The first one: only use AI tools "that are authorised and/or supplied by your organisation". The guide says this "applies to clinicians that have both clinical and managerial responsibilities in sole-trader or smaller organisations". In plain words, if you're the boss and the clinician, you still have to sign your own tools off. The second one: always check the output yourself, "recognising that these tools support but do not replace clinical judgment" (ACSQHC).

In New Zealand, the Medical Council's guidance on using artificial intelligence in patient care is the equivalent reference for doctors. In Australia, AHPRA's five principles cover accountability, understanding, transparency, informed consent and the legal side. We set them out in our AI in healthcare guide.

Write the patient-facing wording at this step too, and keep it plain. A patient who is told clearly what the tool does, and that they can say no, has a real choice. A patient who works it out later hasn't.

Who owns it: the accountable person writes it. Every practitioner uses it.

Skip it and: you're running an undisclosed tool over patient information, which is the first thing a regulator would look at.

Step 6. Pick a champion, and give the team two to three weeks

An AI champion is the person who carries the tool day to day. First to learn it, first to get asked about it, and the one who tells you when it isn't working.

A champion matters more than the training plan. From the software rollouts I've been part of, the thing that decides whether the champion model works is whether you picked the right person at the start. That's someone with a genuine interest in the technology, an innovator by temperament. Not whoever had capacity that month. The Australian Physiotherapy Association's own implementation guidance lands in the same place (Australian Physiotherapy Association, InMotion).

That same piece adds a rule worth keeping. Have people inside the practice who champion the tool. Take responsibility as the owner for making sure staff get trained. And don't force anyone to use it, because it should be their choice. It puts the adjustment period at two to three weeks, so staff can get comfortable and customise their templates.

Two to three weeks matches what I'd expect. Bigger organisations take longer, because more people at more levels have to come along.

Who owns it: the champion, day to day. You own whether the training actually happened.

Skip it and: the tool gets used by the two people who liked it and quietly ignored by everyone else.

Step 7. Hypercare, the step everyone skips

Hypercare is a fixed window after go-live when one named person has to check the tool is actually being used, answer the questions that only come up in real use, and fix what got missed. Think 30, 60 or 90 days, agreed before the project starts.

This is the step that costs the most and shows up in almost nobody's plan. Training gets rushed, the project gets delivered, and everyone washes their hands of it. Nobody checks in afterwards.

So build the window into the project. Put it in the scope. If a consultant is running it, put it in the price too.

Price it openly, because it's the cost owners least expect to pay. You pay for the project and you pay for the software. You don't usually pay for adoption and rollout. Which means you're rolling the dice on whether any of it sticks, and every dollar you spent earlier can go to waste.

Who owns it: named in the scope before the project starts.

Skip it and: adoption drifts back to the old process within a couple of months, and nobody notices until the renewal invoice turns up.

Step 8. Audit it, and keep the register current

The last step is the one that makes the whole thing repeatable. Keep a register of the AI systems your practice runs. The government guidance asks for one and gives you a free template (Department of Industry, Science and Resources).

Two habits from the ACSQHC guide belong here. Label records so it's clear AI was involved in making them. And watch for scope creep: "Be alert to changes in the functional scope of AI tools which can change or 'creep' over time through software updates or upgrades... You may not be notified when these changes occur" (ACSQHC). The tool you checked in March might not be the same tool in September.

Set the review date when you go live, rather than promising to look at it sometime. Our walkthrough of rolling out an AI scribe shows what this looks like for one tool, including the accreditation angle for general practices.

Who owns it: the accountable person, on a fixed review date.

Skip it and: the register goes stale, the tool changes underneath you, and the evidence trail you'd need isn't there.

Where Australia and New Zealand differ

The steps are the same on both sides of the Tasman. The documents you point at aren't. Which body you quote, such as the TGA or the Medical Council of New Zealand, depends on which side you're on.

Health New Zealand's framework came out in July 2026, led by Dr Rosie Dobson. It's one to understand rather than adopt. The National AI and Algorithm Expert Advisory Group spent 18 months building it, for system-level review of AI tools. Health NZ says it is "unique to the Aotearoa New Zealand context. It has been developed for our setting, where there is no specific AI legislation or regulation" (Health New Zealand). Nobody is assessing your private clinic against it. It does tell you what good practice looks like to the people who run the public system.

The running order on one page

None of that needs a data team, a platform decision or a business case with a five-year projection. It needs one accountable person and a calendar.

Where Opal helps

Most practices don't need this sequence explained to them. They need someone in the room running it with them. The week is already full, and steps 2, 7 and 8 are the first to fall off a busy owner's list.

That's what AI strategy and adoption is. We start from the outcome you're chasing, work back to the workflow, and scope the rollout with the hypercare window in it rather than bolted on later. We don't sell software and we don't take a commission on what gets recommended.

FAQ

Who is legally responsible if an AI tool makes an error?

You are. MJA InSight puts it directly in its own published FAQ on AI adoption. AHPRA is clear that the practitioner is personally and professionally accountable for the clinical decisions they make, and for the records that come out of them (MJA InSight). A vendor's assurance doesn't move any of that onto them. It's why step 4 sits before the purchase and not after it.

Why is it difficult for health systems to implement technology?

Clinicians ask each other this openly. On the Australian junior doctors' forum r/ausjdocs, a long thread on the question pulls answers about policy, privacy, budget and safety. At practice scale, the answer I see most often has little to do with the technology. Training gets rushed, and follow-up stops the day the project is signed off. So the work of changing how people actually do their jobs never happens. That's step 7, and it decides whether the previous six were worth paying for.