For companies developing software and AI for healthcare applications, intellectual property and regulatory strategy are not entirely separate exercises. The functionality being developed, the intended medical purpose of that functionality, and changes made as the technology evolves can affect both the scope of the intellectual property being developed and the regulatory pathway required to commercialise the product in Australia.

Software is playing an increasingly important role in the development of medical devices. It may operate as a standalone product, form part of a physical medical device, or control or influence how a device operates. At the same time, advances in artificial intelligence (AI) are driving new applications in medical device software, including tools used for medical imaging, diagnosis, monitoring and clinical decision-making.

The Therapeutic Goods Administration (TGA) regulates software and AI products that fall within the definition of a medical device under section 41BD of the Therapeutic Goods Act 1989, subject to applicable exclusions and exemptions.

For developers and manufacturers, determining whether a software or AI product falls within the medical device framework is an important early consideration when developing and commercialising a product in Australia.

What does the TGA mean by software and AI?

The TGA uses “software-based medical devices” as a broad term covering different types of medical device software. Its current guidance identifies four main categories:

• Software as a medical device (SaMD): software that has an intended purpose that meets the definition of a medical device and operates on a general computing platform, such as a computer, smartphone or tablet, rather than dedicated medical device hardware.
• Software that is an accessory to a medical device: software that is required by another medical device to function as intended.
• Software that is part of a medical device: sometimes referred to as SiMD (software in a medical device), is software that is integral to the functioning of a physical medical device, such as embedded software or firmware.
• Software that controls a medical device: software that controls or adjusts a medical device, including through a physical or wireless connection.

(see TGA: Understanding how we regulate software-based medical devices)

The TGA defines artificial intelligence (AI) as a broad term covering software technologies designed to perform tasks that typically require human intelligence. AI includes technologies such as machine learning, deep learning, neural networks, large language models, generative AI, natural language processing and computer vision.

AI can therefore be incorporated into different types of software-based medical devices, depending on the product's intended purpose and functionality.

(see TGA: Artificial intelligence (AI) and medical device software regulation)

If the software is a medical device, what level of regulation applies?”

Australia uses a risk-based classification system, and that software classification turns substantially on the significance of the information or functionality the software provides and the seriousness of the healthcare situation in which it is used. For example, software providing relatively low-risk information versus software whose output is used in diagnosis or treatment decisions where an incorrect result could cause serious deterioration or death.

When is a software or AI product a medical device?

Australia's medical device regulatory framework is technology agnostic, meaning that whether a product is regulated depends on its intended purpose and functionality rather than the technology used.

The starting point is section 41BD of the Therapeutic Goods Act 1989, which defines a medical device by reference to its intended purpose andfunctionality. The definition covers products intended for purposes including:

• the diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease;
• the diagnosis, monitoring, treatment, alleviation of or compensation for an injury or disability;
• the investigation, replacement or modification of anatomy or a physiological or pathological process or state;
• the control or support of conception; and
• the in vitro examination of a specimen derived from the human body for a specific medical purpose.

For software, the relevant question is therefore what the software is intended to do. The intended purpose is generally reflected in materials such as the manufacturer's instructions for use, labelling, advertising and technical documentation. The way a product is described and marketed may therefore be relevant to determining whether it falls within the medical device framework. (see TGA: Understanding how we regulate software-based medical devices)

Exclusions and Exemptions

Not all software that meets the definition of a medical device is subject to the full TGA regulatory framework. It is important to distinguish between excluded software and exempt medical devices.

The TGA currently identifies 15 categories of excluded software in schedule 1 of the Therapeutic Goods (Excluded Goods)Determination 2018, including certain health and wellness, administrative, communication, electronic health record, image management and clinical workflow software. (see TGA: Software-based medical device exclusions)

Some products that meet the definition of amedical device may nevertheless be exempt from inclusion in the ARTG. Theexemption criteria are set out in Schedule 4, Part 2 of Therapeutic Goods (Medical Devices)Regulations 2002 .An exempt medical device remains subject to certainregulatory requirements such as advertising requirements, adverse eventreporting obligations, and requirement to notify the TGA that the product isgoing to be supplied in Australia, but does not need to be included in theARTG. (see TGA: Exempt software as a medical device)

For example, certain clinical decision support system (CDSS) software may qualify for an exemption where it is intended to provide or support recommendations to a health professional, does not directly process or analyse a medical image or signal from another medical device, and is not intended to replace the clinical judgement of a health professional. (see Therapeutic Goods (Medical Devices) Regulations 2002, Schedule 4, Part 2, item 2.15 and TGA: Understanding clinical decision support system software regulation)

For software with multiple functions, it is also important to consider whether each function satisfies the exclusion or exemption criteria for the product to be excluded or exempt from inclusion in the ARTG.

What does the TGA require?

Where software or AI product satisfies the definition of a medical device and is not excluded or exempt, it will need to be included in the ARTG before it can be supplied in Australia.

The regulatory pathway broadly involves:

1. Establishing conformity: the manufacturer must demonstrate that the device meets the applicable safety and performance requirements, including through conformity assessment or, where available, appropriate evidence from a comparable overseas regulator.
2. ARTG application: the sponsor applies to include the device in the ARTG and provides the required supporting evidence.
3. TGA assessment: the TGA may audit the application, depending on the type and risk classification of the device.
4. Ongoing compliance: following ARTG inclusion, the sponsor remains responsible for post-market obligations, including monitoring the device, reporting adverse events and maintaining appropriate records.

(see TGA: Understanding how we regulate software-based medical devices)

The requirements that apply will depend on the classification and intended purpose of the software. Software-based medical devices are classified according to the level of risk associated with their intended purpose and functionality. Where software drives or influences another medical device, its classification may also be affected by the device it controls. (see TGA: Classifying active medical devices, including software-based medical devices)

There are also some differences for in vitro diagnostic (IVD) medical device software. IVD software is subject to specific classification rules and regulatory requirements that differ from those applicable to other software-based medical devices. Developers of IVD software should therefore consider the specific regulatory framework for IVDs in addition to the general requirements that apply to software-based medical devices. (see TGA: In vitro diagnostic medical device software and TGA: Understanding how we regulate software-based medical devices)

Software updates and regulatory status

Software can evolve significantly after it is first developed or placed on the market. Changes to functionality may also affect whether a product falls within the TGA's medical device framework.

For example, adding functionality that supports diagnosis, recommends treatment or enables clinical monitoring could cause software that was previously outside the medical device framework to become a medical device. In that case, the product may become subject to TGA regulation and require inclusion in the ARTG.

For software that is already regulated as a medical device, changes to its intended purpose or functionality may alter the level of risk associated with the device. This may affect its classification and the regulatory requirements that apply.

Manufacturers should therefore consider the regulatory implications of significant software changes throughout the product lifecycle and assess whether updates affect the product's intended purpose, classification or ongoing compliance obligations.

(see TGA: Understanding how we regulate software-based medical devices)

Conclusion

Software and AI are increasingly being incorporated into medical devices, and the TGA's regulatory framework applies to a broad range of software-based medical devices.

For developers and manufacturers, the key questions are whether the product meets the definition of a medical device, whether an exclusion or exemption applies, and what classification and regulatory requirements follow. These questions should be considered early in development and revisited as the software, intended purpose or AI functionality evolves.

Understanding the regulatory requirements early can help developers plan the pathway from product development through to commercialisation and ensure that regulatory, technical and compliance considerations are addressed throughout the product lifecycle.

For more information about regulatory and IP considerations for software and AI medical devices in Australia, please contact Dr Catrina Olivera or Daniel McKinley.