Digital health is moving quickly across Australia. New tools promise to streamline referrals, improve access, and reduce administrative burden. But one question has a habit of surfacing late – and causing significant disruption when it does.
Will my health app need approval from the Therapeutic Goods Administration?
For founders and public sector teams alike, the answer shapes far more than compliance. It affects product design, timelines, procurement, and ultimately whether your solution can be deployed in real clinical environments.
This article sets out a practical way to think about TGA obligations – grounded in how software is actually designed and used.
The short answer
Your healthcare app may require TGA oversight if it is intended to:
- diagnose a condition
- monitor a patient’s health
- predict clinical risk
- treat or manage a disease
- influence a clinical decision.
This definition aligns with guidance from the Therapeutic Goods Administration and the International Medical Device Regulators Forum, which classify certain software as Software as a Medical Device (SaMD).
If your product crosses that threshold, it is regulated under the Therapeutic Goods Act 1989.
What counts as Software as a Medical Device?
At a high level, software becomes a medical device when it performs a medical purpose on its own – without being part of a physical device.
That purpose might be clinical, predictive, or decision-oriented.
In practice, the distinction is easier to understand through examples:
- A referral platform that routes patients between providers → typically not regulated
- A system that prioritises referrals based on clinical urgency → likely regulated
- A symptom checker that suggests possible conditions → likely regulated
The shift is subtle but important. It is not about how complex your software is. It is about whether it interprets information in a way that affects care.
The critical test – intended use
The TGA does not assess software based on how it is built. It looks at what the software is intended to do.
This ‘intended use’ is inferred from:
- product features and functionality
- user interface and outputs
- instructions and documentation
- marketing and positioning.
A useful way to test this is to ask:
Does this feature change what a clinician does next?
If the answer is yes, you are likely moving into regulated territory.
Consider the progression:
- Displaying patient data → low regulatory risk
- Summarising or structuring data → moderate risk
- Interpreting data or recommending action → high likelihood of regulation
This is where many products cross the line without realising it.
Where the line is drawn
Some categories of software are explicitly excluded from regulation by the Therapeutic Goods Administration.
These typically include:
- general wellness apps
- administrative and workflow tools
- electronic health records that do not analyse data
There is also an important nuance around clinical decision support.
If a clinician can independently review and verify the basis of a recommendation, the software may fall outside stricter regulation. If the logic is opaque or difficult to interrogate – particularly in AI-driven systems – regulation becomes more likely.
Small design decisions matter here. A feature that introduces automated prioritisation, risk scoring, or alerts can change your classification.
If your app is regulated – what happens next?
If your software meets the definition of a medical device, it must be classified according to risk.
Australia uses a tiered system:
- Class I – low risk
- Class IIa – low to medium risk
- Class IIb – medium to high risk
- Class III – high risk
Classification depends on:
- the severity of the condition involved
- how much the software influences decisions
- the potential harm if it is wrong
For example:
- A simple monitoring tool may fall into Class I
- A diagnostic support tool may be Class IIa or IIb
- A system guiding critical clinical decisions may reach Class III
Once classified, the product must be included in the Australian Register of Therapeutic Goods before it can be supplied in Australia.
What compliance actually involves
TGA compliance is not a single step. It is an ongoing obligation that spans the product lifecycle.
Typical requirements include:
- clinical evidence to support safety and performance
- documented risk management processes
- quality management systems (often aligned with ISO standards)
- software lifecycle controls and traceability
- post-market monitoring and reporting
For founders, this is about building a product that stands up to clinical scrutiny.
For institutional buyers, it is a signal that the product can be safely deployed at scale.
The risks of getting it wrong
Operating outside the regulatory framework carries real consequences under the Therapeutic Goods Act 1989.
These include:
- fines and enforcement action
- removal of the product from the market
- delays to pilots or procurement
- loss of trust with clinicians and stakeholders
In practice, the commercial impact is often felt first. Many hospitals and government programs will not engage with products that should be listed on the ARTG but are not.
How product decisions trigger regulation
One of the most overlooked aspects of TGA compliance is when it becomes relevant.
Regulation is not something applied at the end. It is shaped by decisions made during product design.
A few common examples:
- Adding an AI triage feature → may trigger SaMD classification
- Introducing alerts or risk scores → increases regulatory scrutiny
- Moving from data display to recommendation → shifts intended use
These are often incremental changes, made with good intent. But they can materially change your regulatory obligations.
The implication is clear.
Compliance is a product design consideration, not a post-build checklist.
A simple self-assessment framework
If you are unsure where your product sits, this sequence is a useful starting point:
- Does the app have a health-related purpose?
- Does it influence clinical decisions or patient outcomes?
- Can a clinician independently verify its outputs?
- What is the potential harm if the output is incorrect?
- Does it meet the definition of Software as a Medical Device?
This will not replace formal advice, but it will quickly clarify your direction.
Two practical scenarios
Scenario 1 – referral platform
A platform is built to streamline specialist referrals.
- If it manages documents and communication → unlikely to be regulated
- If it prioritises patients based on clinical urgency → likely regulated
Scenario 2 – internal hospital tool
A dashboard is developed for operational visibility.
- If it reports on activity and performance → not regulated
- If it recommends interventions or flags clinical risk → likely regulated
In both cases, the difference comes down to how the software influences decisions.
App store considerations
Even outside formal regulation, distribution platforms apply their own rules.
Both Apple and Google scrutinise medical and health claims. Apps that present themselves as diagnostic or treatment tools may be required to demonstrate evidence or regulatory alignment.
Rejection at this stage is often a signal that the product’s intended use needs closer examination.
When to engage regulatory expertise
Teams often wait too long to bring in regulatory guidance.
In practice, it is worth engaging expertise:
- when defining core product features
- before clinical pilots or trials
- ahead of procurement processes
- when introducing predictive or AI-driven functionality
Early input reduces rework and helps align product decisions with regulatory expectations.
Designing for compliance from day one
For healthcare products, compliance and design are not separate concerns. They are intertwined.
Building with regulatory awareness from the outset leads to:
- clearer product boundaries
- smoother procurement pathways
- stronger clinical trust
- fewer delays later in development
It also creates better products. Constraints force clarity – particularly around how decisions are made and communicated.
What to do next
If you are developing a healthcare app, practical next steps are to:
- define your product’s intended use in plain language
- map features against SaMD criteria
- identify where decisions are being influenced
- validate your assumptions against TGA guidance
- design with compliance in mind from the beginning.
Where product decisions meet regulation
Healthcare software operates in a system where trust, safety, and accountability matter. Understanding whether your product requires approval from the Therapeutic Goods Administration is not just about regulation. It is about building something that can be used, adopted, and relied on in the environments that need it most.
In practice, regulation is rarely a final step. It is shaped by product decisions – often earlier than teams expect.
We are not regulatory consultants. But we do help teams understand how features, workflows and data handling can trigger regulatory obligations – so you can make informed decisions from the outset.
If you are in the early stages, we can help you map where regulation may come into play, and when it is time to bring in specialist advice.
Looking for tailored advice for your app project?
We offer free 30 minute consultations to provide you with:
- A clear understanding of what your app project would involve, including a realistic expectation of cost/time
- Insight into the most important things to consider for your project before you proceed
- Recommendations on next steps
We’d love to hear from you.
Book a free 30 minute consult.
About the author
Guy Cooper is the Managing Director of Wave Digital, where he brings his technical expertise, commercial acumen, and passion for creating better lives through technology to delivering apps for healthcare, government, non-profits, education, research, corporates and startups.
