Healthcare Software Testing Australia: TGA Guide

Australia's digital health sector is undergoing the most significant transformation in its history. The My Health Record system now holds records for more than 23 million Australians. State-based electronic medical record (EMR) systems — including NSW Health's eMR, Victoria's EMR Connect, and Queensland Health's ieMR — are mid-rollout or recently completed. Telehealth volumes remain five times pre-pandemic levels. And a new generation of software-as-a-medical-device (SaMD) products — diagnostic algorithms, AI-powered imaging analysis, remote patient monitoring platforms — are entering the market at pace. Yet for all this growth, the testing rigour applied to Australian healthcare software remains inconsistent. The Therapeutic Goods Administration (TGA) has increasingly focused its regulatory attention on software products, and the consequences of inadequate testing — from patient safety incidents to regulatory action to high-profile EMR failures — are well documented.

What Is TGA Software Regulation in Australia?

The Therapeutic Goods Administration (TGA) is Australia's regulatory authority for therapeutic goods, including medical devices. Under the Therapeutic Goods Act 1989 and the Therapeutic Goods (Medical Devices) Regulations 2002, software intended to be used for a medical purpose is classified as a regulated medical device and must meet TGA requirements before it can be legally supplied in Australia. Software as a Medical Device (SaMD) is classified into four risk tiers based on the potential harm a failure could cause:

• Class I — Lowest risk: software that processes non-critical data or supports clinical workflows without direct diagnostic or treatment output
• Class IIa — Low-to-medium risk: software used to manage or analyse patient data where an incorrect output could cause indirect harm
• Class IIb — Medium-to-high risk: software that drives or influences clinical decisions where an incorrect output could cause serious harm
• Class III — Highest risk: software where a failure could cause death or serious injury, such as software controlling life-support equipment or implantable devices

The higher the classification, the more rigorous the conformity assessment requirements — and the more demanding the testing evidence TGA expects.

What Software Testing Does TGA Require for Medical Devices?

• Functional verification testing — demonstrating that the software performs its intended medical function correctly and consistently across all operating conditions, including boundary conditions and edge cases
• Safety testing — identifying and mitigating hazards where software failure could cause patient harm, typically guided by ISO 14971 risk management and IEC 62304 software lifecycle processes
• Regression testing — verifying that changes to the software do not introduce new defects into existing functionality, with full traceability from requirements through test cases to results
• Security and penetration testing — validating that patient data is protected against unauthorised access, particularly for connected devices and cloud-hosted SaMD platforms
• Usability testing — verifying that the user interface does not introduce use errors that could lead to patient harm, aligned to IEC 62366 usability engineering for medical devices
• Performance testing — ensuring the system meets response time requirements under realistic clinical load conditions, particularly for decision-support systems where delays impact patient care
• Integration testing — verifying correct data exchange with connected systems including My Health Record, pathology systems, imaging systems, and prescribing platforms
• Anomaly management — documenting and tracking all defects found during testing, and providing evidence that all safety-relevant anomalies were resolved before release

What Is My Health Record Integration Testing?

My Health Record is Australia's national digital health record system, operated by the Australian Digital Health Agency (ADHA). Under the My Health Records Act 2012, healthcare providers including hospitals, GPs, specialists, and pharmacies can connect to and contribute clinical documents to a patient's My Health Record. Software vendors building integrations must conform to ADHA's conformance requirements — covering HL7 FHIR R4 APIs, SNOMED CT terminology, secure messaging standards, and the National Clinical Terminology Service (NCTS). My Health Record integration testing covers five core areas:

• FHIR conformance testing — validating that FHIR resource submissions (Clinical Documents, Medication Records, Pathology Reports, Diagnostic Imaging Reports) conform to Australian-specific FHIR profiles in the ADHA's implementation guides
• Clinical terminology validation — verifying that SNOMED CT codes, LOINC codes, and AMT medication codes are applied correctly to clinical concepts
• Consent and access control testing — verifying that patient consent settings are respected and access control decisions are enforced correctly for restricted records and nominated representatives
• End-to-end workflow testing — testing complete clinical workflows from document creation through to My Health Record submission, retrieval, and display
• Conformance test environment testing — passing the ADHA's own conformance test suite before go-live approval in the production environment

Which Testing Standards Apply to Australian Clinical Software?

Australian healthcare software developers and testing teams need to be familiar with several overlapping standards and frameworks that govern clinical QA:

• IEC 62304 — Medical Device Software: Software Life Cycle Processes — the primary international standard referenced in TGA conformity assessments for Class IIa and above. Defines software safety classification (Class A, B, C) and required lifecycle activities: planning, architecture, implementation, testing, and maintenance
• ISO 14971 — Application of Risk Management to Medical Devices — the risk management framework driving safety testing priorities: identifying hazards, estimating risks, implementing and verifying controls
• IEC 62366 — Usability Engineering for Medical Devices — governs human factors and usability testing, requiring formative and summative usability studies for higher-risk software
• AS/NZS standards — various Australian and New Zealand standards apply in specific healthcare settings; state health departments typically require state-specific technical architecture compliance for public hospital EMR systems
• TGA AI/ML guidance — for AI-powered SaMD (diagnostic algorithms, clinical decision support, imaging analysis), the TGA has issued specific guidance including post-market performance monitoring as an ongoing testing obligation

How to Build a TGA-Compliant QA Programme: Key Principles

• Align your software safety class to your test depth — IEC 62304 Class C software (where failure could cause death or serious injury) requires unit testing, integration testing, system testing, and regression testing with full documentation; Class A requires far less. Start by classifying correctly.
• Establish traceability from day one — every test case must trace back to a software requirement, which must trace back to a safety/hazard control. TGA conformity assessments and clinical audits will look for this traceability matrix.
• Document defects as anomalies, not just tickets — IEC 62304 requires an anomaly resolution process. Every defect found in testing must be logged, triaged for safety impact, resolved or risk-accepted, and closed with evidence — not just marked 'done' in Jira.
• Test in a validated environment — your test environment must be representative of the production clinical environment. Testing in a degraded or partial environment and extrapolating to production is not acceptable for higher-risk devices.
• Plan for regression at every release — post-market changes to Class IIb and Class III software require a formal change management process with re-testing evidence. Build your regression suite as a long-term asset from the first release.
• Engage clinical stakeholders in UAT — usability testing by qualified clinical users (not developers or QA engineers playing the role of clinicians) is a core IEC 62366 requirement and a critical input into safety validation

KiwiQA provides end-to-end software testing services for Australian healthcare technology companies — from early-stage SaMD startups navigating their first TGA classification through to established health system vendors managing continuous delivery against IEC 62304 obligations. Our team includes engineers with direct experience in My Health Record integrations, state EMR programmes, and TGA regulatory submissions. Explore KiwiQA's testing services at kiwiqa.ai/security and kiwiqa.ai/automation, or speak with our healthcare QA team about your product's specific testing requirements.