You are here
Understanding if changes to software-based medical device regulation affect you
Guidance about regulatory changes for software based medical devices, including software as a medical device (SaMD).
Recently published
This page was published on [date_placeholder].
Recently updated
This page was updated on [date_placeholder]. See page history for details.
Purpose
This guidance summarises changes to software-based medical device regulation that commenced on 25 February 2021.
It outlines transition arrangements available for devices that may need to be reclassified or that qualify for an exemption or exclusion from the Therapeutic Goods (Medical Devices) Regulations 2002.
Changes to software based medical devices
If a product is a medical device, it must be included in the Australian Register of Therapeutic Goods (ARTG), unless exempt, before it can be legally supplied in Australia.
Rapid innovation in technology has driven significant changes to software function and adoption, giving rise to a larger number of devices able to inform, drive or replace clinical decisions, or directly provide therapy to an individual.
Access to software has become much easier, with personal devices including smartphones,
wearables and tablets becoming ubiquitous, and improvements to network technology providing increased connectivity via technologies such as Bluetooth and Wi-Fi.
These rapid advances in computing technology and software production have led to a large increase in the number of software-based medical devices available on the market.
Following consultation with stakeholders including with global medical device regulators in 2019 and 2020, the Therapeutic Goods (Medical Devices) Regulations 2002 were amended by the government to clarify some existing requirements and to introduce new requirements for software-based medical devices.
The changes that commenced February 2021, include:
Excluded or exempt
The clarification of the boundary for software-based products regulated as medical devices in Australia is important to ensure sponsors and manufacturers of software-based products are not subject to unnecessary regulatory oversight.
From 25 February 2021, certain software-based medical devices were carved-out (through either an exemption or exclusion) from the scope of the TGA regulation, based on the following principles:
- align with international regulatory frameworks where appropriate
- reduce or remove unnecessary regulatory burden:
- by not regulating products where there is no significant risk to safety
- by not regulating where suitable frameworks for product or system oversight are already in place.
As a result, some exclusions and exemptions for specific types of software products have been introduced.
Exemption means that the TGA retains some oversight for advertising, adverse events and notification. Registration of the devices is not required.
Exclusion means that the devices are completely unregulated by the TGA.
Certain clinical decision support systems have been exempted. Exempt software is a medical device but is not subject to all regulatory requirements.
Further detail on exemptions including which products are covered and which requirements still apply can be found in the guidance for Clinical decision support software.
Other products have been excluded and are not subject to any TGA regulatory requirements.
The types of excluded products include:
Consumer health products
Prevention, management and follow up devices that do not provide specific treatment or treatment suggestions:
- software intended for self-management of an existing disease or condition that is not serious (without providing specific treatment or treatment suggestions)
- consumer health and wellness products (may be software or a combination of non-invasive hardware and software), excludes serious conditions
- behavioural change or coaching software intended to be used to improve general health or wellness factors (such as weight, exercise, sun exposure or dietary intake) that does not provide information to the consumer that would generally be accepted to require the interpretation of a health professional
- patient recorded outcome measures (PROMs) and patient surveys (including those that form part of an electronic health record)
- digital mental health tools (including a cognitive behaviour therapy tool) based on established clinical practice guidelines that are referenced and displayed in the software.
Enabling technology
For telehealth, healthcare or dispensing:
- communication software that enables telehealth consultations, including the transmission of patient information, for the purposes of supporting the delivery of health services
- software intended to administer or manage health processes or facilities, rather than patient clinical use cases
systems that are intended only to store or transmit patient images - software intended to provide alerts or additional information to health professionals in relation to patient care. The health professional can exercise their own judgement in determining whether to action the alert or information
- software embedded in delivery of health services (clinical workflow management software)
middleware that does not control IVD instruments or medical devices and does not recommend a diagnosis or make treatment decisions.
Digitisation
Of paper based or other published clinical rules or data including simple dose calculators and Electronic Patient Records:
- simple calculators that use relevant published clinical standards or authoritative sources to make calculations or display calculations and outputs so they may be validated by the user, but do not control the administration of a calculated dosage
- Electronic Patient Records (EMRs) and Electronic Health Records (EHRs) that use relevant published clinical standards or authoritative sources to make calculations or display calculations and outputs so they may be validated by the user, but do not control the administration of a calculated dosage.
Population based analytics
Data analytics that are for the collection and analysis of class, group or population data that are not intended to be used for clinical use cases for individuals.
Laboratory Information Management Systems
These systems include pathology and radiology use cases and typically allow laboratories to automate workflows, integrate instruments, manage orders and samples and associated information.
New classification rules
The new classification rules don't apply to in vitro diagnostics (IVDs).
On 25 February 2021 changes to the Regulations commenced to introduce new classification rules for programmed and programmable medical devices, and medical devices that are software.
This includes all software-based medical devices.
All new applications will need to meet the new classification rules from 25 February 2021, with a transition period ending 1 November 2024.
If the regulatory changes result in the re-classification of a software-based medical device that is currently included in the ARTG, you can access transition arrangements that will allow you to continue supplying the device while you apply to include it in the ARTG under the new, higher classification.
Diagnosis or screening
For software-based medical devices that provide a diagnosis or screen for a disease or condition, the classification depends on whether the device provides the diagnosis/screening directly, or whether a relevant health professional makes the diagnosis using information provided by the device.
This rule covers both software-based medical devices intended to be used for:
- the screening of apparently healthy, asymptomatic individuals to detect disease, abnormalities or risk factors
- the diagnosis of unwell individuals to determine a cause for symptoms.
The second part of this rule differentiates when it is intended the information is provided to a relevant health professional for the purposes of diagnosis.
The term ‘relevant’ describes the health professional with the appropriate expertise that uses the provided information to assist them in making a diagnosis; the information provided by a medical device under this classification rule is not to be solely relied upon for the diagnosis.
For example, a relevant health professional for diagnosis and treatment recommendations for certain forms of cancer would be an oncologist, whereas a general practitioner would not be a relevant health professional in that case.
However, a general practitioner could be a relevant health professional for diagnosing other sorts of diseases and conditions.
This rule also considers how serious the disease or condition that is being screened or diagnosed.
Serious, for a condition, ailment or defect, means a condition, ailment or defect that is:
- generally accepted as not being appropriate to be diagnosed or treated without consulting a medical practitioner, dentist or other kind of health care worker registered under a law of a State or Territory; or
- generally accepted to be beyond the ability of the average person to evaluate accurately, or treat safely, without supervision by a medical practitioner, dentist or other kind of health care worker registered under a law of a State or Territory.
Serious disease means a disease that:
- may result in death or long-term disability; and
- may be incurable or require major therapeutic interventions; and
- must be diagnosed accurately, to mitigate the public health impact of the disease.
Software intended for use in diagnosing for diseases or conditions that:
Examples
A software developer has produced software that performs an analysis of a photo of a patient’s skin, providing information intended to be used to make a diagnosis of malignant melanoma.
Scenario 1
The software is intended to provide the diagnosis to a relevant health professional only.
The instructions for use reflect the intended purpose and the software package is only sold to specialist healthcare facilities.In this instance the software-based medical device is a Class IIb medical device as the device provides information to a relevant health professional so that they can diagnose a serious disease that may lead to the death, or a severe deterioration in the state of a person’s health, without urgent treatment.
Scenario 2
There are no restrictions on the sale of the software, which can be used by anyone who has access to the results of a cardiac MRI to provide an analysis of the results and diagnosis.
In this instance the software would be a Class III medical device as it is intended by the manufacturer (the software developer) to provide a diagnosis for a serious disease to someone other than a relevant health professional, such as any member of the general public.
Software performs diagnosis or screening
A software-based medical device that is a medical device intended to provide a diagnosis or screen for a disease or condition will be classified as:
- Class III if the disease or condition may:
- lead to the death of a person without urgent treatment
- lead to a severe deterioration in the state of a person’s health without urgent treatment
- pose a high risk to public health
- Class IIb if 1. does not apply, but the disease or condition:
- is a serious disease or serious condition
- may pose a moderate risk to public health
- Class IIa if 1. and 2. do not apply.
Software intended to diagnose or screen for a disease or condition | ||
---|---|---|
Class IIIIn the case of diseases or
| Class IIbIn the case of diseases or
| Class IIaIn any case that does not meet |
Example
A software developer has produced an app that performs an analysis of images of a patient’s rash, providing information to the user for the purposes of screening for measles.
In this instance the software-based medical device is a Class IIb medical device as the software screens for a disease that:
- is a serious disease or serious condition
- may pose a moderate risk to public health.
A relevant health professional performs the diagnosis
A software-based medical device that is intended to provide information to a relevant health professional so they can diagnose a disease or condition will be classified as:
- Class IIb if the disease or condition may:
- lead to the death of a person without urgent treatment
- lead to a severe deterioration in the state of a person’s health without urgent treatment
- pose a high risk to public health.
- Class IIa if 1. does not apply, but the disease or condition:
- is a serious disease or serious condition
- may pose a moderate risk to public health.
- Class I if 1. and 2. do not apply.
Software intended to provide information to a relevant health professional to make a diagnosis | ||
---|---|---|
Class IIbIn the case of diseases or conditions that may:
| Class IIaIn the case of diseases or conditions that:
| Class IIn any case that does not meet any of the criteria listed for Class IIb or Class IIa. |
Example
A software developer has produced software that performs an analysis of a patient’s angiogram, providing information to a relevant health professional (e.g., a vascular surgeon) so they can make a diagnosis of acute arterial occlusion.
In this instance the software-based medical device is a Class IIb medical device as the device provides information to a health professional so they can diagnose a disease that may lead to the death or a severe deterioration in health of an individual without urgent treatment.
Monitoring
For software-based medical devices intended to provide information to monitor the state or progression of a disease or condition, the classification depends on both the potential risk to public health and whether the information could indicate if a person is in ‘danger’.
The Macquarie Dictionary defines danger as “liability or exposure to harm or injury; risk; peril”.
This rule considers both:
- immediate danger (danger occurring without delay)
- other danger (i.e., danger that is not immediate).
A software-based medical device that is intended to provide information to monitor the state or progression of a disease or condition, or the parameters in relation to the person will be classified as:
- Class IIb where the information could indicate:
- the person who has the disease or condition is in immediate danger
- another person may be in immediate danger
- there may be a high risk to public health.
- Class IIa where the information could indicate:
- the person with the disease or condition is in danger, but not immediate
- another person, may be in danger that is not immediate
- there may be a moderate risk to public health.
- Class I if 1. and 2. do not apply.
Software intended to monitor the state or progression of a disease or condition | ||
---|---|---|
Class IIbIn the case where the information to be provided could indicate that:
| Class IIaIn the case where the information to be provided could indicate:
| Class IIn any case that does not meet any of the criteria listed for Class IIb or Class IIa. |
Example
A software developer has produced a cloud-based, deep learning neural network that monitors patient recovery from shingles (herpes zoster) using uploaded images of shingles rashes.
The product can be accessed by health professionals or consumers – allowing real-time monitoring of recovery with or without oversight from a health professional.
In this instance the software-based medical device is a Class I medical device as:
- it is intended to monitor the state or progression of a disease
- the information provided does not indicate if an individual may be in danger
- there is a low public health risk.
Treatment or intervention recommendation
For software-based medical devices intended to specify or recommend a treatment or intervention, the classification depends on whether the device specifies or recommends the treatment or intervention, or whether the device recommends the treatment or intervention to a relevant health professional so that they may decide whether to action the recommendation using information provided by the device.
This rule covers both software-based medical devices intended to:
- directly specify a treatment or intervention (the software makes the decision)
- recommend a treatment or intervention (the user makes the decision).
The second part of this rule differentiates when it is intended to recommend (but does not specify) a treatment or intervention to a relevant health professional for the purposes that health professional deciding whether to action the recommendation.
The term ‘relevant’ describes the health professional with the appropriate expertise that uses the provided information to assist them in deciding about the treatment; the information provided by a medical device under this classification rule is not to be solely relied upon for the proposed treatment.
For example, a relevant health professional for performing a hip replacement would be an orthopaedic surgeon, whereas a general practitioner would not be a relevant health professional in that case.
However, a general practitioner could be a relevant health professional for treating other sorts of diseases and conditions.
This rule also references an intervention that may be ‘harmful’ to a person, other than causing the death of a person or a severe deterioration in the state of a person’s health.
The Macquarie Dictionary defines ‘harm’ as: “injury; damage; hurt: to do someone bodily harm”.
Under this rule, software will be Class I if the treatment or intervention (or its absence) cannot cause harm.
Software intended for use in specifying or recommending treatments or interventions
Software recommendations
A software-based medical device that is intended to specify or recommend treatment or intervention will be classified as:
- Class III where the treatment or intervention, or the absence of the treatment or intervention may:
- lead to the death of a person
- lead to a severe deterioration in the state of a person’s health
- pose a high risk to public health.
- Class IIb where the treatment or intervention, or the absence of the treatment or intervention:
- may be otherwise harmful to a person
- may pose a moderate risk to public health.
- Class IIa if 1. and 2. do not apply.
Software intended to specify or recommend a treatment or intervention | ||
---|---|---|
Class IIIIn the case where the absence of the treatment or invention-or where the treatment or intervention itself-may:
| Class IIbIn the case where the absence of the treatment or invention-or where the treatment or intervention itself-may:
| Class IIaIn any case that does not meet |
Example
A software developer produces software intended to perform an analysis of a patient’s coronary angiogram then, based on the results of the analysis, specifies coronary artery bypass grafting surgery as the appropriate treatment.
This software is a Class III medical device as:
- it is intended to specify a treatment or intervention
- the absence of this treatment, or the treatment itself, may lead to the death or a severe deterioration in health of an individual.
Software recommendations for a health professional
A software-based medical device that is intended to recommend a treatment or intervention to a health professional so the health professional can decide about a treatment or intervention will be classified as:
- Class IIb where the treatment or intervention, or the absence of the treatment or intervention may:
- lead to the death of a person
- lead to a severe deterioration in the state of a person’s health
- pose a high risk to public health.
- Class IIa where the treatment or intervention, or the absence of the treatment or intervention:
- may be harmful to a person
- may pose a moderate risk to public health.
- Class I if 1. and 2. do not apply.
Software intended to provide information to a relevant health professional to decide about treatment or intervention | ||
---|---|---|
Class IIIIn the case where the absence of the treatment or invention-or where the treatment or intervention itself-may:
| Class IIaIn the case where the absence of the treatment or invention-or where the treatment or intervention itself-may:
| Class IIaIn any case that does not meet |
Example
A software developer produces software intended to perform an analysis of a patient’s coronary angiogram and based on the results of the analysis, provides a recommendation to a cardiac surgeon to perform coronary artery bypass grafting surgery.
This software is intended only to be used by a relevant health professional (e.g., a cardiac surgeon).
This software is a Class IIb medical device as it:
- is intended to recommend a treatment or intervention to a relevant health professional for the purposes of that health professional deciding about the treatment or intervention; and
- is a case where the absence of this treatment, or the treatment itself, may lead to the death or a severe deterioration in health of an individual.
Information as therapy
For software-based medical devices intended to provide therapy through the provision if information, the classification depends on the potential to cause harm to the person using the information. For this rule, four levels of harm are referred to:
- harm that may result in the death of a person or a severe deterioration in the state of a person’s health
- serious harm
- harm that is not serious and will not harm that may result in the death of a person or a severe deterioration in the state of a person’s health
- no harm.
The Macquarie dictionary defines ‘harm’ as: “injury; damage; hurt: to do someone bodily harm”. ‘Serious’ has the same meaning as defined in the Therapeutic Goods (Medical Devices) Regulations 2002.
A software-based medical device intended to provide therapy to a person through the provision of information will be classified as:
- Class III if the therapy may result in:
- the death of the person
- a severe deterioration in the state of their health.
- Class IIb if both:
- 1. does not apply
- the therapy may result in serious harm to the person.
- Class IIa if both:
- 1. and 2. do not apply
- the therapy may cause harm to the person.
- Class I if 1. 2. and 3. do not apply.
Software intended to provide therapy through the provision if information | |||
---|---|---|---|
Class IIIIn the case of therapy that may result in:
| Class IIbIn the case of therapy which may cause serious harm to the person but which does not meet any of the criteria listed for Class III. | Class IIaIn the case of therapy that may cause harm to the person but does not meet any of the criteria listed for Class III or Class IIb. | Class IIn any case that does not meet any of the criteria listed for Class III, Class IIb or Class IIa. |
Steps you need to take
All applications for inclusion of software-based medical devices in the ARTG made after this date must meet these classification rules.
For sponsors and manufacturers of devices included in the ARTG that will need to be included at a higher classification as a result of the amendments to the Therapeutic Goods (Medical Devices) Regulations 2002, transition arrangements apply.
The transition period (ending 1 November 2024) applies to sponsors of eligible medical devices already included in the ARTG or included in the ARTG because of an application lodged before 25 February 2021.
Software intended to provide therapy to a person through the provision of information
Timeframe for changes to the new classification rules for software-based medical devices
If you want to continue supplying your eligible medical devices, you must:
- notify the TGA that you have an eligible inclusion by whichever is the later date
- before 25 August 2021
- within 2 months of the start date of your ARTG entry
- obtain the appropriate evidence of conformity assessment. See How the TGA regulates software
- apply for your medical device to be included in the ARTG under the new classification rules before 1 November 2024.
If you do not notify the TGA of your medical devices before 25 August 2021, you must cease supplying the medical device from 25 August 2021.
If you notify the TGA you have a device that must transition to a higher classification before 25 August 2021, you must submit an application for inclusion before 1 November 2024.
If you do not submit your application by 1 November 2024, you must cease supply on or before this date and cancel your inclusion.
If your application for inclusion is rejected, you are no longer eligible for the transition arrangements and must cease supplying your device immediately and consider cancelling your inclusion.
Notifying us
If you have identified that you need to notify the TGA you have an ARTG inclusion for a software-based medical device to be reclassified, you must notify the TGA using the online form.
For the notification, you will need to know:
- the ARTG inclusion number for the medical device
- for Class III medical devices, the unique product identifier for each medical device.
You must notify the TGA by the 25 August 2021 or 2 months after the start day of the ARTG entry.
Changes to the Essential Principles
Sponsors and manufacturers must demonstrate their medical devices meet the Essential Principles to supply them in Australia.
Medical devices must meet the Essential Principles for safety and performance.
Schedule 1 of the Therapeutic Goods (Medical Devices) Regulations 2002 describes the Essential Principles.
There are six general Essential Principles that apply to all medical devices.
There are a further nine Essential Principles about design and construction. These apply to medical devices on a case-by-case basis.
From 25 February 2021 the following changes that will impact programmed or programmable medical devices or software that is a medical device will be made to the Essential Principles:
- Essential Principle 12.1 is amended to clarify the existing requirements for:
- cyber security
- the management of data and information
- requirements relating to development, production, and maintenance.
- Essential Principle 13.2(3) is amended to allow information to be provided electronically rather than on a leaflet
- a new Essential Principle, Essential Principle 13B, will be introduced requiring the current version and build number for the software to be made accessible and identifiable to users of software-based medical devices. Information must be in English, but it can also be displayed in other languages.
Transition arrangements are available for medical devices already included in the ARTG to meet the new requirements imposed by the introduction of Essential Principle 13B.
There are no transition arrangements available for medical devices included in the ARTG for Essential Principles 12.1 and 13.2(3) as these changes are clarification of existing requirements and are not new requirements.
Steps you need to take
Medical devices included in the ARTG because of an application made before 25 February 2021 are automatically eligible for the transition period allowing them to continue being supplied without meeting Essential Principle 13B until 1 November 2024.
From February 2021, all software-based medical device applications must comply with Essential Principle 13B.
Summary of transition provisions for the new Essential Principles
Contact us
Contact us by emailing digital.devices@health.gov.au.
Page history
New template and update of links.
Update – finalise draft.
Include links for clinical decision support guidance.
Original publication.
New template and update of links.
Update – finalise draft.
Include links for clinical decision support guidance.
Original publication.