How the TGA Regulates Software as a Medical Device (SaMD) in Australia

How the TGA regulates software as a medical device (SaMD) in Australia

Australia's Therapeutic Goods Administration (TGA) regulates software as a medical device under the same framework that governs physical devices: the Therapeutic Goods Act 1989 and the Therapeutic Goods (Medical Devices) Regulations 2002. What changed in recent years is the precision with which software is classified and the number of carve-outs that keep low-risk digital health products out of scope. This overview walks through the definition, the risk classification rules, the treatment of clinical decision support software (CDSS), the excluded-software regime, and the exemptions that permit supply without ARTG inclusion.

What counts as software as a medical device

The TGA treats software as a medical device (SaMD) as software whose intended purpose meets the medical device definition and that operates via a general computing platform (computer, smartphone or tablet) rather than dedicated hardware. It spans AI, standalone programs, mobile apps, software as a service (cloud-based), websites and browser-based products ¹⁵⁹. Software is generally a medical device if it is intended for diagnosis, prevention, monitoring, prediction, prognosis or treatment of a disease, injury or disability, or for compensation for an injury or disability ¹⁵⁹. Software used only for general health or lifestyle purposes is not regulated unless it meets that definition ⁹¹.

How a product is regulated turns on intended purpose and how it is supplied:

Software built into a device, or preinstalled firmware, is regulated as part of that device, not as a separate product ²⁰⁵²⁰⁹¹⁵⁸.
Software that controls or influences a medical device carries the same classification as the device it controls ²⁰⁵⁵⁹⁷²⁶⁶.
Software that is an accessory to a medical device is regulated as a medical device in its own right when supplied separately ²⁰⁹⁶⁶.
Software intended to provide diagnostic or therapeutic information, or to perform diagnosis, monitoring, prediction, prognosis, treatment, alleviation, compensation, anatomical/physiological modification, contraception, or to act as an accessory, may be a medical device ¹⁴¹¹⁶².

If software does not carry one of the medical-device purposes, it is not a medical device and is not regulated by the TGA ²⁰⁷¹⁶². If it is a medical device, it must be included in the Australian Register of Therapeutic Goods (ARTG) before supply, unless it is excluded or exempt ²⁰⁴⁹¹. In-vitro diagnostic (IVD) software is also regulated, but under different classification rules and with some distinct exemptions, including for certain in-house IVDs ⁹¹²¹².

The February 2021 software classification reforms

The Medical Devices Regulations were amended to clarify existing requirements and introduce new requirements for software-based medical devices, with changes commencing in February 2021 ²¹⁴. All new ARTG applications had to meet the new classification rules from 25 February 2021, with a transition period that ended 1 November 2024 ⁵⁶. Where a reclassification pushed an already-listed software device into a higher class, transition arrangements allowed continued supply while the sponsor applied to include the device at the new, higher classification ⁵⁶⁷⁰.

Classification rules for SaMD

For classification purposes, software-based medical devices are treated as active medical devices, and the rules are applied according to the manufacturer's intended purpose and how the device works. Where more than one rule applies, the device is classified at the highest applicable level, and each individual function is assessed against the rules with the highest class governing the device as a whole for ARTG inclusion ⁶¹⁶⁶⁷². If a device is driven or influenced by software, the software takes the same classification as the device it drives ⁶⁶⁷²¹¹⁸. The active-device rules do not apply to IVD medical devices, which follow separate Schedule 2A rules ⁶¹⁷³.

The binding classification tests in the Regulations, and the matching TGA guidance rules, are risk-tiered. The recurring principle is that software making an autonomous decision or delivering a result directly to a lay user attracts a higher class than software that merely informs a health professional who remains the decision-maker.

Diagnosis or screening (Rule 4.5). Applies to active devices that process data to provide a diagnosis, or to screen for the potential presence, of a disease or condition ⁵². If the device performs the decision-making itself and gives the diagnosis/screening result directly to the user, classification is higher; if it only provides information to a relevant health professional who makes the final decision, classification is lower ⁵²⁵⁶. In the Regulations, software that provides a diagnosis or screens is Class III where the condition may lead to death or severe deterioration without urgent treatment (or poses high public-health risk), Class IIb for a serious disease/condition or moderate public-health risk, otherwise Class IIa; where the software only provides information to a health professional for diagnosis, the tiers step down to Class IIb / IIa / I ¹¹². Example: analysing a mammogram to aid a health professional's diagnosis of breast cancer is Class IIb; providing information to a GP to aid diagnosis of diabetes is Class IIa ⁵¹⁵⁵.

Monitoring the state or progression of a disease (Rule 4.6). Software providing information to monitor the state or progression of a disease or condition is Class IIb if the information may indicate immediate danger or high public-health risk, Class IIa for other danger or moderate public-health risk, and Class I otherwise ⁵⁵¹¹¹.

Specifying or recommending treatment or intervention (Rule 4.7). Software that processes data to specify or recommend a treatment or intervention is Class III where absence of the treatment (or the treatment itself) may lead to death, severe deterioration, or high public-health risk; Class IIb where otherwise harmful or moderate public-health risk; otherwise Class IIa. Where the software instead recommends to a relevant health professional for their decision, the tiers drop to Class IIb / IIa / I ⁵⁷¹¹⁴. Example: software recommending coronary artery bypass grafting to a cardiac surgeon is Class IIb; recommending corneal surgery for keratoconus to an eye surgeon is Class IIa ⁶³⁶⁸.

Providing therapy through information (Rule 4.8). Software that provides therapy to a person through the provision of information is Class III if the therapy may result in death or severe deterioration, Class IIb if it may cause serious harm, Class IIa if it may cause harm, and Class I otherwise ¹¹³⁵³.

Recording images and anatomical models (Rule 5.4). Software intended to record patient images, or to create or generate virtual anatomical models, is generally Class IIa; for example, software generating a virtual anatomical model from patient scans to assist diagnosis is Class IIa ⁵³⁵⁴⁵⁸⁶⁴¹¹⁵. Note the boundary with Rule 4.5: if the software also captures and analyses an image to provide a specific diagnosis, the diagnosis rule applies instead ⁵⁴⁵⁸.

Clinical decision support software (CDSS)

CDSS sits at the most contested boundary of the framework. The TGA's approach is to exempt transparent, evidence-based decision-support tools that assist rather than replace the clinician, while keeping opaque, diagnostic, image-analysing or alerting tools inside regulation ¹⁹⁴¹⁸²¹⁸⁹¹⁹⁰.

To fall within the CDSS exemption, software must be evidence-based and transparent, support (not replace) the clinician's judgement, and generate recommendations the clinician can independently verify ¹⁸³¹⁸⁴¹⁸⁶¹⁸⁷. Critically, it must not process medical images or signals from other medical devices ¹⁸²¹⁸⁶¹⁸⁷. The TGA describes qualifying systems as "glass box" models, such as computerised flowcharts built on decision-tree logic and established clinical guidelines, where the underlying logic can be reviewed by the clinician ¹⁸⁴¹⁸⁵. Examples of exempt CDSS include computerised clinical scoring tools based on a published, referenced score; EMR asthma modules built on published evidence-based guidelines; and thromboembolism risk-assessment tools that generate options the clinician selects and signs off ¹⁸³¹⁸⁴¹⁸⁶¹⁸⁷¹⁹².

What is not exempt: "black box" tools whose logic cannot be reviewed (opacity alone fails the exemption) ¹⁸³¹⁸⁴¹⁸⁵; CDSS that provides a diagnosis ¹⁸⁹; tools that analyse x-rays or other medical images ¹⁸⁸¹⁸⁹; and evidence-based monitoring/alert tools (for example, sepsis tools) that do not reference or step through the logic behind their alerts ¹⁹⁰. Separately, a GP Management Plan tool that only extracts EMR information without analysing or summarising it is not a medical device at all, because it has no therapeutic purpose ¹⁹¹¹⁹³, and software forming part of an IVD process (such as combined maternal-screening interpretation) is regulated as IVD interpretive software rather than CDSS ¹⁸⁸¹⁹⁰.

Excluded software: the Excluded Goods Determination 2018

Beyond exemptions, a substantial body of low-risk software is excluded from TGA regulation altogether by the Therapeutic Goods (Excluded Goods) Determination 2018. Excluded software does not need to meet device requirements or be included in the ARTG, and the developer, manufacturer or sponsor is responsible for confirming that a product fits a specific Schedule 1 item before supply ¹⁴⁹²³¹²³²²³³. The TGA states there are currently 15 excluded software categories, and the mechanism is category-based and item-specific, with some exclusions conditional ²³¹²³²²³³.

Categories identified in the guidance include: general consumer health or wellness software ²³²; behavioural change or coaching software (weight, exercise, sun exposure, diet) ²³⁵²⁴⁵; health self-management software for a non-serious existing condition (item 14A) ¹¹¹⁷; digital mental health tools including CBT tools, on conditions discussed below (item 14E) ⁷⁹¹⁰; communications software enabling delivery of health services ²³⁸; health facility management software (item 14G) ¹⁴⁶; health alert software that solely provides alerts to health professionals ²⁴²; image storage and transmission software ²⁴³; patient survey / PROMs software ¹⁵¹²⁴⁴; calculator software (item 14L) ⁵¹⁹; clinical workflow management software ¹⁴⁰²⁴⁰; middleware connecting applications ²³⁹; laboratory information management software (item 14O) ⁴¹⁶; electronic health record software ²³¹; and certain population-based analytics software ²³³.

Two boundary points recur. First, several exclusions are conditional: for instance, the digital mental health exclusion only applies where the tool is based on established clinical practice guidelines that are referenced and displayed within the software in a manner reviewable by the user ¹⁴⁷¹⁶⁷. Second, adding analytical logic can pull a product back into regulation: software that merely digitises a paper questionnaire for data collection is not a medical device, but adding interpretive logic may bring it into scope ¹⁶⁷.

Distinct from exclusions under the Determination, two legislative instruments define the outer boundary of "medical device" itself: the Therapeutic Goods (Articles that are Not Medical Devices) Declaration 2023 lists article classes that are not medical devices ¹⁰¹, and the Therapeutic Goods (Medical Devices - Specified Articles) Instrument 2020 specifies classes that are medical devices, including several that reference the software necessary for their proper application ¹⁰²¹⁰³.

ARTG exemptions and alternative supply pathways

If software is a medical device and is neither excluded nor covered by the Determination, it must be included in the ARTG before supply, unless an exemption applies ²⁰⁴⁹¹. A key distinction: exempt devices are exempt from ARTG inclusion, not from regulation. They must still comply with the Essential Principles, labelling and instructions for use, advertising requirements and adverse-event reporting ¹³⁵⁷⁹¹²¹⁷. Exemption examples relevant to software and personalised devices include custom-made devices, some low-volume patient-matched devices, certain CDSS, and some devices made by health practitioners in clinical practice ¹³⁵⁷⁹¹²¹⁷.

The main pathways to supply an unapproved (non-ARTG) medical device, including software, are:

Clinical trial exemptions, used for devices supplied in a trial where full ARTG documentation is not available ³.
Special Access Scheme (SAS), an access route for individual patients ⁶¹⁹.
Authorised Prescriber scheme, supported by an exemption in the Act that lets authorised prescribers supply unapproved goods ⁴⁶¹¹¹⁹.
Personal Importation Scheme, one of the identified import/supply routes for unapproved devices ⁶¹⁹.

The TGA guidance flags these as the pathways to consider but does not, in the material reviewed here, set out the full eligibility conditions for each; sponsors should confirm the current SAS, Authorised Prescriber and personal-importation criteria before relying on them.

Essential Principles, standards and version identification

Software-based medical devices must meet the Essential Principles for safety and performance. The TGA identifies IEC 62304 (software life-cycle processes) and IEC 62366 (usability engineering) as the key standards representing the state of the art for software design and usability ²¹³¹⁶³. Devices are expected to be developed and maintained with regard to the generally acknowledged state of the art across design, development life cycle, development environment, version control, quality and risk management, security, verification and validation, change and configuration management, and problem resolution ²⁵². Where the software runs on a general computing platform, its design must account for the platform's capability, resources, configuration and external IT environment, and the manufacturer must supply the hardware, software, IT-environment and security requirements needed to run it as intended ²⁵². Cybersecurity is explicitly in scope: protection against unauthorised access or manipulation, vulnerability mitigation, updates and patches, vulnerability disclosure, and information supporting user decisions about applying updates ²⁵².

Two labelling principles are software-specific. Essential Principle 13 requires that product information and labelling, including the graphical user interface, screenshots, electronic-media labels and product demonstrations, meet the labelling requirements, whether the software is downloaded, installed from electronic media, or preinstalled ²¹³¹⁶³. Essential Principle 13B requires devices that are, or incorporate, software to make the current version number and current build number accessible to and identifiable by users, in English (other languages may also be shown); devices included in the ARTG after 25 February 2021 must comply with EP 13B ²¹³²²².

Conformity assessment, ARTG inclusion and ongoing obligations

The route to market is sequential: determine whether the software is a medical device, then whether it is excluded or exempt; if neither, include it in the ARTG before supply ¹⁴¹¹⁵²¹⁶⁵. The manufacturer classifies the software, because classification sets the minimum conformity assessment procedures, then holds conformity-assessment evidence to support inclusion ¹⁷¹⁸¹. The sponsor applies to include the device in the ARTG with the appropriate evidence; applications may be subject to mandatory or discretionary audit depending on device type and risk ²²³. Evidence supporting inclusion includes technical documentation, advertising material and labelling where applicable, an Essential Principles checklist demonstrating conformity, and, for software, verification and validation of the finished device (including testing in an actual user environment before final release) and confirmation that the current version and build number are accessible under EP 13B ¹⁷¹²²⁵²²⁷²²⁹²²².

Once listed, obligations continue. Sponsors and manufacturers must monitor performance and safety across the device lifecycle and respond to emerging risks; where a device no longer complies with the Essential Principles, the TGA may take action including recalls or non-recall actions ²⁴⁷. Sponsors must report adverse events, specified incidents and performance issues, and relevant overseas regulatory actions ²⁴⁶²⁴⁹. Software errors may be corrected through a product defect correction issued as a software update, and the TGA may require updated user information or additional post-market conditions such as user-support services or periodic distribution/performance reporting ²⁴⁷²⁴⁶²⁴⁸. ARTG entries for software may be subject to post-market review, with sponsors asked to provide samples or information for independent evaluation ²⁴⁸²⁴⁹.

Digital mental health software: a worked example of the boundary

Digital mental health software illustrates how definition, exclusion and classification interact. A digital mental health tool, including a CBT tool, is not a medical device where it is based on established clinical practice guidelines that are referenced and displayed within the software in a manner the user can review ¹⁴⁸⁵³. The guideline must be widely accepted for clinical use in Australia, typically published by professional bodies or accredited providers, and must be shown so users can easily see it (a link in a user manual is not sufficient; an in-app link may be) ¹⁶⁷. Where those conditions are not met, the software remains a regulated device: an app delivering CBT for bipolar disorder that does not reference an established guideline is given as a Class IIa example, and novel or still-under-trial treatments are not yet widely accepted and therefore remain regulated ⁵³¹⁶⁷. The TGA notes it is coordinating with the Australian Commission on Safety and Quality in Health Care on broader oversight of digital mental health services through the NSQDMH Standards ¹⁶⁷²⁵⁵.

For a specific product, the decisive questions are its stated intended purpose, whether it fits an Excluded Goods Determination item, and (if regulated) which classification rule bites and at what tier. Those determinations drive the conformity assessment route, the evidence package and the post-market commitments, and they are where most SaMD sponsors would want to press further.

How the TGA Regulates Software as a Medical Device (SaMD) in Australia