Understanding clinical decision support system software regulation

CDSS is software that can perform a broad range of functions to enable and support clinical practice. 

Examples include:

• a web-based application that provides information about particular diseases or conditions based on a health practitioner’s input of their patient’s symptoms
• software intended to analyse an x-ray image to assist a radiologist in identifying anomalies
• software that collects and records data from a closed-loop blood glucose monitor.

CDSS could be any kind of software, including but not limited to:

• mobile apps
• software as a service (cloud based)
• websites and browser delivered products
• more traditional software platform architectures.

Excluded software

Certain software-based medical devices are excluded from the scope of our regulation, based on the following principles:

• aligning with international regulatory frameworks where appropriate
• reducing or removing unnecessary regulatory burden:
  • by not regulating products where there is no significant risk to safety
  • by not regulating where suitable oversight frameworks are already in place.

Determine if your CDSS software is excluded

If all functions of your CDSS software are excluded per the Therapeutic Goods (Excluded Goods) Determination 2018, it is not regulated by us. 

In this case you do not need to consider the rest of this guidance or the examples it includes.

To determine if your CDSS software is excluded refer to our guidance on Software-based medical device exclusions. 

If your CDSS software is a medical device but does not meet the exclusion criteria, it will be regulated by us. 

You should then assess whether it is exempt from being included in the ARTG. 

Note 
If your product is updated or its intended purpose changes, you must reassess whether it still meets the exclusion criteria.

Excluded software is not regulated by us. 
Exempt software is not required to be included in the ARTG. It remains subject to our oversight, including requirements for advertising, adverse event reporting, and notification.

Exemption for some CDSS software

CDSS software that meets the definition of a medical device must be included in the Australian Register of Therapeutic Goods (ARTG) unless it is exempt.

Some CDSS software is exempt from inclusion in the ARTG. To qualify, the CDSS software must meet all exemption criteria set out in the Therapeutic Goods (Medical Devices) Regulations 2002 (Schedule 4, Part 2). 

Exempt CDSS typically has limited functionality. 

It may include software that collects, performs simple analysis, and displays data from: 

• Electronic Medical Records (EMRs),
• Electronic Health Records (EHRs) or
• Clinical Information Systems (CISs). 

These systems may provide prompts, alerts, reminders, and recommendations to help health professionals apply evidence-based clinical guidelines or hospital procedures.

CDSS that performs more advanced analysis and functions such as specifying a diagnosis or treatment for a patient, is unlikely to meet the exemption criteria. 

This includes software that analyses results or images from medical devices or in vitro diagnostic medical devices to generate diagnostic outputs or recommendations. 

These products must be included in the ARTG unless another exemption applies.

Although exempt CDSS is still considered a medical device, it is subject to fewer regulatory requirements.

Regulatory requirements that apply to exempt CDSS

If your CDSS software is exempt, it does not need to be included in the ARTG. 

However, the following regulatory obligations still apply:

• Sponsors must notify us within 30 working days of supplying an exempt CDSS using the Clinical Decision Support Software Exemption Notification Form. Once notified, you may supply the device if you believe it meets the exemption criteria.
• The exempt software must comply with Essential Principles for safety and performance of medical devices. The Essential Principles cover design, manufacture and intended use. See our guidance on Essential Principles.
• We can take regulatory action such as a recall or issuing a hazard alert if there is a problem with the device.
• Sponsors must report adverse events to the TGA.
• Sponsors must comply with the advertising requirements for therapeutic goods.

Some software may be described as ‘clinical decision support’, but that is not sufficient to qualify as exempt CDSS. 

To determine if your CDSS software qualifies for the exemption, ask the following questions:

1. Is the software a medical device?
2. Is the software a used to support a health professional to make clinical decisions?
3. Does it meet all 3 exemption criteria?

Note

You do not need to assess your CDSS software against the exemption criteria if you have already determined that it:

• does not meet the definition of a medical device; or
• is excluded under the Therapeutic Goods (Excluded Goods) Determination 2018.

In either case, the software is not regulated by us.

Step 1: is the software a medical device?

Your software is regulated by us if it meets the definition of a medical device under Section 41BD of the Therapeutic Goods Act 1989. 

A product is a medical device if it is intended to be used for: 

• Diagnosis, monitoring, prediction, prognosis, treatment or alleviation of disease, injury or disability
• Prevention of a disease
• Compensation for an injury or handicap
• Investigation, replacement or modification of the anatomy or of a physiological or pathological process or state
• Control or support of conception
• in vitro examination of a specimen derived from the human body for a specific medical purpose
• Is an accessory to a medical device. 

If your software is intended for any of these purposes, it is likely to be a medical device. You should then consider whether it is intended to support a health professional to make clinical decisions (see Step 2).

If it is not intended for any of these purposes, it is not a medical device and is not regulated by us.

Examples of CDSS software that is not a medical device

These examples are not medical devices, as they are digitising what was previously a paper-based resource through an interactive software interface. They have no functionality beyond this.

The health professional uses information about their patient to decide which path to proceed, and how to use the resulting information or recommendations.

The software itself is not directly performing or providing recommendations consistent with any of the activities in the definition of a medical device.

Example 1 – App with reference to specific diseases or conditions

A web-based application that provides referenced information about particular diseases or conditions based on a health practitioner’s key-word search of a patient’s symptoms.

The app does not indicate probability of a match/red flag or priorities.

Example 2 – Cancer treatment resource website  

A website that provides referenced cancer treatment information categorised by cancer type. The information is intended as a resource for clinicians who have made a diagnosis to use when making treatment decisions. 

The information is collected in a particular way from a number of references; the treatment information presented would otherwise be available to the health professional.

Example 3 – GPMP tool within CIS

During follow-up appointments, GPs access a Clinical Information System (CIS) that includes patient medical history and hospital discharge summaries. 

The GP uses a GP Management Plan (GPMP) tool within the CIS, which auto-populates information from the patient’s records. The GP uses the tool to select healthcare needs, and relevant treatment plans. The GP reviews the information before confirming and electronically signing the plan.

Explanation 
This CDSS is not a medical device. The GPMP tool extracts information from the EMR without analysing or summarising the information and there is no therapeutic purpose. The information is provided to support the GP to develop a management plan. While recording or extracting the information does not make the GPMP tool a medical device, if the tool analyses the information for a medical purpose (for example, it is used for patient monitoring, or analyses it to provide diagnostic information), the GPMP tool is a medical device.

Step 2: Is the software used to support a health professional to make clinical decisions?

For the purposes of the exemption, a CDSS is software that helps health professionals make decisions about patient care. 

It may provide prompts, alerts, reminders, or recommendations based on clinical data.

If your software is not intended to support clinical decision-making, it is not considered a CDSS and does not qualify for the CDSS exemption. 

If your software provides decision support directly to patients (or any non-health professional user) it also does not qualify for the exemption.

If it is intended to support a health professional to make clinical decisions, proceed to Step 3.

Step 3: Does it meet all 3 exemption criteria?

To be exempt, your CDSS must meet all the following:

(a) is intended by its manufacturer to be for the sole purpose of providing or supporting a recommendation to a health professional about preventing, diagnosing, curing or alleviating a disease, ailment, defect or injury in persons; and

(b) is not intended to directly process or analyse a medical image or signal from another medical device (including an in vitro diagnostic device); and 

(c) is not intended to replace the clinical judgement of a health professional in relation to making a clinical diagnosis or decision about the treatment of patients

A CDSS is only exempt if it meets all 3 of the exemption criteria below.

If your software meets all three criteria, it is likely to be an exempt medical device. You must still meet the regulatory requirements that apply to exempt devices.

If your software is a medical device but does not meet all three criteria, it must be included in the ARTG before it can be supplied in Australia (unless another exemption applies).

With the rapid uptake of artificial intelligence and its growing incorporation into medical devices, it is important to understand that an AI-enabled CDSS will not meet the exemption criteria.

Exemption criterion (a)

(a) is intended by its manufacturer to be for the sole purpose of providing or supporting a recommendation to a health professional about preventing, diagnosing, curing or alleviating a disease, ailment, defect or injury in persons; and

Explanation

The software must be intended only to provide or support a recommendation to a health professional about preventing, diagnosing, curing or alleviating a disease, ailment, defect or injury.

This means the software:

• helps health professionals make decisions through recommendations or information, but
• does not make the decision itself.

It must not:

• diagnose or screen for a condition,
• determine a treatment,
• override a clinician’s judgement, or
• provide information for monitoring a patient’s condition or state of health

A recommendation may include advice to take action, gather more information, or follow a clinical pathway. 

It can also include general information about conditions, risks or treatment options.

Terminology used in exemption criterion (a)

Exemption criterion (b)

(b) is not intended to directly process or analyse a medical image or signal from another medical device (including an in vitro diagnostic device); and 

Explanation

The software must not directly process or analyse:

• medical images (e.g. X-rays, MRIs, CT scans), or
• signals from other medical devices (e.g. patient monitors, ECGs, blood pressure machines, glucose sensors).
• information, data or signals from an IVD medical device

If the software simply displays or retrieves this information from an electronic medical record (EMR), it may still meet this criterion. 

But if it interprets or generates results from that data or displays the information for the purpose of patient monitoring, it is not exempt.

Terminology used in exemption criterion (b)

Exemption criterion (c)

(c) is not intended to replace the clinical judgement of a health professional in relation to making a clinical diagnosis or decision about the treatment of patients.

Explanation

The software must not be intended to replace a health professional’s clinical judgement when diagnosing or treating a patient.

To meet this criterion, the software must:

• be transparent in how it generates recommendations (i.e. cannot use proprietary analysis or AI to generate recommendations),
• provides information that allows the health professional to easily understand and verify the accuracy of the recommendation, and
• clearly references the logic, clinical guidelines, process or evidence all recommendations are based on.

If the software provides information that the health professional cannot independently verify or information that is not available other than through the software, it does not meet this criterion.

Terminology used in exemption criterion (c)

How transparency and interpretability impact exemption status

Basic characteristics of digital clinical support tools can include things like using computers to manage clinical decision-making information, or tools that help healthcare professionals stay focused – such as computerised flowcharts tailored to specific medical problems.

Computerised flowcharts are based on decision-tree models and follow established clinical guidelines. 

They are considered transparent systems – sometimes called “glass box” models – because their internal logic and decision-making process can be clearly seen and reviewed by the clinician, allowing them to apply their judgement.

More complex CDSS can involve the integration of different methods to derive outputs that might not be transparent, accessible, or interpretable by healthcare professionals. 

In contrast to a transparent system, an opaque (sometimes referred to as a ‘black box’) system is one that can only be viewed in terms of its inputs and outputs, without any knowledge of its internal workings. 

A CDSS could be opaque regardless of whether it incorporates technologies such as machine learning. 

Opaque CDSS do not meet exemption criterion (c) and are not exempt.

The following examples demonstrate circumstances where CDSS software is exempt from stricter regulatory oversight.

Example 1 – CIS with computerised clinical scoring

A Clinical Information System (CIS) includes a computerised clinical scoring tool, which digitises the McIsaac (Modified Centor score) criteria for assessing tonsillopharyngitis. 

The general practitioner (GP) enters patient data such as age, presence or absence of fever, cough, exudate and swelling into the system. The software uses these inputs to determine the probability score according to the referenced scoring tool and outputs the recommended treatment pathways. The GP uses their clinical judgement to decide which, if any of the recommended options to follow.

Explanation 
This CDSS is exempt. The scoring tool is evidence-based and transparent (scoring tool is referenced and published) and supports clinical decision-making without replacing the GP’s judgement. It does not process medical images or signals from other medical devices, and its recommendations can be independently verified by the clinician.

Example 2 – EMR asthma module

A clinician selects an asthma module within an electronic medical records (EMR) system to manage patients presenting to emergency department with severe asthma exacerbations. 

The module is based on the evidence-based guidelines from the Australian Asthma Handbook (National Asthma Council Australia, 2019) for acute and life-threatening asthma.

Based on the clinician’s inputs, the module presents all relevant treatment options, including preconfigured medications such as inhaled salbutamol and steroids. The clinician reviews the options, applies their clinical judgement to select a course of action, and electronically signs the selected treatment plan.

Explanation 
This CDSS is exempt. It provides evidence-based recommendations that are transparent (the referenced guideline is published) to support clinical decision-making but does not process medical images or signals from other medical devices. The clinician remains responsible for all treatment decisions.

Example 3 – Thromboembolism Risk Assessment Tool

A clinician uses a Thromboembolism Risk Assessment Tool, which is integrated into an EMR system. 

The tool helps assess a patient’s risk factors for Venous Thromboembolism and recommend appropriate pharmacologic or mechanical prophylaxis. The clinician enters patient-specific information, and the tool generates a list of treatment options including medications. The clinician reviews the options, applies their clinical judgement to select one of the options and electronically signs the selected orders.

Explanation 
The CDSS is exempt. This tool is a published, evidence-based guideline that supports clinical decision-making. It does not process medical images or signals from another device and does not replace the clinician’s judgement.

Example 4 – EMR that flags patient-specific clinical parameters 
An intensive care unit (ICU) uses a ward round pathway integrated into the electronic medical record (EMR) system. 

The tool flags patient-specific clinical parameters, such as abnormal lab results and potential drug–drug interactions. It compiles a summary report for ICU clinicians, including vital signs, medications and relevant case notes.

Based on local ICU protocols and guidelines from the College of Intensive Care Medicine (CICM), the tool recommends whether a patient may be suitable for a clinical trial. Clinicians can access the supporting guidelines via a web link embedded in the EMR.

Explanation 
This CDSS is exempt. It uses evidence-based, locally developed protocols to support clinical decision-making. It does not process medical images or signals from other medical devices and does not replace the clinician’s judgement.

The following examples demonstrate circumstances where CDSS software is not exempt from stricter regulatory oversight.

Example 1 – Diagnostic tool for diabetes

An endocrinologist enters clinical data and laboratory test results – such as HbA1c levels, fasting glucose, and glucose tolerance test results – into a diabetes diagnosis and treatment module within the electronic medical record (EMR) system. 

The module returns a diagnosis of diabetes mellitus and recommends a treatment plan, including drug options that consider the patient’s current medications.

The endocrinologist reviews the suggested plan and makes any necessary adjustments based on their clinical judgement.

Explanation 
This CDSS is not exempt. It does not meet the exemption criteria because it provides a diagnosis of diabetes mellitus based on the input data.

Example 2 – CDSS that analyses x-ray images

A dentist conducts a physical examination and reviews a set of x-rays for a patient presenting with a toothache. To support their decision-making, the dentist uses a CDSS that analyses the x-ray images and reviews the proposed treatment plan.

The CDSS identifies additional cavities or pathologies that the dentist may have missed, and an updated treatment plan is generated. The dentist reviews the findings and discusses the options with the patient before proceeding.

Explanation 
This CDSS is not exempt. The algorithm identifies additional pathologies based on image analysis, and its decision-making process is not transparent or verifiable by the dentist.

Example 3 – Maternal screening tests 

Maternal screening tests are used to assess the likelihood of a foetal chromosomal abnormality. A laboratory conducts biochemical tests on a maternal blood sample and incorporates ultrasound nuchal translucency measurements along with patient demographic information.

Software is used to calculate the probability of the foetus having a chromosomal abnormality. A report is then provided to the obstetrician to support decisions about whether further, more invasive testing is warranted.

Explanation 
This is not considered a CDSS. The software is part of an in vitro diagnostic (IVD) process that combines laboratory results, ultrasound data, and demographic inputs to assess risk. It is classified as IVD medical device interpretive/analysis software and is regulated separately.

Example 4 – Software that flags potential sepsis 

An evidence-based, proprietary sepsis tool monitors clinical parameters and pathology results for signs of sepsis. When certain thresholds are exceeded, the tool generates alerts and recommends a management plan, including preconfigured medications such as antibiotics, based on the patient’s data. 

The intensive care unit (ICU) clinician reviews recommendations and selects the appropriate treatment options before electronically signing the orders.

Explanation 
The CDSS is not exempt because it is for patient monitoring and alerts when a threshold value is exceeded. While evidence-based, the software does not reference or step through the logic or calculations used to inform the alerts and recommendations.

Example 5 – Wound Management 

A smart phone app that utilises the phone camera to take photographs of wounds. The photographs aid in the assessment of pressure ulcers, diabetic ulcers and venous ulcers. Intended to be used by health care professionals, the device can be used for wound imaging, automated wound dimension measurement, and tissue classification. The device uses a machine learning algorithm to determine tissue classification and generates a care plan for the clinician. 

Explanation 
This is not an exempt CDSS. The software has diagnostic functions by classifying tissue and generates treatment plans based on a machine learning algorithm which is not transparent to the clinician.