Before you launch clinical AI in Australia, work out if it is a medical device.

If you are putting an AI scribe or a decision-support tool into an Australian clinic this year, the first question is not which model you used but whether the thing you built is a medical device, because if it is, it cannot be supplied until it is on the Australian Register of Therapeutic Goods, and the TGA has said it is now looking.

That question quietly decides a launch date, which is why it is worth answering early. A team can spend months on the model, the workflow and the integrations, and then discover late that the product meets the legal definition of a medical device and has to clear a regulatory pathway before a single clinic can use it. The good news is that the test is knowable up front, so the rest of this article walks through how it actually works and what it means before you ship.

A medical device is a purpose, not a technology

The Therapeutic Goods Act decides what counts as a medical device by its intended purpose, not by how it is built.¹ So if software is intended to diagnose, prevent, monitor, predict, provide a prognosis for, treat or alleviate a disease, or to compensate for an injury or disability, it meets that definition, and software has sat squarely inside the definition since the 2021 reforms made software-based medical devices explicit.²

Because purpose is what matters, "we use AI" tells you nothing about your obligations. A simple rules engine that flags a drug interaction and a deep-learning model that reads a retinal photo are judged the same way, by what the maker says the product is for. That intended purpose is the whole game, and you set it in the labelling, the marketing copy, and the words on the button in the interface, which means it is a legal artefact rather than a tagline, and a regulator will read it more literally than your marketing team meant it.

So the useful question is never "is it AI?" but "what does this claim to do for a patient?" Answer that in one plain sentence before anything else, because that sentence drives every decision that follows.

A scribe that only writes down what was said is not a device, but one that diagnoses is

The TGA has published specific guidance on digital scribes, and the line it draws is clean.³ A scribe that transcribes or translates a consultation, turning speech into text without interpretation, is not a medical device, whereas a scribe that interprets the conversation by generating a diagnosis, a differential, or a treatment recommendation the clinician did not actually state is a medical device.³

That distinction is easy to cross without noticing, because "summarise this consult into a note" is documentation while "suggest the three most likely diagnoses" is a medical purpose. So the same product can sit on the safe side of the line in one release and the regulated side in the next, simply because a well-meaning engineer added a helpful feature in a sprint. The classification is therefore not set once; it follows the feature set, and it can move under you.

This is not theoretical, because through 2025 the TGA signalled it is stepping up its oversight of digital scribes, including AI ones, working alongside Ahpra and the Australian Commission on Safety and Quality in Health Care, and it has been blunt that supplying a medical device that is not on the Register carries substantial penalties.³ "We will deal with the regulator later" is therefore not a launch plan but a recall risk with a delay on it.

Decision support has an exemption, with three conditions and a catch

Most clinical AI that is not a pure scribe lands in clinical decision support software, and there is a carve-out for it, but it is an exemption rather than a free pass. To be exempt from inclusion on the Register, decision-support software must meet all three conditions, in that it only provides or supports a recommendation to a health professional rather than directly to a patient, it does not directly process or analyse a medical image or a signal from another medical device, and it does not replace the clinician's own judgement in making a diagnosis or a treatment decision.⁴

There is also a fourth requirement that catches teams out, which is that exempt software has to show its working. The basis of each recommendation, whether the source, the guideline, the calculation or the logic, must be legible to the clinician so they can verify it in the moment, in the real clinical context.⁴ So a black box that says "do this" and cannot say why is not exempt; it is a regulated device wearing an exemption it does not qualify for.

Exemption is also not the same as exclusion, and the words are not interchangeable. Excluded software, for example a consumer tool for self-managing a condition that is not serious, sits outside TGA regulation entirely.⁵ Exempt software, by contrast, is still a medical device; it simply does not need to be included on the Register, while the TGA keeps oversight of things like advertising and adverse-event reporting.⁴ That gives you three buckets with three different sets of obligations, and you do not get to choose which one you are in, because the intended purpose chooses for you.

If it is a regulated device, how wrong it can be sets its class

Once software is a regulated medical device, its classification follows the harm it can cause by being wrong, so the pivotal question is who makes the call.⁶ If the software gives information to a health professional who then makes the final diagnosis, it generally sits lower, around Class IIa. But if it produces the diagnosis or the screening result itself, whether the user is a clinician or a patient, it climbs to Class IIb, or to Class III where a wrong output could lead to death or a serious deterioration in health.⁶

These are the rules that commenced on 25 February 2021, with a transition window that closed on 1 November 2024, which means new software is assessed against them now rather than against the old ones.⁷ Reaching market under those rules means a conformity-assessment route, technical documentation and clinical evidence, and inclusion on the Register before supply rather than after the first customer signs.² For a small team that is measured in months and real cost, so it belongs in the launch plan as a dependency, not something discovered halfway through a pilot.

The TGA is not the only gate

Even if your product is clearly not a medical device, a pure scribe say, you are not finished, because the Privacy Act 1988 and the Australian Privacy Principles govern every piece of health information the product touches regardless of TGA status.⁸ Health information is sensitive information, so collecting, storing and disclosing it carries obligations that a "we only transcribe" framing does not switch off.

And when something goes wrong, the Notifiable Data Breaches scheme requires notifying the OAIC and the affected individuals of an eligible breach, broadly meaning unauthorised access to or loss of personal information that is likely to result in serious harm.⁹ So a vendor that records consultations and cannot say afterwards what was accessed has a privacy problem whether or not it ever had a TGA one. Regulatory exposure in health is rarely single-source, and for scribes specifically the safety and professional bodies are looking at the same product from their own angles.³

What to do before you launch

The honest sequence is short, and all of it belongs before the launch date rather than after the first incident, so work through it in order:

• First, write the intended purpose down in plain words, meaning what the product does for a patient, because that one sentence drives everything below it.
• Then run that sentence through the TGA's own "is my product a medical device" test rather than your intuition about it.¹
• If it is a device, decide the bucket honestly between excluded, exempt decision support (and ask whether you can actually show your working), or regulated, and if it is regulated, start the conformity and Register work now so you can price the months in.⁴⁶
• Throughout, treat privacy as a parallel track from day one rather than a downstream clean-up.⁸

Trenthos builds Lumen on the assumption that these questions get asked at design time, not at launch, which is why the honest way to describe any new clinical-AI capability is "designed to align with the TGA's software framework and the Privacy Act, and working toward the relevant pathways" rather than "TGA approved" or "compliant" as a finished fact. The distance between those two sentences is exactly the work this article describes, and it is far cheaper to do at the start than to retrofit under a deadline.