Is it a medical device?
Start with the intended purpose, functions, claims, users and clinical role—not the technology label.
Software & AI medical devices
When does software become a medical device?
A practical Australian starting point for founders, developers, clinicians and digital-health teams working with SaMD, clinical decision support and AI-enabled products.
General information · Australian-focused · Verify current requirements
Choose your starting point
What do you need to understand first?
The regulatory decision path
Medical purpose is only the beginning of the assessment
A complete Australian review moves through the medical-device definition, exclusions, exemptions, classification and the evidence required for the proposed market-access pathway.
Is any function excluded?
Check each software function against the Australian exclusions before assuming the complete product is outside TGA regulation.
Could an exemption apply?
Some medical-device software, including limited CDSS, may be exempt from ARTG inclusion while remaining regulated.
What class and pathway apply?
Apply every relevant rule to the full intended purpose, then plan evidence, sponsorship, ARTG inclusion and post-market obligations.
Software as a Medical Device
SaMD performs a medical purpose without dedicated medical-device hardware
In Australia, software may be a medical device when its intended purpose includes diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease, injury or disability, or another purpose within the medical-device definition.
Not every healthcare app is a medical device. Administrative, communication, information-management and general-wellness functions can have a different regulatory outcome, depending on their claims and precise functionality.
Functions that may require assessment
- software that detects, diagnoses, screens or monitors a condition
- medical-image or physiological-signal analysis
- patient-specific risk prediction or prognosis
- treatment or intervention recommendations
- digital therapeutics and information-based therapy
- software that controls or influences another medical device
Artificial intelligence & machine learning
AI does not decide device status—but it changes the evidence conversation
Once AI forms part of a medical device, manufacturers need transparent evidence showing how the model supports the intended purpose and how safety and performance are maintained across the lifecycle.
01Purpose & model role
Explain what the model does and how it contributes to the device’s intended purpose.
02Data
Justify training and testing datasets, population representation and relevance to the intended users.
03Performance
Plan analytical and clinical validation using metrics that are meaningful for the intended use.
04Risk
Address bias, overfitting, data drift, cybersecurity, foreseeable misuse and incorrect outputs.
05Human oversight
Define how users interpret results, where clinical judgement remains, and how limitations are communicated.
06Change control
Assess model updates, new features and changed claims before release, then monitor performance after supply.
Australian classification
Classification reflects intended purpose and potential harm
Software-based medical devices are active medical devices. All relevant rules must be considered, and the highest applicable classification governs the device as a whole for ARTG inclusion.
Applies where no higher classification rule governs the intended purpose.
May apply to certain diagnostic, monitoring, treatment or information functions.
May apply where incorrect outputs could lead to serious deterioration or intervention.
May apply where the intended purpose and consequence of failure meet the highest-risk rules.
Clinical Decision Support Software
CDSS needs its own boundary assessment
Some limited CDSS medical devices can be exempt from ARTG inclusion if every exemption criterion is met. Software that analyses medical images or signals, replaces clinical judgement, or provides advanced patient-specific diagnostic or treatment outputs is unlikely to meet that exemption. Exempt CDSS remains subject to specified obligations.
From concept to Australian supply
Build regulation into the product before evidence gaps become expensive
Early choices about claims, users, architecture, datasets and clinical validation can affect the later classification, evidence burden and ARTG pathway.
01Define intended purpose
Describe the product, intended users, patient population, medical purpose, inputs, outputs and clinical decisions influenced.
02Determine regulatory status
Assess the medical-device definition, then test relevant exclusions and exemptions for every function.
03Determine classification
Apply all relevant Australian classification rules and use the highest applicable class.
04Build the evidence system
Plan quality management, risk management, software verification and validation, clinical evidence, usability and cybersecurity.
05Prepare for Australian market entry
Confirm manufacturer evidence, the Australian sponsor, the ARTG route, labelling and application readiness.
06Manage the lifecycle
Control updates, complaints, adverse events, performance monitoring, recalls and regulatory changes.
Interactive assessment · in development
Is My Software a Medical Device?
The future assessment will guide visitors through intended purpose, functions, users, possible exclusions or exemptions, clinical impact and the next regulatory question—without presenting the result as a formal TGA determination.
View the assessment roadmap- 1
PurposeWhat medical outcome is intended?
- 2
FunctionWhat does the software analyse or provide?
- 3
Decision impactHow could the output influence care?
- 4
BoundaryCould an exclusion or exemption apply?
- 5
Next stepWhat should be assessed next?
Coming soon
SaMD Regulatory Starter Kit — Australia
Turn an early software concept into a structured regulatory plan
A practical self-guided toolkit for software, digital-health and AI teams that want to organise the right regulatory questions before engaging specialist support.
Register your interest Educational resource in development. It will provide general information and planning tools, not a TGA determination, legal advice or product-specific regulatory advice.01
Device status & boundariesStatus assessment plus exclusion and exemption worksheets.
02
Intended purpose & classificationIntended Purpose Builder plus the SaMD classification worksheet.
03
Australian pathway & ARTG readinessPathway map and a practical ARTG readiness checklist.
04
Risk, verification & clinical evidencePlanning checklists for risk, software V&V and clinical evidence.
05
AI/ML & cybersecurityAI development, validation and cybersecurity planning tools.
06
Quality system & regulatory strategyAn early QMS roadmap and regulatory strategy template.
Primary sources
Check current requirements with official TGA guidance
Regulatory legislation and guidance change. These official resources are the starting point for confirming current Australian requirements.
Software regulationUnderstanding how the TGA regulates software-based medical devicesAI evidenceEvidence requirements for software using AIClassificationClassifying active and software-based medical devicesCDSSUnderstanding clinical decision support system software regulation
Information on this page is general in nature and should not be relied upon as a determination of the regulatory status, classification or approval pathway for a particular product.