Understanding if your software-based medical device is excluded from our regulation

There are 15 exclusions and one exemption for specific types of software products.

Excluded products are not subject to any TGA regulatory requirements.

Excluded products do not need to be included in the Australian Register of Therapeutic Goods (ARTG).

Not all software that is not a medical device is described by an exclusion (i.e., specified in the excluded goods order cited above).

If your product is not specified in the excluded goods order you need to consider whether it meets the definition of a medical device.

In this case, if your product does not meet the legislated definition of a medical device (as outlined in Section 42BD of the Therapeutic Goods Act 1989), it is not a medical device, and is not subject to any TGA regulatory requirements.

The groups of software excluded from regulation include:

• consumer health life-cycle prevention, management and follow up
• enabling technology for telehealth, remote diagnosis, and healthcare facility management
• digital mental health tools
• digitisation of paper-based other published clinical rules or data
• population-based analytics
• laboratory information management systems and laboratory information systems.

The software exclusions came into effect on 25 February 2021.

An exemption has also been introduced for some clinical decision support system (CDSS) software.

Further detail on the exemption, including which products are covered, and which requirements still apply can be found in the guidance for Clinical Decision Support Software.

Supplying excluded software in Australia

The following guidance should be viewed in conjunction with the Therapeutic Goods (Excluded Goods) Determination 2018, and you should refer to the legislative instrument when assessing if your product is excluded.

We recommend also assessing your product against:

• the definition of a medical device outlined in the Therapeutic Goods Act 1989
• the clinical decision support software exemption in the Therapeutic Goods (Medical Devices) Regulations 2002 (Medical Device Regulations)

If your product meets the conditions of an exclusion, it is not subject to TGA regulation.

Excluded products must not be included in the Australian Register of Therapeutic Goods (ARTG).

In that case, you do not need to take any further action with the TGA regarding that software.

If your software meets the definition of a medical device, and does not meet the requirements of an exclusion, it will be subject to TGA regulation.

In that case, (unless the product is exempt), you will need to apply for the software to be registered on the ARTG before you market, sell or distribute it in any way in Australia.

It is possible that some software products may have multiple functions – one or more of these functions may appear be excluded when each feature is considered in isolation.

The overall product will not be excluded unless all its individual functions meet the exclusion criteria.

Similarly, the exemption for clinical decision support systems (CDSS) does not apply where there are multiple functions that do not meet the CDSS exemption requirements.

The TGA has published general guidance on clinical decision support software and more detailed explanation of the exemption for certain clinical decision support software.

The following exclusions relate to consumer health products used for general health and wellness, or the prevention, management and follow up of existing conditions.

These products are not intended to be used in clinical practice or to manage serious diseases or conditions.

Software for self-management

Exclusion 14A applies to Software intended for self-management of an existing disease or condition that is not serious, without providing specific treatment or treatment suggestions:

14A software that is:

1. intended by its manufacturer to be used by a consumer for the self-management of an existing disease, condition, ailment, or defect that is not a serious disease or serious condition, ailment, or defect; and
2. not intended by its manufacturer to be used:
   1. in clinical practice; or
   2. in relation to a serious disease or serious condition, ailment, or defect; or
   3. for the purpose of diagnosis, treatment, or making a specific recommendation or decision about the treatment, of a disease, condition, ailment, or defect that is not a serious disease or serious condition, ailment, or defect

Understanding this exclusion

This exclusion is based on five questions.

If you answer ‘yes’ to the following two questions, the exclusion may apply:

1. Is your software intended for general consumer use?
2. Is your software for the self-management of an existing disease or condition?

If you answer ‘yes’ to any of the following questions, your software is not excluded:

3. Is the disease, condition, ailment or defect ‘serious’?
4. Is your software also intended for use in clinical practice?
5. Does the software diagnose, directly treat, or make specific treatment recommendations or decisions?

Definitions

Intended for

This means your software has been designed, produced, and will be marketed for a particular purpose (or purposes).

You must communicate and explain the purpose of your software to potential users, so they understand what it is for and what it is not for.

Self-management

This means the software will be used by a general consumer (or their carer) to manage an existing disease or condition and is not intended for use by a healthcare professional and/or in clinical practice.

If this is the case, then the software is 'intended for self-management' and could be excluded.

'Self-management', as distinguished from 'treatment', refers to enabling users to make healthy lifestyle choices (e.g., weight management and physical activity) that are medically accepted to help reduce the risk (e.g., of complications) or impact of an existing disease or condition.

If the general consumer shares information generated by your software with a healthcare provider but it is not used for diagnosis or treatment, the software is still 'intended for self-management' and it is excluded.

But, if the healthcare provider and/or the clinical practice does use the software-generated information for any diagnosis or treatment, the software is no longer 'intended for self-management'.

In this case, the software is not excluded.

Clinical practice

In this case means:

• a formal, professional medical scenario such as a GP clinic, pathology lab, health centre, hospital, vaccination centre, etc
• where a health professional or healthcare provider prescribes the software for use by a patient (i.e., formally advising a patient to use the software).

For a full definition of ‘health professional’, see the Therapeutic Goods (Medical Devices) Regulations 2002.

Existing

This means a disease or condition that may or may not have been previously diagnosed by a medical practitioner.

Disease condition, ailment or defect that is not serious

This means a disease or condition (including an ailment or defect) that:

• will not result in death or long-term disability
• can be cured
• does not need major therapeutic interventions (such as surgery)
• does not pose a risk or threat to the general public (e.g., it is not for self-management of a serious infectious disease)
• the average general consumer can evaluate accurately and safely self-manage by making choices towards a healthy lifestyle without the supervision of a medical practitioner, dentist, or other kind of state- or territory-registered healthcare worker.

A disease or condition must meet all these requirements to be defined as 'not serious'.

If your software is intended to be used for a disease or condition that is serious then this exclusion does not apply, and your software will come under the TGA regulations.

Serious vs not serious: examples of diseases or conditions

An example of a serious condition is diabetes.

Diabetes is considered serious as it requires the intervention of a health professional to be evaluated and treated effectively.

An example of a condition that is not serious is a mild headache.

A general consumer could reasonably evaluate whether they have a mild headache and manage it safely.

Without providing specific treatment or treatment suggestions

This means your software is restricted to monitoring and reporting on the current state of a disease or condition and helping with self-management only.

Your software only provides information that can help the user track the state of the disease or condition or self-manage it.

It does not provide anything more than this information.

This also means your software is not intended to be used:

• for diagnosing, treating, or giving treatment and diagnostic advice, or
• for making any recommendations or decisions about treating a disease or condition.

If your software is intended to be used for any of these tasks, then this exclusion does not apply, and your software will come under the TGA regulations.

Next steps

Follow the flow diagram to see if your software is excluded or not.

Excluded

Example

An app that enables a user to self-manage tinnitus by describing techniques to the user for the purposes of improving well-being and reducing the level of tinnitus-related annoyance.

Explanation

The software is intended for self-management of a non-serious disease, condition, ailment, or defect (tinnitus) and does not make recommendations or decisions about treatment.

Not excluded

Example

An app that is intended to be used by a health professional to diagnose tinnitus and determine appropriate sound therapy for treatment.

Explanation

Even though tinnitus is considered a non-serious condition, this software is intended for the:

• diagnosis of a condition that is not serious
• treatment of tinnitus by a health professional (so, not self-management).

Example

An app that is intended to be used by a general consumer to manage their pre-existing diabetes.

The app allows users to view their blood glucose levels, track trends overtime, and provides alerts if the levels are outside pre-set ranges.

Explanation

This software is intended for the management of a serious condition – diabetes.

The app relies on tracking of blood glucose levels and not on encouraging choices towards a healthy lifestyle such as weight management, healthy eating, or physical activity.

General health and wellness

Exclusion 14B applies to software intended to be used by a consumer to promote or facilitate general health or wellness by measuring or monitoring (through non-invasive means) a physical parameter, such as movement, sleep, heart rate, heart rhythm, temperature, blood pressure or oxygen saturation:

14B software, or a combination of software and non-invasive hardware, that is:

1. intended by its manufacturer to be used by a consumer to promote or facilitate general health or wellness by measuring or monitoring (through non-invasive means) a physical parameter, such as movement, sleep, heart rate, heart rhythm, temperature, blood pressure or oxygen saturation; and
2. not intended by its manufacturer to be used:
   1. in clinical practice; or
   2. for the purpose of diagnosis, screening, prevention, monitoring, prediction, prognosis, alleviation, treatment, or making a recommendation or decision about the treatment, of a serious disease or a serious condition, ailment or defect

Understanding this exclusion

This exclusion is based on four questions.

If you answer ‘yes’ to the following two questions, this exclusion may apply:

1. Is your product (software, or a combination of software and non-invasive hardware), intended for general consumer use?
2. Is your product intended to promote and/or facilitate general health or wellness by measuring and/or monitoring a physical parameter through non-invasive means?

However, if you answer ‘yes’ to any of the following, your software is not excluded:

3. Is your product also intended for use in clinical practice?
4. Does your product make claims about a serious disease, condition, ailment, or defect?

Definitions

Non-invasive hardware/non-invasive means

An invasive device is described as a medical device intended to be used to penetrate the body either through an orifice or body surface (e.g., the skin).

For the full definition, see the Medical Devices Regulations.

Thus, non-invasive hardware is described as any physical health or wellness device that is not intended to penetrate the body either through an orifice or the surface of the body.

This includes non-invasive means of gathering medical information including machines and/or systems such as X-rays, ECGs, MRIs and CTs.

Non-invasive procedures can also sometimes be used as treatment.

Intended for

This means your software has been designed, produced, and will be marketed for a particular purpose (or purposes).

You must communicate and explain the purpose of your software to potential users so they understand what it is for and what it is not for.

All literature published about the software – even if it is just a comment on the screen – must be considered when determining whether a product is excluded or not.

General consumer use

This means:

• You intend your product (software, or combination of software and non-invasive hardware), to be used by a consumer to promote or facilitate general health or wellness.
• You do not intend for your product to be used in clinical practice.
• You do not intend for your product to be used for diagnosis, screening, prevention, monitoring, prediction, prognosis, alleviation, treatment, or making a recommendation or decision about the treatment, of a serious disease, condition, ailment, or defect.

Clinical practice

This means:

• a healthcare facility such as a GP clinic, pathology lab, health centre, hospital, or vaccination centre
• where a health professional is involved.

For a full definition of 'health professional', see the Medical Devices Regulations.

Promote and/or facilitate general health or wellness

This means recording and communicating broad (non-specific) health and wellness information only to a general consumer (e.g., a user's heart rate during exercise).

It does not include information relating to a serious disease, condition, or ailment.

Physical parameter

A physical parameter is a measure of a particular health or wellness characteristic.

Examples include heart rate, heart rhythm, temperature, blood pressure or oxygen saturation, the amount and type of movement and the amount and type of sleep.

This measure is not intended by its manufacturer to be used:

• in clinical practice
• for the purpose of diagnosis, screening, prevention, monitoring, prediction, prognosis, alleviation, treatment, or making a recommendation or decision about the treatment, of a serious disease or a serious condition, ailment, or defect.

Disease condition, ailment or defect that is not serious

This means a disease or condition (including an ailment or defect) that:

• will not result in death or long-term disability
• can be cured
• does not need major therapeutic interventions (such as surgery)
• does not pose a risk or threat to the general public (e.g., it is not for self-management of a serious infectious disease)
• the average general consumer can evaluate accurately and safely self-manage by making choices towards a healthy lifestyle without the supervision of a medical practitioner, dentist, or other kind of state- or territory-registered healthcare worker.

A disease or condition must meet all these requirements to be defined as 'not serious'.

If your software is intended to be used for a disease or condition that is serious then this exclusion does not apply, and your software will come under the TGA regulations.

Serious vs not serious: examples of diseases or conditions

An example of a serious condition is diabetes.

Diabetes is considered serious as it requires the intervention of a health professional to be evaluated and treated effectively.

An example of a condition that is not serious is mild fever.

A general consumer could reasonably evaluate whether they have a mild fever and manage it safely.

Make claims about a disease, condition, ailment or defect

This means that when the software is used for diagnosis, screening, prevention, monitoring, prediction, prognosis, alleviation, treatment or making decisions about treatment of a disease, condition, ailment, or defect, it will only be excluded if the disease or condition is not serious.

Next steps

Follow the flow diagram to see if your software is excluded or not.

Excluded

Example

A fitness tracker that uses a wrist-worn sensor and a mobile phone app to track the user's heart rate during exercise.

The product provides information to the user comparing their resting heart rate to their heart rate during exercise for the purposes of determining the intensity of their workout.

Explanation

The software does not provide information linked to serious disease, condition, ailment, or defect.

It is not looking for medical irregularities or signs of fibrillation.

It is not used for diagnosis, or prognosis, or making decisions about treatment of any disease, condition, ailment, or defect.

Not excluded

Example

A fitness tracker that uses a wrist-worn sensor and a mobile phone app to track the user's heart rate during exercise.

The product provides information to the user comparing their resting heart rate to their heart rate during exercise for the purposes of determining the intensity of their workout.

This product has an additional function for users suffering from chronic heart conditions, where it monitors their heart rate and provides a warning when their heart rate is approaching a pre-set safety threshold.

Explanation

The software is intended to both provide fitness information and to monitor a patient’s heart rate in relation to a serious condition to indicate when they may be in danger.

Example

A wearable that enables a user to view their movements during exercise from a mobile app during post-surgery recovery.

The monitor and app are recommended by healthcare professionals and may also include exercises to carry out during recovery to reduce the need for in-person appointments.

The monitored data is sent to the healthcare professional to monitor and inform on recovery progress.

Explanation

The software is intended to be used to monitor recovery, is for clinical use and can identify issues during recovery that could be symptomatic of a serious disease, condition, defect, or ailment.

Behavioural change and coaching

Exclusion 14C applies to software intended to be used by a consumer to improve general health or wellness by coaching, or encouraging behavioural change, in relation to personal or environmental factors, such as weight, exercise, sun exposure or dietary intake:

14C software that is:

1. intended by its manufacturer to be used by a consumer to improve general health or wellness by coaching, or encouraging behavioural change, in relation to personal or environmental factors, such as weight, exercise, sun exposure or dietary intake; and
2. not intended by its manufacturer to be used:
   1. in clinical practice or to provide information to the consumer that would generally be accepted to require the interpretation of a health professional; or
   2. (ii) for the purpose of diagnosis, prognosis, or making a decision about the treatment, of a disease, condition, ailment or defect

Understanding this exclusion

This exclusion is based on five questions.

If you answer ‘yes’ to the following two questions, this exclusion may apply:

1. Is your software intended for improving general health or wellness through coaching or behavioural change (e.g., limiting sun exposure, modifying diet or exercise habits)?
2. Is your software for general consumer use?

However, if you answer ‘yes’ to any of the following, your software is not excluded:

3. Is your software also for use in clinical practice?
4. Does your software provide information to the consumer that would generally be accepted to require the interpretation of a health professional?
5. Is the software used for diagnosis, or prognosis, or making decisions about treatment of any disease, condition, defect, or ailment?

Definitions

Coaching or behavioural change

This means teaching or advising a person on making changes to their health habits.

For example:

• eating more healthily (reducing fat, increasing fresh food and/or having a better-balanced diet)
• limiting their sun exposure
• doing more exercise
• sleeping longer and at more regular times.

General health and wellness

This means broad (non-specific) health or wellness issues (e.g., a person's mental state of mind or general mobility or fitness).

General consumer use

This means:

• You intend your software to be used by a consumer only.
• You intend your software to promote or facilitate general health or wellness.
• You do not intend for your software to be used in clinical practice.
• You do not intend for your software to be used for diagnosis, screening, prevention, monitoring, prediction, prognosis, alleviation, treatment, or making recommendations or decisions about the treatment, of a disease, condition, ailment, or defect.

Clinical practice

This means:

• a healthcare facility such as a GP clinic, pathology lab, health centre, hospital or vaccination centre
• where a health professional is involved.

For a full definition of 'health professional', see the Medical Devices Regulations.

Interpretation of a heath professional

You need to ask yourself if your software can be understood and used by a general consumer (a patient with no medical training or knowledge) or can it only be understood and used by a patient if it is explained to them by a health professional.

For example, a general consumer could read a temperature reading from a thermometer but may not be able to interpret the implications of having certain levels of inflammatory markers in their blood.

Diagnosis or prognosis

This means the software identifies, detects, informs, or advises a person of the probability and/or the presence of a disease, condition, ailment or defect or the likely course of the disease, condition, ailment, or defect.

Making decisions about treatment

This means the software identifies, makes decisions, and/or helps a patient and/or a health professional decide what treatment to undertake to address (or 'treat') a health condition.

This includes providing recommendations or suggestions to undertake a treatment.

Next steps

Follow the flow diagram to see if your software is excluded or not.

Excluded

Example:

A 'sun-smart' app that gives the user alerts for UV protection to minimise skin cancer risk.

Explanation

While the software focuses on a health-related issue, it only provides information and is not used for diagnosis, or prognosis, or making decisions about treatment of any disease, condition, defect, or ailment.

Not excluded

Example:

Software that monitors a user's weight and uses trends in the data to then advise the user to take or cease taking prescription medication to control their weight.

Explanation

In addition to providing information and coaching and/or behavioural changes, the software is also used for making recommendations or decisions about treatment of a disease, condition, defect, or ailment.

Where products make claims about chronic disease associated with lifestyle, they are not excluded.

Patient reported outcome measures

Exclusion 14D applies to software intended to be used as a patient reported outcome measures (PROMs) questionnaire or patient survey:

14D software that is:

1. intended by its manufacturer to be used as a patient reported outcome measures (PROMs) questionnaire or patient survey; and
2. (b) not intended by its manufacturer to diagnose, screen for, monitor, predict, make a prognosis of, alleviate, treat, or make a recommendation or decision about the treatment of, a disease, condition, ailment, or defect

Understanding this exclusion

This exclusion is based on two questions:

1. Is your software a PROM questionnaire or patient survey?
2. Does your software make claims about a disease, condition, ailment, or defect?

Definitions

PROM questionnaire

A PROM questionnaire asks patients for information about their health outcomes from their perspective, rather than that of a health professional.

The information gathered helps to measure changes in a patient's general health status – for example, in their acute and/or chronic pain, or their depression – while the patient is waiting for care or surgical treatment or after care or surgical treatment.

Questions they ask:

• Some PROMs ask about things that only patients can know (e.g., how much pain they are in or the level of their psychological distress).
• Others ask questions about things that other people could observe as well as the patient (e.g., how mobile the patient is or how able they are to walk or stand).

Although they are designed for patients to complete, in some cases, a carer or a nominated support person may also complete a PROM.

A PROM questionnaire might also be one that forms part of an electronic health record.

You can find more detailed information about PROM questionnaires at the Australian Commission on Safety and Quality in Healthcare.

A PROM questionnaire is an example of a patient survey.

Patient survey

Sometimes people are asked to complete surveys to aid in screening.

Paper based surveys are increasingly being provided in digital formats (e.g., via a mobile phone or tablet app).

Software that is a patient survey is not a medical device when its purpose is limited to exclusively collecting patient data via the user inputting responses to survey questions.

Whether or not the software is excluded depends on what is done with the collected information:

• Software may be excluded in cases where software automates the calculation of scores for collected survey results according to established rules. These results are then presented to the user who makes a diagnostic or screening decision.
• Software is not excluded where the software itself is further analysing the survey responses and/or combining the responses/score with other data. In these cases, the software may be providing unique diagnostic or screening information and/or making inferences about a patients’ condition to make a recommendation or decision related to patient care.
• Where the software makes a prediction about risk of a disease or condition, it would not be excluded.

Make claims about a disease, condition, ailment or defect

This means that when the software is used for diagnosis, screening, prevention, monitoring, prediction, prognosis, alleviation, treatment or making decisions about treatment of a disease, condition, ailment, or defect, it is not excluded.

Next steps

Follow the flow diagram to see if your software is excluded or not.

Excluded

Example

An app that digitises an established PROM questionnaire to assess the quality of life of a patient undergoing cancer treatment.

The software provides the same information as a traditional paper questionnaire or survey but in a digital format.

The information is stored in the patient’s medical records and is used to inform their care, but the app itself does not diagnose, screen, prevent, monitor, predict, provide a prognosis, alleviate, or treat the patient’s cancer.

Explanation

The software is not used for one of the above purposes (diagnosis, treatment etc.).

Example

An app that digitises an established patient survey that is used to help clinicians screen for certain health disorders.

The software:

1. presents questions with multiple choice responses to choose from
2. allows the patient to select the answer to each question that most applies to their situation
3. saves the responses and calculates a risk score based on predetermined weightings for each response.

The responses and risk score are provided to the clinician who may use this to inform their patient’s care.

The software provides the logic of the risk score calculation to the clinician, as well as a reference to the established survey it implements.

Explanation

Although the survey is used to help clinicians to screen for a condition, the software itself is not performing the screening because:

• the software itself is not making inferences about the patient’s condition, or
• making a recommendation or decision related to patient care for (diagnosis, treatment etc.).

Example

An app that digitises the PHQ-9 survey (which is commonly used as an adjunct screening tool for the presence and severity of depression).

The app collects the user’s inputs and provides the results to a health professional.

Explanation

As the software itself is limited to collecting information the health professional may choose to use this information in deciding to screen for the presence and severity of depression.

The software itself does not perform a screening function.

Not excluded

Example

An app that requires the user to complete a questionnaire or survey to analyse the responses to predict the user’s likelihood of having a certain cancer.

Explanation

The software is a patient survey that is used to screen for a disease, condition, ailment, or defect.

The software itself is determining the likelihood of the patient having cancer, rather than providing information to a user to interpret.

Example

A software product is intended to allow GPs to identify the presence of serious inflammatory disorders by undertaking algorithm-based analysis of survey results in combination with photographs of ‘affected areas’.

The product is intended to provide a surrogate for expert rheumatologist examination. The next action is referral to a specialist or further testing.

Explanation

The software is doing more than simply collecting data. It is analysing the information to diagnose a condition.

Example

An app that digitises the PHQ-9 survey (which is commonly used as a screening tool for the presence and severity of depression).

The app analyses the user’s inputs and states the presence and severity of depression directly to the user.

Explanation

The software is doing more than collection of information as it is analysing data to screen for a condition.

Exclusion 14E applies to software that is a digital mental health tool (including a cognitive behaviour therapy tool) based on established clinical practice guidelines that are referenced, displayed, and are reviewable by the user within the software:

14E software that is a digital mental health tool (including a cognitive behaviour therapy tool) based on established clinical practice guidelines that are referenced and displayed in the software in a manner that is reviewable by the user.

Understanding this exclusion

This exclusion is based on five questions:

1. Is your software intended to be used in mental health?
2. Does your software follow an established clinical practice guideline? 
3. Is the guideline referenced?
4. Is that reference displayed in the software so a user can clearly view it?
5. Is the software part of novel treatment still undergoing trials?

For more information, see: Regulation of software based medical devices

Definitions

Intended to be

This means your software has been designed and produced for a particular purpose (or purposes).

You must communicate and explain the purpose (or purposes) of your software to potential users, so they understand what it is for and what it is not for.

If the software replicates paper-based mental health assessments in electronic format, then it is excluded.

Used in mental health

This means anything related to a mental health (and only mental health) disease, condition, ailment, or defect, (e.g., a diagnosis) and any treatment related to mental health.

Software that uses psychological tools to manage a physiological condition is not covered under this exclusion (e.g., a smartphone app that uses cognitive behavioural therapy to manage symptoms of diabetes).

Follow an established clinical practice guideline

This means the software is an implementation of a digital mental health tool that is widely accepted for use in clinical practice in Australia.

This usually means that clinical practices and organisations that represent health professionals have published the guideline for use in patient care.

However, it can also mean the hospital itself or an individual has published it.

It is unlikely that a single guideline (e.g., a published research paper) would be considered 'established' in clinical practice.

The guideline must be recognised and widely accepted by clinical practices and organisations that represent healthcare providers and established for use in Australia.

Likewise, creating your own guideline for use in your product would not be sufficient to meet the criteria, as the guideline must be widely accepted and established for use in Australia.

It must be recognised by a relevant health professional body or a national body such as the Australian Commission on Safety and Quality in Healthcare.

Here's an example of an established clinical practice guideline from the Royal Australian & New Zealand College of Psychiatrists.

Referenced and displayed in the software

The user needs to be able to clearly identify the specific clinical practice guidelines the software follows.

This means these guidelines must be referenced and displayed so the user can easily see and access them. Incorporating links to guidelines would be acceptable, but only if they are directly available to users (e.g., displayed within an app).

Displaying links in a user manual is not enough for the software to be excluded.

Novel treatment still undergoing trials

If the treatment your software facilitates is undergoing trials, it means it is not yet established in clinical practice.

This means the software is not excluded and therefore is still regulated by the TGA.

In this case, you may need to consider if you need to apply to the TGA for an exemption to use your software in a clinical trial.

Next steps

Read our guidance (Understanding digital mental health device rules) and our Digital Mental Health factsheet (PDF, 269 kb).

Follow the flow diagram to see if your software is excluded or not.

Excluded

Example

A website that offers digital therapy sessions (e.g., focusing on cognitive behavioural therapy) to help treat anxiety.

The sessions on the web page follow established clinical practice guidelines published by the Royal Australian & New Zealand College of Psychiatrists, and the web page links directly to the specific guidelines published by the Royal Australian & New Zealand College of Psychiatrists.

Explanation

The tool follows an established clinical practice guideline, and a link to the guideline from the Royal Australian & New Zealand College of Psychiatrists is included on the web page.

Not excluded

Example

A website that uses an innovative treatment for depression that has recently been developed.

There are some preliminary papers published, but no clinical practice guidelines for the treatment, and the treatment is not in wide use.

Explanation

The website does not follow an established clinical practice guideline.

Communications

Exclusion 14F applies to software intended to enable communications for the purposes of supporting the delivery of health services:

14F software that is:

1. intended by its manufacturer to enable communications, including the transmission of patient information, for the purposes of supporting the delivery of health services; and
2. not intended by its manufacturer to diagnose, screen for, prevent, monitor, predict, make a prognosis of, alleviate, treat, or make a recommendation or decision about the treatment of, a disease, condition, ailment, or defect

Understanding this exclusion

This exclusion is based on two questions:

1. Is your software intended to enable communications, including the transmission of patient information, for the purposes of supporting the delivery of health services?
2. Does your software make claims about a disease, condition, ailment, or defect?

Definitions

Enable communications

This means your software provides or helps to provide an electronic communication medium, method or channel, over which patient information (and, possibly, other information) can be transmitted and shared between individuals (patients and/or health professionals). 

This channel could be anything from an SMS to an email, or an audio call, video call or video conference. 

This is intended to refer to communications between people, rather than equipment or devices.

Transmission of patient information

This means our software is intended to send and receive information related to one or more aspects of a patient's health. 

This transmission might be between health professionals and/or general consumers. 

This information could be from a patient record, for example.

Software intended to remotely display certain patient information would not be excluded if the information:

• is being displayed to remotely monitor a patients’ condition, that is intended to alert a caregiver to take clinical action
• is being displayed for the purposes of making a diagnosis, or screening for a disease or condition (for example, is the software is intended to display test results or medical imaging for a health professional to interpret, and/or make a diagnosis).

Supporting the delivery of health services

This means your software is intended to transmit patient information with the goal of helping to deliver some sort of health service.

There are many types of health service that can be delivered remotely via a telehealth service – anything from the results of a test or scan (information only) to advice on what disease a patient might have (diagnosis), what the patient's chances are of recovery (prognosis) or step-by-step guidance to perform an emergency procedure in a remote location (treatment).

If the software only facilitates the communication, then it is excluded, even if a health professional using it might be diagnosing or treating a patient.

However, if the software makes claims about a disease, condition, ailment, or defect, it may not be excluded.

For example, if software intended to support communications also included functionality that analysed patient information (such as imaging and test results) to detect a particular condition, it would not be excluded.

Make claims about a disease, condition, ailment or defect

If your software does any of the following:

• diagnosis
• screening
• prevention
• monitoring
• predicting
• prognosis
• alleviation
• treatment
• recommending or making decisions about treatment

…of a disease, condition, ailment, or defect, then it is not excluded.

Next steps

Follow the flow diagram to see if your software is excluded or not.

Excluded

Example

Software that runs (or is) purely a communications tool (e.g., something that sends an SMS that gives a patient or health professional some results) or sends a PDF file of written results.

The software is marketed specifically for sharing this health information.

Explanation

The software is used only for healthcare communication (e.g., chat during a telehealth medical appointment).

Even though a diagnosis or prognosis or some other health activity might be undertaken during the communication, the software is not performing that activity itself.

Not excluded

Example

A software telehealth feature that is part of GP practice software that measures range of movement of a patient's limbs (e.g., a goniometer) for the purpose of monitoring patient recovery or prognosis.

Explanation

This software is more than just a communication device, and is making claims about a disease, condition, ailment, or defect.

Administration of health facilities

Exclusion 14G applies to software intended to be used for the administration or management of health processes or facilities (including financial records, claims, billing, appointments, operating theatre management, hospital bed management, schedules, business analytics, admissions, inventory, and workflow):

14G software that is:

1. intended by its manufacturer to be used for the administration or management of health processes or facilities (including financial records, claims, billing, appointments, operating theatre management, hospital bed management, schedules, business analytics, admissions, inventory, and workflow); and
2. (b) not intended by its manufacturer to be used for the purpose of diagnosis, screening, prevention, monitoring, prediction, prognosis, alleviation, treatment, or making a recommendation or decision about the treatment, of a disease, condition, ailment, or defect

Understanding this exclusion

This exclusion is based on two questions:

1. Is your software for the administration or management of health processes or facilities?
2. Does your software make claims about a disease, condition, ailment, or defect?

Definitions

Administration or management of health processes or facilities

This means your software is intended for things such as (but not limited to)

• ordering (of medications, tests, treatments, etc.)
• scheduling (appointments, etc.)
• planning
• recording the administrative or management side of health processes or a facility (e.g., a hospital or GP clinic) where those processes happen.

Your software is not intended for patient clinical use cases but is nonetheless important for the health and wellbeing of a patient as they go through the health process and/or a facility. This exclusion does not apply to software intended to manage individual patient use cases.

This includes things such as managing financial records, claims, billing, appointments, operating theatre management, hospital bed management, schedules, business analytics, admissions and/or inventory and workflow.

Make claims about a disease, condition, ailment or defect

If your software does any of the following:

• diagnosis
• screening
• prevention
• monitoring
• predicting
• prognosis
• alleviation
• treatment
• making recommendations or decisions about treatment

…of a disease, condition, ailment, or defect, then it is not excluded.

Next steps

Follow the flow diagram to see if your software is excluded or not.

Excluded

Example

Software that organises Medicare claims for a GP practice.

Explanation

The software is not intended for use in the diagnosis, screening, prevention, monitoring, prediction, prognosis, alleviation, treatment or for making decisions about treatment of a disease, condition, ailment, or defect.

Not excluded

Example

A software module that is part of a system that manages hospital admissions that is used to screen patients for conditions.

Explanation

The software is intended to be used for the screening of a disease, condition, ailment, or defect.

Storing or transmitting patient images

Exclusion 14H applies to software that is for the sole purpose of storing or transmitting patient images:

14H software that is intended by its manufacturer to be used for the sole purpose of storing or transmitting patient images

Understanding this exclusion

This exclusion is based on one question: 

1. Is your software for the sole purpose of storing or transmitting patient images, or does it also analyse images?

Definitions

Sole purpose

This means your software has one purpose only. 

It cannot be used for anything else. 

If your software has any other functionality (such as displaying images for diagnostic purposes) it may not be excluded.

Storing or transmitting patient images

This means your software is intended (only) for the electronic storage of digital images of a patient that relate to that patient's health or condition and/or electronically transmitting those images.

If your software analyses the images for the purposes of diagnosis, screening, monitoring and/or determining treatment options, it will not be excluded.

Similarly, software intended to display medical images for the purpose of the viewer making a diagnosis or to screen for a disease or condition is not excluded.

Next steps

Follow the flow diagram to see if your software is excluded or not.

Excluded

Example 1

A database that allows for images to be received, saved, and sent to other software.

The software has no other functionality.

Explanation

This software is intended to function purely as a repository for images. 

All this software does is receive, save, and send images.

Example 2

An online system that stores patient images and allows for these images to be accessed by patients for information purposes only.

Explanation

Although this software allows for the display of patient images, it is for information purposes only and does not display the images for the purpose of diagnosis.
 

Not excluded

Example

An app that receives a patient image from a health record, then highlights areas on the image that might be flagged for further review by a health professional.

Explanation

The software is intended for uses outside of simply receiving, saving, and sending images.

The software also analyses images and/or their metadata for a medical purpose.

Alerts for health professionals

Exclusion 14I applies to software that is for the sole purpose of providing alerts to health professionals in relation to patient care:

14I software that is:

1. intended by its manufacturer to be used for the sole purpose of providing alerts to health professionals in relation to patient care; and
2. not intended by its manufacturer to:
   1. replace the clinical judgement of a health professional; or
   2. diagnose, screen for, prevent, alleviate, treat, or make a decision about the treatment of, a disease, condition, ailment or defect.

Understanding this exclusion

This exclusion is based on three questions:

1. Is your software for sole purpose of providing alerts to health professionals in relation to patient care?
2. Is your software intended to replace clinical judgment?
3. Does the software diagnose, screen for, prevent, alleviate, treat, or make recommendations or decisions about treatment of a disease, condition, defect or ailment?

Definitions

Sole purpose

This means your software has one purpose only. It cannot be used for anything else.

Providing alerts to health professionals in relation to patient care

This means the software prepares and communicates some sort of notification ('alert') to a health professional that relates to one or more aspects of a patient's care.

This alert might remind a health professional that prescribed medication is ready to be dispensed, or alert that two medications that have been prescribed may have an adverse interaction.

The health professional can make their own decision whether to take any action because of the alert or the information. For a full definition of 'health professional', see the Medical Devices Regulations.

Alerts versus alarms:

This exclusion does not apply to alarms provided to health professionals that must be actioned. For example, an alarm on a ventilator alerting an ICU nurse to take immediate action.

Replace clinical judgment

This means your software is intended to take the place of a health professional when making a clinical decision.

In other words, a treatment decision that has traditionally been performed by a human is performed instead by your software.

Additionally, if the alert is providing unique clinical information that the health professional would not otherwise have access to, or cannot check in any way, the software is not excluded.

This is because the clinician does not have access to all the information needed to judge whether the information is valid.

Make claims about a disease, condition, ailment or defect

Your software may be excluded, depending on what claims are made about the alerts. If your software provides an alert to a health professional relating to:

• monitoring, or
• predicting, or
• making a prognosis of a disease, condition, ailment, or defect

... then it is excluded.

If your software provides an alert to a health professional that is intended to inform:

• diagnosing
• screening
• preventing
• alleviating
• treating
• making recommendations or decisions about treatment.

…of a disease, condition, ailment, or defect, then it is not excluded.

Next steps

Follow the flow diagram to see if your software is excluded or not.

Excluded

Example

Software that checks potential prescriptions and sends an information-only alert to a health professional, informing them of any known adverse drug interactions.

The software uses information from MIMS Australia.

Upon receipt of an alert, the health professional decides whether to proceed with prescribing the chosen medications.

Explanation

The software is for the sole purpose of providing alerts to health professionals in relation to patient care, it is not intended to replace clinical judgment and it does not diagnose, screen for, prevent, alleviate, treat, or make recommendations or decisions about treatment of a disease, condition, defect, or ailment.

Example

Software that checks hospital prescriptions made for antibiotics and sends an information-only alert to a health professional, informing them of the hospital’s antimicrobial stewardship policy for the chosen antibiotic. Upon receipt of an alert, the health professional decides whether to proceed with prescribing the chosen antibiotic(s).

Explanation

The software is for the sole purpose of providing alerts to health professionals in relation to patient care, it is not intended to replace clinical judgment and it does not diagnose, screen for, prevent, alleviate, treat, or make recommendations or decisions about treatment of a disease, condition, defect, or ailment.

Not excluded

Example

Software that checks potential prescriptions and sends an alert to a health professional, informing them of any known adverse drug interactions.

The software does not allow the chosen medications to be prescribed and recommends alternatives with no known adverse interactions.

The software uses information from MIMS Australia.

In this case, the health professional cannot proceed with the original prescription and must choose a replacement prescription based on the options presented.

Explanation

The software is not for the sole purpose of providing alerts to health professionals in relation to patient care.

The software is not excluded because:

• The software is intended to replace clinical judgment by not allowing the health professional to proceed with their original prescription.
• The software is making recommendations or decisions about treatment of a disease, condition, defect, or ailment by recommending alternative medications.

Example

Software that collects patient heart rhythm data and sends an alert to a health professional flagging an arrythmia has been detected.

The health professional relies on the software to inform them if they need to take an immediate clinical action.

Explanation

Although the software is providing an alert to a health professional in relation to patient care, this software does more than this, as it is monitoring for and screening for arrythmias.

The health professional is relying on this information to determine whether a clinical action is required.

Clinical workflow management

Exclusion 14J applies to software that is for clinical workflow management:

14J software that is:

1. intended by its manufacturer to be used for clinical workflow management; and
2. (b) not intended by its manufacturer to diagnose, screen for, prevent, monitor, predict, make a prognosis of, alleviate, treat, or make a recommendation or decision about the treatment of, a disease, condition, ailment, or defect

Understanding this exclusion

This exclusion is based on two questions:

1. Is your software for clinical workflow management?
2. Does the software make claims about a disease, condition, ailment, or defect?

Definitions

Clinical workflow management

This means how processes are performed in both administration and operations to offer patients the best health experience possible. This term encompasses software designed to make the healthcare system (or elements if it) more efficient and streamlined. It connects activities, environments, organisations, people, and technologies in a clinical environment. Some of these might happen or work at the same time, while others might proceed in a logical order, one providing the information needed for the next to happen.

This includes access to, and display of, a patient's digital medical history and/or peer-reviewed clinical studies and clinical-practice guidelines.

Clinical workflow management develops patterns that can be relied upon, minimising the risk of mistakes and complications.

Make claims about a disease, condition, ailment or defect

If your software does any of the following:

• diagnosis
• screening
• prevention
• monitoring
• predicting
• prognosis
• alleviation
• treatment
• making recommendations or decisions about treatment.

…of a disease, condition, ailment, or defect, then it is not excluded.

Next steps

Follow the flow diagram to see if your software is excluded or not.

Excluded

Example

Software that runs a function that admits a patient to a hospital, according to that hospital’s standard procedures.

Explanation

This software includes a series of steps such as recording observations (e.g., a patient's vital signs) and tells a user what work to do (according to an established procedure) but not what decisions to make.

The software makes no claims (i.e., it is not intended for treating, diagnosing, monitoring, etc) about diseases or conditions.

Not excluded

Example

Software that runs a function that admits a patient to a hospital and has options for a screening function for several diseases.

Explanation

This software has additional functionality to the excluded example. It tells a user what work to do and provides screening recommendations and suggestions to the users. That means it meets the TGA's definition of a software-based medical device and comes under the regulations.

Exclusion 14K applies to software that is middleware intended to connect or interface applications to an underlying operating system or another application, including by communicating or transmitting information:

14K software that is middleware and is:

1. intended by its manufacturer to connect or interface applications to an underlying operating system or another application, including by communicating or transmitting information; and
2. not intended by its manufacturer to:
   1. control medical devices; or
   2. perform analysis, computation or logic that relates to the intended purpose of a medical device; or
   3. be used for the purpose of diagnosis, screening, prevention, monitoring, prediction, prognosis, alleviation, treatment, or making a recommendation or decision about the treatment, of a disease, condition, ailment, or defect

Understanding this exclusion

This exclusion is based on four questions:

1. Is your software middleware that is intended to connect or interface applications to an underlying operating system or another application, including by communicating or transmitting information?
2. Does your software also control medical devices?
3. Does your software perform analysis, computation or logic that relates to the intended purpose of a medical device? 
4. Does the software make claims about a disease, condition, ailment, or defect?

Definitions

Middleware

Middleware in a healthcare context usually means the same as in IT.

It is software that sits between software applications (such as user-facing software) and an operating system.

Middleware enables communications between these different software layers or components.

Middleware software is excluded from the TGA regulations, and therefore is not a medical device (even if it is used in a healthcare context such as hospital).

Pathology middleware

In one area of healthcare – pathology – middleware has a slightly different and very specific meaning.

Pathology middleware commonly sits between laboratory instruments and Laboratory Information Systems (LIS) to manage laboratory data collected from laboratory instruments.

As well as performing a communications function, pathology middleware can also perform a variety of other functions including:

• verifying and analysing the results of medical tests (a biopsy, for example),
• helping in diagnosis and/or prognosis. 

If the middleware includes these functions, it is a medical device and is not excluded from the TGA regulation.

Control medical devices

Sometimes middleware can control medical devices, for example, by passing instructions from another software application to a medical device.

Analysis, computation or logic that relates to the intended purpose of a medical device

This means, is your middleware software required by a medical device for it to perform as intended? If it does this, then it is an accessory to a medical device, and is not excluded.

Make claims about a disease, condition, ailment or defect

If your software does any of the following:

• diagnosis
• screening for
• prevention
• monitoring
• predicting
• prognosis
• alleviation
• treatment
• making recommendations or decisions about treatment.

…of a disease, condition, ailment, or defect, then it is not excluded.

Next steps

Follow the flow diagram to see if your software is excluded or not.

Excluded

Example

Middleware software used in a hospital that communicates and integrates between user-facing software and the hospital's mainframe but does nothing else (i.e., does not analyse medical test results).

Explanation

The middleware is generic and not designed specifically for a healthcare or medical purpose.

Nor is it a medical device.

Nor does it control medical devices or is it intended for diagnosis, screening for, prevention, monitoring, predicting, prognosis, alleviation, treatment or making recommendations or decisions about treatment.

Example

An application programming interface (API) that enables secure access to patient bank details to facilitate the payment of Medicare benefits.

Explanation

The API is not used to control a medical device or perform logic related to the intended purpose of a medical device or for the diagnosis, screening for, prevention, monitoring, predicting, prognosis, alleviation, treatment or making recommendations or decisions about treatment.

Not excluded

Example

A web server that supports the delivery of content for a software-based medical device that requires information be uploaded through a web-based portal.

Explanation

The web server is required for the medical device to achieve its intended purpose and therefore is not excluded.

Example

Pathology middleware software used to influence, control, or drive an analyser.

Explanation

Because the analyser is a medical device (IVD), and the software drives or influences it, the software must be classified with the medical device, and it is not excluded.

Example

Pathology middleware software used to analyse biopsy samples and provide a diagnostic output.

Explanation

Because the software performs (or helps to perform) a diagnosis or prognosis on a patient's disease, condition, ailment, or defect, it is not excluded.

Calculators

Exclusion 14L applies to software that makes calculations using authoritative sources such as published clinical standards or displays the calculation steps or logic so that the user can validate the result:

14L software that is a calculator and

1. either:
   1. uses relevant published clinical standards or authoritative sources to make calculations; or
   2. displays calculations and outputs in a manner that may be validated by the user; and
2. is not intended by its manufacturer to control the administration of a calculated dosage

Understanding this exclusion

This exclusion is based on four questions:

1. Is your software a calculator?
2. Does your software use relevant published clinical standards or authoritative sources to make calculations?
3. Does your software display the calculations and outputs in a manner that may be validated by the user?
4. Does your software control the administration of a calculated dosage?

Definitions

Calculator

This means your software includes a function that acts as a digital numerical calculator. 
It could be the digitised version of a pain medication dose calculator, or a calculator on a smartphone that is linked to a health-related app or system.

This exclusion does not apply to software that are not numerical calculators (e.g., rules-based or based on decision trees).

If your software has any functionality other than numerical calculations, you must consider if those functions would be captured as a medical device.

Relevant published clinical standards or authoritative sources

This means your software’s calculator function follows a relevant published clinical standard formula.

This means it is either in common usage (e.g., the Parkland formula), or may be subject to another form of regulation and/or certification (e.g., a weight-based dosage calculation for a medicine that follows a formula in the product information (PI) published for that medicine).

Display the calculations and outputs in a manner that may be validated by the user

This means that if your software's calculator function displays or steps through the logic of the calculation, or the formula itself (for example, ‘patient weight x 100mg’) for the user to see, then it is excluded.

If the calculation is sufficiently complex that it is not practical to present this logic, or that the user cannot easily understand the logic (and the calculation is not based on a published clinical standard or authoritative source), the calculator will not be excluded.

Control the administration of a calculated dosage

This means your software's calculator does more than provide information – it also schedules, determines, and/or delivers calculated doses of medicine to a patient.

The administration can be automatic (for example, software that controls the dosage delivered by a medication pump) or manual (the software specifies what the user must do and when).

If the calculator specifies a dosage in this way, then it is not excluded.

Next steps

Follow the flow diagram to see if your software is excluded or not.

Excluded

Example

Software that calculates the volume of fluids needed for a burns patient using the Parkland Formula and displays the mathematical formula and results for each of the calculation steps.

Explanation

The calculator uses the Parkland Formula, which is a relevant published clinical standard formula.

As the software displays the formula and calculation logic, the user can see if the results are correct or as expected.

Not Excluded

Example

Software that is part of an intravenous device administering chemotherapy medication that calculates the volume and frequency of each dose.

Explanation

This software controls the administration of a calculated dosage and is therefore a medical device.

Exclusion 14M applies to software, or a combination of software and hardware, that is an electronic health record (however named or described):

14M software, or a combination of software and hardware, that is an electronic health record (however named or described) and is:

1. intended by its manufacturer to be used in clinical practice by healthcare providers to collect, use, disclose and otherwise manage patient clinical data within or between healthcare facilities; and
2. not intended by its manufacturer to diagnose, screen for, prevent, monitor, predict, make a prognosis of, alleviate, treat, or make a recommendation or decision about the treatment of, a disease, condition, ailment, or defect

Understanding this exclusion

This exclusion is based on three questions:

1. Does your product (software or a combination of software and hardware) function as an electronic health record regardless of how you have named or described?
2. Is your product for use in clinical practice by healthcare providers to collect, use, disclose or otherwise manage patient clinical data within or between healthcare facilities?
3. Does the software diagnose, screen for, prevent, monitor, predict, make a prognosis of, alleviate, treat or make recommendations or decisions about treatment of a disease, condition, defect or ailment?

Definitions

Electronic health record

This means your software is used to electronically collect, use, disclose and otherwise manage patient clinical data within or between healthcare facilities.

This includes Electronic Medical Records (EMR) and Electronic Patient Records (EPR).

These products are intended to do the same job as previously used paper records.

These software products allow health professionals to see, review and update patient medical records and determine whether any clinical actions are required (e.g., ordering more medications, or scheduling tests or procedures).

Patient clinical data

This means data that is specific to a patient and to that patient's health.

For example, a patient's cholesterol levels or history of surgical procedures.

It is different to data related to, for example, healthcare processes or facilities, or general reference material.

Healthcare facilities

This means venues or locations that are professional places for administering one or more healthcare aspects or services (e.g., hospitals, GP clinics, dental practices, and COVID-19 vaccination centres).

Make claims about a disease, condition, ailment or defect

If your software does any of the following:

• diagnosis
• screening
• prevention
• monitoring
• predicting
• prognosis
• alleviation
• treatment
• making recommendations or decisions about treatment.

…of a disease, condition, ailment, or defect, then it is not excluded.

Next steps

Follow the flow diagram to see if your software is excluded or not.

Excluded

Example

Software that electronically stores and manages patient data in a GP clinic but does no more than that (e.g., a GP's notes, past test results and prescriptions).

It allows the GP to retrieve, view and add new information about their patients.

Explanation

The software is an electronic health record and is intended for use by health professionals in a healthcare facility, but it is for information purposes only and does not diagnose, screen for, prevent, monitor, predict, make a prognosis of, alleviate, treat, or make recommendations or decisions about treatment of a disease, condition, defect, or ailment.

Not Excluded

Example

Software that electronically stores and manages data in a GP clinic and analyses information to identify trends for the purposes of diagnosing a patient's disease, condition, defect, or ailment.

For example, a software module that analyses blood pressure information collected over a period to screen for chronic hypertension.

Explanation

Even though the software is an electronic health record, it is also used to screen patients for conditions.

Exclusion 14N applies to software that is data analytics for the collection and analysis of class, group, or population data:

14N software that is data analytics and is:

1. intended by its manufacturer to be used for the collection and analysis of class, group or population data; and
2. not intended by its manufacturer to be used for the purpose of diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation, of a disease, condition, ailment or defect in relation to individuals

Understanding this exclusion

This exclusion is based on three questions:

1. Does your software perform data analytics?
2. Is your software for the collection and analysis of class, group, or population data?
3. Does your software make claims about a disease, condition, ailment, or defect in relation to an individual patient's clinical case?’

Definitions

Perform data analytics

This means working with and using data to discover insights and support evidence-based decision making. 'Working with' data can mean looking at, cleansing, transforming and re-organising data, so it is easier to use. 'Using data' can mean interrogating the data and creating models to display information and insights.

Collection and analysis of class, group, or population data

This means collecting and analysing this data. If the collection and analysis is used to find trends only (i.e., to show results and patterns), then it is excluded from the TGA regulations.

For example, software may analyse aggregated, de-identified patient data for research purposes, or to inform public health measures, and where resources could most efficiently be used. This software would be excluded.

Individual patient's clinical case

If the data collection and analysis is used to inform clinical action in relation to the health of an individual patient (e.g., software that compares an individuals’ information against aggregated data to screen for a disease) then the software is not excluded.

Make claims about a disease, condition, ailment or defect

If your software does any of the following:

• diagnosis
• screening
• prevention
• monitoring
• predicting
• prognosis
• alleviation
• treatment
• making recommendations or decisions about treatment.

…of a disease, condition, ailment, or defect, then it is not excluded.

Next steps

Follow the flow diagram to see if your software is excluded or not. 

Excluded

Example

Analysis on a population who are asked via email reminders to report via a website on fever, cough, days off work, and vaccination status.

The results are used to generate population statistics and track infections, which may be of use in studying and controlling epidemics.

The information is not used to inform therapeutic interventions for any of the individuals involved.

Explanation

The results of the analysis are used for population-based study and are not used for an individual patient.

It's not the analysis itself but what the results are then used for that determines if the software is excluded or not.

Not excluded

Example

Software that analyses aggregated data from a population of patients relating to treatment and prognosis for breast cancer.

The software uses this to make inferences about the most appropriate treatment options for and individual patient’s breast cancer.

Explanation

The results of the analysis are used to inform the treatment for an individual person.

Exclusion 14O applies to software that is a Laboratory information management system, however named or described.

14O software that is a laboratory information management system (however named or described) and is not intended by its manufacturer to:

1. manipulate information or data to change, or generate new, diagnostic outputs (other than automating simple calculations or generating report comments); or
2. prevent, monitor, predict, make a prognosis of, treat or alleviate a disease, condition, ailment or defect

Understanding this exclusion

This exclusion is based on three questions:

1. Is your software a laboratory information management system (however named or described)?
2. Does your software manipulate information or data to change, or generate new, diagnostic outputs (other than automating simple calculations or generating report comments)?
3. Does the software prevent, monitor, predict, make a prognosis of, alleviate, or treat a disease, condition, ailment, or defect

Definitions

Laboratory information management system

This means your software is any kind of information and data management system used in a healthcare laboratory, such as a pathology or radiology laboratory. LIMS are generally used to capture the data produced or used by a laboratory, such as inventory, samples, and test results. These systems may also automate or integrate workflows and standard procedures.

Manipulate information or data

This means your software can use the data it collects to produce outputs that can be used for health-specific and/or patient-specific activities. For example, analysing test results to produce new information that will be used to screen patients for a disease.

Change, or generate new, diagnostic outputs

This means your software can alter outputs and produce additional information that was not previously available, which effectively influences decisions about the diagnosis of a patient. If your software does this, it is not excluded.

Note that functionality that is limited to automating simple calculations, generating report comments, or allowing for manual annotation can be performed by excluded software.

'Make claims about a disease, condition, ailment or defect'

If your software does any of the following:

• diagnosis
• screening
• prevention
• monitoring
• predicting
• prognosis
• alleviation
• treatment
• making recommendations or decisions about treatment.

…of a disease, condition, ailment, or defect, then it is not excluded.

Next steps

Follow the flow diagram to see if your software is excluded or not.

Excluded

Example

Software that automates workflows, integrates instruments, manages samples, and reports results of assays.

The software allows for pathologists to annotate test results and create notes but does not itself recommend a diagnosis or treatment.

Explanation

The software only manages workflows and data.

The software records, saves, sends, and makes data available.

The software is not used for the prevention, monitoring, prediction, making a prognosis of, alleviating, or treating a disease, condition, ailment, or defect.

Not excluded

Example

A LIMS software module that analyses IVD results and generates new diagnostic data.

Explanation

Because the software is generating a diagnostic output that would have otherwise been unavailable.