Website maintenance took place on Thursday 30 April 2026. If you experience any issues, please contact us.
Recently published
This page was published on [date_placeholder].
Recently updated
This page was updated on [date_placeholder]. See page history for details.
This guidance helps developers, sponsors and manufacturers understand how medical device software is regulated. It explains how intended purpose determines regulatory status, outlines the different types of software‑based medical devices, and shows what obligations apply when software is a medical device.
We regulate medical devices in Australia. This includes software and artificial intelligence (AI) that meet the definition of a medical device unless otherwise excluded.
A software or AI product is a medical device if it meets the definition of a medical device under section 41BD of the Therapeutic Goods Act 1989. These software products are also known as ‘digital’ technologies. They may work on general computing platforms (such as computers, mobile phones or tablets), or they might need specialised hardware.
Some software products and mobile apps are sources of information or tools to manage a healthy lifestyle. We do not regulate health and lifestyle apps, unless they meet the definition of a medical device.
If a software product is a medical device, it must be included in the Australian Register of Therapeutic Goods (ARTG), unless it is excluded or exempt, before it can be legally supplied in Australia.
We also regulate in vitro diagnostic (IVD) medical device software. There are some differences in how IVD software is regulated compared with other medical device software. For example, there are different classification rules for IVD software, and exemptions for some in-house IVDs. Labelling requirements and international standards for software lifecycle management and usability apply to both IVD and non-IVD medical device software.
There are typically 2 key parties involved in supplying medical devices in Australia:
A manufacturer is the person or company legally responsible for making the medical device, as indicated by the name on the label or the name under which the product is supplied. They are responsible for the design, production, packaging, and labelling of the device; however, they don’t have to do these things themselves.
It is the manufacturer’s responsibility to determine if their product is a medical device.
Software developers may not see themselves as manufacturers but under the Therapeutic Goods Act 1989 they will meet the definition of a manufacturer for regulatory purposes when their products are therapeutic goods or medical devices.
Example of a manufacturer: Software developer
A service provider wants to publish some software under their name. However, they want to outsource the design and development.
The service provider maintains responsibility for these aspects and publishes the software under their name.
The service provider meets the definition of a manufacturer of a medical device.
Example of a manufacturer: Adapting pre-existing software
A developer wants to develop an AI system that analyses data entered into a hospital electronic health record to inform clinicians of individual patient risk of developing sepsis.
Due to time constraints, the developer chooses to purchase a general large language model offered by another company to act as a base model for his product. The developer proceeds to tailor the performance of the AI model to suit their purpose.
As the developer has altered the intended purpose of the general platform they purchased from a third-party, they would now meet the definition of a manufacturer of a medical device.
Sponsors are legally responsible for supplying devices in Australia or exporting them.
The manufacturer–sponsor relationship is not necessarily one-to-one, that is multiple sponsors can supply the same model from one manufacturer, and a sponsor can supply devices from multiple manufacturers.
Sponsors of software-based medical devices must:
Sponsors must make sure the manufacturers of the devices they’re supplying hold conformity assessment evidence from a recognised independent body.
Under the Therapeutic Goods Act 1989, supply means providing therapeutic goods by any method, including sale, exchange, gift, lease, loan, hire, offering as a sample or through advertising.
This definition applies whether the goods are provided for payment or free of charge. The definition of supply also includes importing, exporting, manufacturing for supply, or otherwise placing the goods on the market under the sponsor’s name.
If software is made available to users in Australia – whether through an app store, cloud platform, or website – it is considered to be supplied in Australia. This applies whether the software is downloaded directly by consumers or accessed remotely via a web interface.
When a software product that meets the definition of a medical device is supplied in this way, the sponsor must:
Even if the software is hosted overseas or downloaded directly by users, it is still subject to regulation if it is accessible or intended to be used in Australia.
If you supply software-based medical devices, you need to determine whether you are the sponsor or manufacturer of the medical device for the purposes of regulation.
If you resell or supply software in Australia from or on behalf of an overseas-based developer, you are likely to be the sponsor of the device.
Platforms such as app stores or websites may distribute or resell software on behalf of the sponsor. In these cases, the platform will not meet the definition of a sponsor. The
We regulate software based on the manufacturer's intended purpose and how it is supplied.
The manufacturer defines how they intend the device to be used – not all possible uses. For instance, 2 apps may present with similar functionalities but have different intended purposes based on the features or information that is made available to the user, for example:
The intended purpose is documented in any materials provided with or about the device either in hard copy or electronic formats, such as on a website.
These materials include:
The intended purpose and functionality of the device will determine the device classification and the minimum conformity assessment procedures required.
The manufacturer must adhere to these procedures to include the device in ARTG, which authorises the product's supply in Australia.
Software updates can affect the intended purpose of a product and change its status for the purpose of regulation. If an update introduces new functionality – such as introducing diagnostic support, treatment recommendations, or clinical monitoring – the software may now meet the definition of a medical device, even if it was not previously regulated. In these cases the product may become subject to regulation and require ARTG inclusion.
For software that is already regulated as a medical device, updates that change the intended purpose could impact the device’s risk profile. Changes to risk profiles can change the device classification and may trigger additional regulatory obligations.
Manufacturers must assess the impact of updates on the software’s intended purpose and ensure ongoing compliance with the Therapeutic Goods Act 1989 and associated regulations.
The term software as a medical device (or SaMD) refers to software that:
SaMD includes, but is not limited to, AI, computer programs and applications, mobile apps, software as a service (cloud based), websites and browser-based products.
Software would generally be a medical device if it is intended to be used for:
In this context, ‘monitoring’ means active, clinical monitoring of a disease, injury or disability. Monitoring does not need to happen in real-time and can be done remotely.
This definition does not include software used for indirect activities, such as checking health records to see if someone qualifies for a screening program or is due for a medical assessment.
Examples of software as a medical device
Software that takes user input, such as a questionnaire, and uses this information to screen for a particular condition or disease.
A mobile phone app that connects via Bluetooth to a blood pressure cuff to obtain readings used to track the blood pressure in the individual wearing the cuff. This is a medical device as it is intended to be used to monitor symptoms related to a disease (such as hypertension).
Examples of software that is not a medical device
A smartwatch app that tracks the amount and intensity of physical activity of the user.
A videoconference web-portal solely intended to facilitate the scheduling and delivery of remote patient consultations with healthcare professionals.
Some SaMD may be an accessory to a medical device. This means the software is required by another medical device for that device to function as intended. Accessories are regulated as separate medical devices.
Software that is an accessory to a medical device is regulated as a medical device in its own right if it is supplied separately from the related device.
Example of software that is an accessory to a medical device
Software intended to allow clinical patient monitoring and assessment of treatment efficacy based on data transmitted from an implanted cardiac monitor from a personal computer or laptop. The software is supplied with the cardiac monitor.
Software can be part of a device when it is integral to the functioning of that device.
This kind of software is sometimes referred to as SiMD (software in a medical device) and is usually supplied preinstalled with the hardware device. SiMD is regulated as part of the device it is installed in.
Example of software that is part of a device
The embedded software or firmware in a cardiac pacemaker is regulated as a component of the pacemaker, because it is supplied as part of the device and is necessary for the device to function.
Some software, including mobile apps, can control or adjust a medical device through a connection, either physical or utilising wireless technology.
Where software drives or influences a medical device, the software has the same classification as the medical device it’s controlling.
Examples of software that controls a medical device
Pacemaker programmer and controller software for use on a personal computer or laptop.
An instance of cochlear implant configuration/optimisation software for use on a personal computer or laptop.
When determining the regulatory status of your software product, you may wish to follow these steps.
Is the software intended to be used in one or more of the following ways:
If your software is a medical device, you should determine if it is excluded from regulation. Excluded products are not required to meet our regulatory requirements. They do not need to be included in the ARTG before they are imported, exported or supplied.
See Software-based medical device exclusions to help determine if your software is excluded.
If your software is a medical device and is not excluded, you should determine if it is exempt. Exempt devices are still regulated by us and must meet some regulatory requirements, but they are not required to be included in the ARTG before they are imported, exported or supplied.
Certain types of basic Clinical Decision Support System (CDSS) software are exempt. Exempt CDSS software is a medical device but is not required to be included in the ARTG. See Exempt software as a medical device to help determine if your software is exempt.
Note
If your software is a medical device and is not excluded or exempt, it will need to be included in the ARTG before being supplied in Australia.
Software-based medical devices follow the same ARTG registration process as other medical devices.
Note
Evidence of manufacturer’s certification is not required for Class I devices. However, manufacturers will need to complete a declaration of conformity that their devices comply with the relevant regulatory requirements.
Overview of our regulatory pathway for medical devices, including software as a medical device
The manufacturer must show the device meets all relevant requirements for safety and performance by obtaining:
The sponsor applies to include the device in the ARTG. The application must include the appropriate evidence from Step 1.
We may audit the application. Audits can be mandatory or discretionary, depending on the type and risk level of the device.
If the application is approved, the device will be included in the ARTG. The sponsor must meet ongoing responsibilities, such as reporting problems and keeping up-to-date records.
Devices are classified based on their intended purpose and the level of harm they may pose, which is determined through factors including:
Classification is one of the factors used to determine minimum acceptable regulatory evidence.
There is a four-tier classification system for medical devices:
The higher the classification of the device, the higher the level of regulatory scrutiny.
The principles for applying the classification rules are provided under Part 3, Division 3.1, Regulation 3.3 of the Therapeutic Goods (Medical Devices) Regulations 2002 (the Regulations).
The classification rules themselves are in Schedule 2 of the Regulations.
Note
For classification purposes all software based medical devices are considered to be active medical devices.
While all relevant classification rules will apply to all medical devices, there are specific classification rules for active medical devices and software based medical devices (referred to as “programmed, programmable, and software medical devices” in the Regulations). These rules can be found in Part 4 of Schedule 2 in the Regulations.
See Classifying active medical devices in Australia (including software-based medical devices) for detailed guidance on how the classification rules apply to software based medical devices.
Note
The classification rules referenced above do not apply to in vitro diagnostic (IVD) medical devices.
Schedule 2A of the Regulations has specific classification rules for IVDs.
Conformity assessment procedures outline the regulatory requirements that apply to manufacturers of medical devices, including software-based medical devices, when manufacturers choose to obtain Australian conformity assessment certification from us.
They include requirements for:
The classification of a medical device determines the minimum conformity assessment procedures apply. These procedures are used to demonstrate that the device meets the Essential Principles – safety and performance requirements for medical devices. This principles-based approach allows flexibility in how manufacturers can demonstrate compliance, supporting a wide range of technologies and innovation over time.
The level of regulatory oversight applied to a manufacturer’s compliance increases with the risk classification of the device. Higher-risk devices (e.g. Class IIa, IIb, or III) are subject to more rigorous scrutiny, while most Class I devices can be self-certified and do not require direct assessment by a third party.
There are different conformity assessment pathways depending on the classification and intended purpose of the device. For a summary of these procedures, see the Conformity assessment overview.
Manufacturers can also use evidence issued by a comparable overseas regulator that is comparable to the Australian conformity assessment requirements. For guidance on of the specific comparable overseas regulator assessments and approvals that you can use to support applications for inclusion of medical devices, see Use of market authorisation evidence from comparable overseas regulators and assessment bodies for medical devices (including IVDs).
To supply a medical device in Australia, the sponsor or manufacturer must be able to demonstrate their medical device meets all relevant Essential Principles.
Schedule 1 of the Therapeutic Goods (Medical Devices) Regulations 2002 describes the Essential Principles in full.
Essential Principles 1 to 6 are general and apply to all medical devices, including software and AI. There are a further nine Essential Principles relating to design and construction that apply to medical devices on a case-by-case basis.
Note
Manufacturers must consider all Essential Principles and decide which ones apply to their device. They must not assume that only some principles are relevant. Evidence must be provided to show compliance with each applicable principle.
The Essential Principles require a manufacturer to minimise risks associated with the design, long term safety and use of the device. Manufacturers need to ensure continuing compliance with the Essential Principles throughout the medical device life cycle.
Compliance with the relevant Essential Principles helps address various risks associated with software-based medical devices.
You can find more information at:
While all Essential Principles may be relevant to a software-based medical device, three apply specifically.
| Essential Principle | What it includes |
|---|---|
| 12.1 | Requirements for applicable devices, including for:
|
| 13.2(3) | Allowances for providing information, where applicable, electronically for software-based medical devices. |
| 13B | Requirements for the identification of current version and build number to be:
You can find more information at Complying with identification requirements for medical devices that contain software. |
Once a medical device is in the ARTG sponsors and manufacturers must continue to meet regulatory obligations.
These include:
See Understanding your post-market responsibilities for medical devices for detailed information on meeting post-market requirements.
Together with ANDHealth we’re delivering software-based medical device webinars and regulatory discussion sessions. For dates and how to book see ANDHealth website.
New Guidance page based on content from the former PDF ‘How the TGA regulates software based medical devices’.
New Guidance page based on content from the former PDF ‘How the TGA regulates software based medical devices’.
The Department of Health, Disability and Ageing acknowledges First Nations peoples as the Traditional Owners of Country throughout Australia, and their continuing connection to land, sea and community. We pay our respects to them and their cultures, and to all Elders both past and present.
© Commonwealth of Australia
