Software as a Medical Device (SaMD) Regulation in Australia

Excluded vs Exempt vs Regulated Software

Determining whether a digital health tool falls within TGA regulatory oversight is the first critical step for healthtech founders and clinical software architects:

• Excluded Software (Not Regulated as Medical Devices): Pure administrative practice management software, electronic appointment booking systems, billing software, general health and fitness trackers, and clinical reference libraries that merely display static text/guidelines without patient-specific calculation or recommendation.
• Exempt Software: Specific clinical decision support software (CDSS) that merely assists a healthcare professional by displaying reference information or validated clinical practice guidelines, provided the clinician can independently review the basis of the recommendation and does not rely on opaque 'black-box' automated outputs.
• Regulated Software as a Medical Device (SaMD): Software that processes, analyses, or calculates patient-specific data to generate diagnostic outputs, calculate drug dosages, drive treatment decisions, or operate autonomously.

The TGA SaMD Classification Matrix

Under Schedule 2 of the Regulations, SaMD is classified based on two interacting axes: the criticality of the healthcare situation and the significance of the information provided:

• Class I (Low Risk): Software intended to record patient-reported symptoms without diagnostic algorithms.
• Class IIa (Low-Moderate Risk): Diagnostic or monitoring software where erroneous output could lead to temporary impairment or reversible injury; or software providing clinical recommendations where a qualified clinician exercises clinical judgment before acting.
• Class IIb (Moderate-High Risk): Software used to diagnose or manage serious disease (e.g. cardiac monitoring algorithms, oncology radiation planning tools, automated ICU drug titrators) where an error could cause irreversible harm or death.
• Class III (High Risk): Autonomous diagnostic software for critical conditions where no clinician intervenes to verify outputs, or life-supporting implantable software.

Key Compliance Pillars for ARTG Inclusion

To successfully obtain ARTG inclusion for Class IIa and above, manufacturers must compile a comprehensive technical dossier demonstrating compliance with the Essential Principles:

1. Clinical Evaluation Report (CER): Exhaustive clinical literature review and clinical study data proving safety, clinical performance, and favourable benefit-risk ratio in Australian clinical populations.
2. Software Lifecycle Documentation (IEC 62304): Documented architectural design, safety classification, unit testing, and configuration management.
3. Cybersecurity and Data Integrity: Threat modelling, secure cryptographic storage, vulnerability penetration testing, and software Bill of Materials (SBOM) compliant with TGA cybersecurity guidelines.
4. Certified Quality Management System: Third-party certification of ISO 13485 compliance by an authorized Conformity Assessment Body.

Post-Market Vigilance & Regulatory Reporting

Once included on the ARTG, the manufacturer must maintain continuous post-market monitoring. Any Adverse Event—defined as an incident where software malfunction contributed to, or could have contributed to, death or serious injury—must be formally reported to the TGA Medical Device Vigilance Program within statutory timeframes (within 48 hours for immediate threats, or 10 days for serious injury).