Sub menu

 
 

Determining exemptions for Clinical Decision Support Software

Detailed guidance for exempt Clinical Decision Support Software which complements the general guidance already published.

Published

Purpose

This guidance is for sponsors, manufacturers, suppliers, and software developers of Exempt Clinical Decision Support Software (CDSS) and provides detailed interpretation of the exemption criteria for certain CDSS. This is to ensure software-based medical devices meet the requirements for quality, safety, and performance. This document complements the general guidance on CDSS that was published by the TGA in February 2021.

Please note that it is the manufacturer’s responsibility to determine if a product is a medical device, according to the intended purpose of the product. Products are regulated as medical devices when they fit the definition of medical device under Section 41BD of the Therapeutic Goods Act 1989 (the Act). Sponsors, manufacturers, suppliers and software developers of CDSS products are responsible for complying with the relevant legislation.

Legislation

Background

In February 2021, the Therapeutic Goods (Medical Devices) Regulations 2002 (the Regulations) were amended by the Government to clarify some existing requirements and to introduce new requirements for software-based medical devices. Certain software-based medical devices were carved-out (through either an exemption or exclusion) from the scope of the TGA regulation, based on the following principles:

  • alignment with international regulatory frameworks where appropriate
  • reduce or remove unnecessary regulatory burden:
    • by not regulating products where there is no significant risk to safety
    • by not regulating where suitable frameworks for product or system oversight are already in place.

The changes applied from 25 February 2021 and information about the changes can be found in Regulatory changes for software based medical devices.

As part of the reforms an exemption was introduced for certain types of CDSS. Exempt software is a medical device but is not required to be included in the Australian Register of Therapeutic Goods (ARTG). However, the following legal requirements still apply:

  • Sponsors must notify the TGA of their exempt CDSS devices. You must notify the TGA using the Notification form: Clinical Decision Support Software Exemption within 30 working days of supply. Following notification to the TGA, you are able to supply the device if you believe it to be exempt.
  • Sponsors of exempt software must ensure it meets the relevant essential principles for safety and performance of medical devices. The essential principles describe the fundamental design and manufacturing legislative requirements. More information on the essential principles can be found in the Manufacture of medical devices: Quality management | Therapeutic Goods Administration (TGA).
  • The TGA 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.

TGA will be reviewing exemption notifications periodically to ensure they are being applied correctly. For guidance on the regulation of medical device software, see How the TGA regulates software based medical devices.

The flow chart in Figure A below can assist you to identify whether or not your CDSS is exempt from regulation by the TGA.

Figure A. Is a particular CDSS exempt?

*Refer to Table 1 for explanations on the criteria. For more information about determining whether your CDSS is a medical device, see Is my software regulated?

This flowchart determines if a medical device is exempt or must be included on ARTG. The decision process is as follows:

  1. Is it a medical device? If yes, proceed. If no, not shown.
  2. Does it support clinical decisions? If yes, proceed. If no, it's not exempt and must be included on ARTG.
  3. Does it meet all 3 criteria:
    1. Intended only for providing/supporting recommendations to health professionals about prevention, diagnosis, curing, or alleviating disease/ailment/defect/injury
    2. Not intended to directly process or analyse medical images or signals from other medical devices
    3. Not intended to replace clinical judgment of health professionals in diagnosis or treatment decisions

If yes to all 3, it's an exempt medical device. If no to any, it's not exempt and must be included on ARTG. Exempt devices proceed to see legal requirements for next steps.

Scope of regulated Clinical Decision Support Software

CDSS is software that can perform a broad range of functions that facilitate, support, and enable clinical practice. An exemption has been made in the regulations for those CDSS that have more limited functionality and meet the exemption criteria described below. These exempt CDSS typically include software that aggregates, analyses, and displays data from electronic medical records (EMRs), electronic health records (EHRs) or clinical information systems (CISs) to provide prompts, alerts, reminders, and recommendations to assist health professionals in implementing evidence- based clinical guidelines and/or hospital procedures.

CDSS that includes functionality such as specifying a diagnosis or treatment for a patient, is likely to require inclusion in the Australian Register of Therapeutic Goods (ARTG) as a medical device. This includes software that analyses results or images from medical devices, or in vitro diagnostic medical devices, to generate a new diagnostic result.

Exemption criteria

The purpose of the exemption for certain types of CDSS is to reduce regulatory burden for sponsors, manufacturers, suppliers, and software developers where the risk is low, as the software supports clinical decision making but does not replace it. All three of the exemption criteria need to be met for the CDSS to be exempt. The below table (Table 1) sets out the exemption criteria.

Exemption criteria: Explanatory table 

Table 1. Exemption Criteria

Exemption criteria 

(Note, a CDSS is only exempt if it meets all 3 of the criteria below)

TerminologyExplanation

  1. 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.

    For information on the distinction between providing or supporting a recommendation about diagnosis or treatment vs.
    making a diagnosis or specifying a treatment, see Table 2 below. 

Health professional:

A Health professional is defined by the Regulations and includes a person who is:

  1. a medical practitioner, a dentist or any other kind of health care worker registered under a law of a State or Territory or
  2. a biomedical engineer, chiropractor, optometrist, orthodontist, osteopath, pharmacist, physiotherapist, podiatrist, prosthetist, or rehabilitation engineer.

Recommendation:

A recommendation means advice to take steps, gather other inputs or follow a course of action. It could also provide general information about diseases or conditions, risks, treatment pathways and prevention.

It does not mean making a diagnosis, providing diagnostic information, or contributing to the diagnosis of a particular disease or condition, nor specifying or customising a particular treatment for a disease or condition.
 

Such functions intend to assist health professionals in making patient-specific care decisions but do not make the decision itself.

They do not treat a patient, determine a patient’s treatment, or provide a diagnosis of a patient’s disease or condition. Instead, these functions collate or develop recommendations based on an analysis of patient-specific information to a health professional, who may then use this information to decide about the care of a patient, along with other information and factors of which the health professional is aware.

It is not exempt if the CDSS itself is making the diagnostic or treatment decisions and changing the way that a health professional would typically render a diagnosis or make a treatment decision.
 

  1. Not intended by its manufacturer to directly process or analyse a medical image or a signal from another medical device (including an in vitro diagnostic medical device).

Directly analyse or process:

The CDSS examines or interprets a signal (or data) produced by a medical device to generate a result or medical image.

Signal:

A signal can include data from sensors like electrocardiogram; heart rate; blood pressure; oxygen saturation; blood glucose; nerve conduction; brain activity or others.

Medical image:

Medical images include MRI scans, X- Rays, PET- Positron Emission Tomography, Computerised Tomography (CT) scans, ultrasound, nuclear medicine imaging, photographs, videos, microscope imaging.

If the CDSS is merely obtaining the results or medical images post hoc – within the EMR, then it would meet one of the exemption criteria. It would need to also meet the other two criteria to be exempt.

If your CDSS is connected to another medical device (or devices), such as an infusion pump or ventilator (or other device), and the CDSS is processing or analysing (interpreting) a signal, such as an ECG waveform, or vital signs such as heart rate or respiratory rate, or a medical image, such as an x-ray or MRI, then it would not be exempt.

  1. Not intended by its manufacturer to replace the clinical judgement of a health professional in relation to making a clinical diagnosis or decision about the treatment of patients. 

Replace clinical judgement:

Any steps that would normally be taken by the health professional such as making a diagnosis or a decision.
 

Where the intention is to provide a clinical diagnostic decision or treatment information that the health professional would not otherwise have access to, or be able to verify, then it would not be exempt.

Therefore, if an EMR, EHR or CIS contains CDSS functionality that incorporates methods to reach a diagnosis, without that method being published and transparent, and without the health professional being able to verify it, then it would not be exempt. Transparency in this instance means that it is possible for the health professional to be able to understand the steps taken to reach a decision.

The manufacturer/software developer should describe the underlying logic and data used to develop the algorithm and should include plain language descriptions of the logic or rationale used to render a recommendation. In addition, the sources underlying the basis for or supporting the recommendation should be identified and available to the health professional (e.g., clinical guidelines, hospital procedures or publications of completed studies/literature – with the accompanying date or version), and understandable by the health professional.

The following table (Table 2) provides clarity on the distinction between:

  • making a diagnosis vs. making a recommendation about diagnosis
  • specifying treatment vs. making a recommendation about treatment.
Table 2. Distinction between different terms
Diagnosis
  • identifying a specific disease or condition, e.g., melanoma, diabetes or dental caries
  • identifying a lesion
  • classifying a lesion
  • identifying features typical of a type of lesion
  • highlighting anomalies and suggesting they are a lesion.
Making a recommendation about diagnosis
  • suggesting further investigation, e.g., tests, scans, x-rays etc.
  • suggesting other action such as recall, second reading etc.
  • highlighting anomalies for example in imagery or proposed treatment plan
  • highlighting areas for follow up or further analysis
  • identifying insufficient information or invalid data for diagnosis
  • identifying the appropriate diagnostic pathways or protocols for the health care facility
  • displaying a clinical practice guideline relevant to the diagnostic situation.
Treatment
  • displaying a decision that a patient should be delivered a specific treatment or procedure
  • specifying treatment parameters such as calculations for treatment that are tailored to a patient’s anatomy.
Making a recommendation about treatment
  • providing options for treatment pathways
  • generating a treatment plan based on a clinical pathway or protocol for the health care facility
  • recommending types of treatment based on a clinical practice guideline.

Where do I go if I have more questions?

  • you can contact the TGA via digital.devices@tga.gov.au
  • SME Assist is a dedicated service the TGA provides to assist small to medium enterprises (SMEs), researchers, start-ups and those unfamiliar with regulation to understand their regulatory and legislative obligations
  • the Medical Device Information Unit, ph. 1800 141 144, is an information hotline that can provide you with assistance on devices-related inquiries.

The following appendices contain supporting information pertaining to CDSS characteristics, accompanied by a series of clinical scenarios to assist readers in interpreting the exemption criteria.

Appendix A: CDSS characteristics

As referred earlier within this guidance, basic characteristics can include factors such as the computerisation of clinical decision support resources for information management, or tools that help better focus the healthcare professional’s attention, such as computerised problem-specific flowcharts.

These problem-specific flowcharts are examples of decision-tree models. These are based on conventional clinical guidelines and are readily interpretable and are transparent systems (or ‘clear box’, or ‘glass box’). This is where the inner components or logic are available for inspection.

See Figure B below:

Figure B: Basic exempt transparent CDSS

This diagram illustrates software for providing recommended treatment options. It shows 3 input sources feeding into a central process, which then produces an output.

The input sources are:

  1. clinical guidelines, represented by a stack of documents
  2. patient-specific information (e.g., demographic data, vital signs, laboratory results, etc.), represented by a medical chart and graph
  3. a computer or device icon in the centre, representing the software processing the inputs. The output is shown as 2 human figures, indicating recommended treatment options or management plan based on patient-specific data.

More complex CDSS can involve the integration of different CISs and/or ‘black box’ methods to derive outputs that might not be transparent, accessible, or interpretable by healthcare professionals. In contrast to a transparent system, 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. Its implementation is opaque, sometimes known as ‘black box’. The black box term may apply to any CDSS regardless of whether it incorporates technologies such as machine learning.

It is important to note that not all complex CDSS contain uninterpretable algorithms. A CDSS that is a medical device can still be complex, but if the internal workings are interpretable and understandable by the health professional then it may meet one of the exemption criteria.

The following examples attempt to illustrate these points:

  1. Where the CDSS is housed as a module within the EMR, and the EMR is integrated with a medical device which is sending data to the EMR, provided the data is not being processed or analysed by the CDSS, i.e., changed in any way, then the CDSS would meet one of the exemption criteria.
  2. Where a patient is being cared for remotely by clinicians (virtual hospital), and the patient’s vital signs are being captured by medical devices (e.g., pulse oximeters, temperature probes) and sent to the EMR via Bluetooth or manually by the patient, and then used to guide recommendations about treatment, then the CDSS would meet one of the exemption criteria, because it is not processing or analysing the data.
  3. If the CDSS is processing signals or medical images from other medical devices, and/or using opaque methods that are not accessible or interpretable by a health professional, then they are not exempt.

The below example (Figure C) depicts a complex multi-system software system located within a hospital setting that is used to diagnose breast cancer. The software integrates with a digital mammography system and displays image inputs from multiple modalities including blood test results, X-rays, ultrasounds, and MRI scans. It allows for a range of functions including selection, display, annotation, and image transfer. The CDSS software identifies regions of interest, along with likely diagnoses to the health professional. The system aids in the diagnosis of breast cancer and the internal workings of the software are not transparent nor accessible by the health professional so this example clearly does not meet the exemption criteria.

Figure C: Software to diagnose breast cancer

This diagram depicts software for diagnosing breast cancer.

It shows 3 components:

  1. Input: Medical imaging (ultrasound, MRI, X-ray) represented by medical device icons
  2. Input: Patient data (test results, symptoms, PMH) represented by a medical chart icon
  3. Central processing: A computer icon representing the diagnostic software
  4. Output: Defined output (diagnosis for clinician) represented by 2 human figures.

Similarly, a system used to detect malignant melanoma by analysing the images generated by the dermoscopy imaging system, then generating a lesion classification for the health professional would be a medical device but would not be exempt. This is because the system is intended to detect malignant melanoma and provides a diagnosis – a lesion classification in this case. See Figure D below.

Figure D: Software to diagnose melanoma

This diagram illustrates software for diagnosing malignant melanoma. 

It consists of 3 components:

  1. Input: Dermoscopy imaging, represented by a magnifying glass icon examining skin
  2. Central processing: A computer icon representing the diagnostic software
  3. Output: Lesion classification, represented by 2 human figures.

The following diagram (Figure E) highlights the difference between transparent software and opaque (sometimes known as “black box”) software by setting the examples side-by-side. The scenario is a clinician consulting with a patient who has a suspicious mole. The left side of Figure E demonstrates a transparent software system that would be exempt. The right side of Figure E demonstrates software that would not be exempt.

Figure E: Patient with a suspicious mole

This diagram compares exempt and non-exempt systems for patient consultation on a suspicious mole.

It is divided into 3 sections:

  1. Top: A doctor icon representing the patient consultation
  2. Left (Exempt): A transparent system with icons for:
    • Clinician reviewing patient-specific information
    • CDSS providing recommended management options based on guidelines
    • Management/treatment plan based on clinician's interpretation
  3. Right (Not Exempt): An opaque system with icons for:
    • Clinician using imaging to capture mole pictures
    • CDSS analysing images with non-transparent AI
    • CDSS generating lesion classification without clinician's direct interpretation.

Appendix B: Clinical settings and scenarios

CDSS is used across the health care continuum within the Australian health system: from health promotion and disease prevention, to primary and community care, to specialist, acute and residential care.

The following table presents a series of patients and their associated symptoms which describe scenarios within different environments, along with examples of CDSS that meet OR do not meet the exemption criteria.

Table 3: Clinical scenarios
SettingCDSS Example
These scenarios are based on real world examples with references supplied.
 		Discussion of whether the CDSS meets the criteria of the Exemption or notExempt vs. not exempt
SettingCDSS Example These scenarios are based on real world examples with references supplied.Discussion of whether the CDSS meets the criteria of the Exemption or notExempt vs. not exempt

Scenario 1

Meera 12, attends her GP complaining of a sore throat, cough, and fever (<3 days).
 

The GP takes a clinical history and conducts a physical examination of Meera.

The GP accesses the practice’s CIS*, which incorporates a clinical scoring tool used to predict the likelihood of tonsillopharyngitis, and the need for antibiotics1. The clinical scoring tool is based upon the McIsaac (Modified Centor score) criteria. It is a clinical scoring tool to aid clinicians in prescribing antibiotics for acute tonsillopharyngitis in low-risk situations.

The GP enters patient specific information including age range, presence/absence of fever, cough, exudate, swelling, and a probability is returned, along with a recommended treatment plan. The GP exercises their own judgement as to which of the recommended options to enact.

The CIS incorporates a computerised clinical scoring tool that is evidence-based and accessible to the GP via a web link. The GP can review the evidence, including the clinical scoring tool logic and associated recommended treatment pathways.

The software compares a particular patient’s symptoms with the clinical scoring tool to recommend treatment, with the guidelines described as the basis for the recommendation.

It meets the exemption criteria:

  • as it is not processing or analysing a medical image or signal from another medical device.
  • it is only providing or supporting a recommendation about possible treatment options.
  • it is not replacing the clinical judgement of the GP and the CDSS is providing information that the GP can otherwise verify.
Exempt

Scenario 2

2 days later, Meera’s mother Claudia attends her GP for exacerbation of asthma. Claudia has a cough and a mild wheeze.

The GP takes a clinical history and conducts a physical examination of Claudia. Claudia’s asthma is normally well controlled.

The GP accesses the ‘Asthma Consult Checklist’ which is a clinically validated tool published by Asthma Australia2 and incorporated within the CIS. The tool is used to manage non- emergency flare-ups and takes health professionals through the recommended steps to manage a patient experiencing an acute exacerbation. The GP works through the tool in concert with Claudia, and based on her symptoms, generates a recommended management and treatment plan, which is then presented on the screen. The GP can use their own judgement as to which options should be enacted.

The CIS incorporates the ‘Asthma Consult Checklist’ which is a clinically validated tool published by Asthma Australia and available at its website. There is a link to the website embedded within the CIS, which can be verified by the GP.

Based on the responses to the tool, the recommended management and treatment plan is produced, which is patient specific.

It meets the exemption criteria as:

  • it is not processing or analysing a medical image or signal from another medical device.
  • it is only providing or supporting a recommendation for management and treatment.
  • it is not replacing the clinical judgement of the GP. The software is providing information that the GP can otherwise verify.
Exempt

Scenario 3

The following day, Claudia presents to the Emergency Department for severe exacerbation of her asthma.

Claudia is reviewed by the ED clinician who selects the asthma module that has been configured within the EMR and derived from an evidence-based guideline for treatment of asthma. The guideline is taken from the latest Australian guidelines from the Australian Asthma Handbook published by the National Asthma Council Australia (2019) for acute and life-threatening asthma management.3

It incorporates a set of treatment options that are presented on the screen, based on inputs by the ED clinician. Treatment options include the presentation of preconfigured medications such as inhaled salbutamol and steroids, which are derived from the guideline. The ED clinician is required to electronically sign the medications once the relevant options have been selected on the screen.

The ED clinician is still able to exercise their own clinical judgement as to which treatment options – including medications, will be ordered before entering their electronic signature.

The EMR incorporates a clinically validated tool contained in the Australian Asthma Handbook published by the National Asthma Council (NAC) Australia. There is a link to the website embedded within the CIS, and the ED clinician can browse to the NAC website to access the information and view the treatment flow chart.

The treatment options, including medications, are displayed in the EMR based on the responses to each question, and are patient specific.

It meets the exemption criteria as:

  • it is not processing or analysing a medical image or signal from another medical device.
  • it is only providing or supporting a recommendation about possible treatment options.
  • it is not replacing the clinical judgement of the ED clinician. The software is providing information that the ED Clinician can otherwise verify.
Exempt

Scenario 4

The ED clinician decides to admit Claudia as an inpatient.

Prior to transferring Claudia to the ward, the ED clinician enacts the Venous Thromboembolism (VTE) Risk Assessment Tool.4 The tool is published by the Clinical Excellence Commission (CEC, NSW) and is for use in adult patients (>16 years) admitted to a NSW public hospital or health service.

The VTE tool is integrated within the EMR and identifies VTE risk factors and contraindications to pharmacologic VTE prophylaxis.

The ED clinician completes the checklist according to Claudia’s risk and clinical condition, and a set of recommended treatment options appear on the screen, including a preconfigured set of orders, including medications. Treatment options include the presentation of preconfigured VTE prophylaxis such as anticoagulant therapy or mechanical devices, which are derived from the guideline. The ED clinician is required to electronically sign the orders once the relevant options have been selected on the screen.

The ED clinician is still able to exercise their own clinical judgement as to which treatment options – including medications, will be ordered before entering their electronic signature.

The EMR incorporates the risk assessment tool, which is evidence-based and published by the CEC (NSW).

There is a link to the website embedded within the CIS, and the ED clinician can browse to the CEC website to access the information and view the risk assessment flow chart.

The treatment options are displayed in the EMR based on the responses to each question and are patient specific.

It meets the exemption criteria as:

  • it is not processing or analysing a medical image or signal from another medical device.
  • it is only providing or supporting a recommendation about possible treatment options.
  • it is not replacing the clinical judgement of the ED clinician. The software is providing information that the ED Clinician can otherwise verify.
Exempt

Scenario 5

While in the ICU, Claudia is actively monitored for signs of sepsis.

The EMR incorporates an adult sepsis pathway that automatically scans the EMR for signs and symptoms of possible sepsis. The pathway is based upon evidence-based sepsis tools and published by the Clinical Excellence Commission (NSW) and directly links with the Australian Commission on Safety and Quality in Health Care's National Safety and Quality Health Service Standards.
The sepsis pathway tool generates warnings to alert clinicians if clinical parameters and/or pathology results are out of limits and is also able to generate a management and treatment plan.

The management and treatment plan is derived from the pathway and presents preconfigured orders, including antibiotics, which can be selected by the ICU clinician.

The ICU clinician is required to electronically sign the orders once the relevant options have been selected on the screen.

The ICU clinician is still able to exercise their own clinical judgement as to which treatment options – including medications, will be ordered, before entering their electronic signature.

The EMR incorporates the sepsis pathway tool, which is a clinically validated tool and evidence based.

The guideline upon which the sepsis pathway is based is accessible via clicking on the web link embedded within the EMR, so clinicians can review it.

The potential treatment options are displayed in the EMR and are patient specific.

It meets the exemption criteria as:

  • it does not directly process or analyse a medical image or a signal from another medical device. The information is contained within the EMR only.
  • it is only providing or supporting a recommendation to the ICU clinician about potential indicators of sepsis and treatment options.
  • it is not replacing the clinical judgement of the ICU clinician, who is able to determine whether a patient has sepsis and if so what treatment to provide. The software is providing information that the ICU clinician can otherwise verify.
Exempt

Scenario 6

Claudia remains a patient in the ICU.

As part of the ongoing management of Claudia ’s condition, the EMR incorporates a ward round pathway that collates stored patient information for the purposes of flagging patient-specific clinical parameters such as out-of-range laboratory tests and potential drug-drug interactions and compiles a report for review by ICU clinicians on clinical ward rounds. The information presents vital signs, pathology results, medications and IV infusions, along with relevant case notes. Based on patient- matched information, the ward round pathway is also able to present a recommendation regarding Claudia’s suitability for a current clinical trial, which the ICU has been participating in, as part of a multi-centre, investigator-initiated research project occurring in Australasian ICUs.

The pathway is a locally developed ICU protocol that is taken from resources published by the College of Intensive Care Medicine (CICM) of Australia and New Zealand, and The Australian and New Zealand Intensive Care Society Clinical Trials Group.

The CDSS incorporates a locally developed protocol that is evidence-based and drawn from resources published by the CICM, which the clinicians can access via clicking on the web link embedded within the EMR.

The report is displayed in the EMR and is patient specific.

It meets the exemption criteria as:

  • it is not processing or analysing a medical image or signal from another medical device. Although the medical devices are interfacing with the EMR the data is simply being sent by the interface for capture and storage within the EMR. It is not being changed in any way as part of that process.
  • it is only providing or supporting a recommendation about diagnosis and treatment.
  • it is not replacing the clinical judgement of the ICU clinician.
Exempt

Scenario 7

After 10 days in ICU, Claudia is transferred to a ward.

Claudia’s medical history includes diabetes. In order to optimise their patients’ glycaemic control, the junior doctors and nurses on the ward utilise a clinical decision support app called ‘Thinksulin.5 As part of the ‘Leading Better Value Care’ program, the app has been designed and developed by the NSW Diabetes Taskforce, Agency for Clinical Information (ACI), and is in use in NSW public hospital facilities.6
The app supports point of care decision making by providing information and decision support on blood glucose level targets, hypoglycaemia management, blood glucose monitoring, basal- bolus calculations, and charting and reviewing doses.

Junior doctors and nurses can utilise the app on a mobile device and enter relevant patient information to provide recommendations about treatment.

NB: the app does not store information on the device.

Claudia’s diabetic treatment is also overseen by an endocrinologist who reviews Claudia’s progress in the EMR.

The app is available via a mobile device which junior doctors and nurses can download.

The guideline is evidence based.

The information is also accessible via a weblink, so clinicians can review it.

It meets the exemption criteria as:

  • it is not processing or analysing a medical image or signal from another medical device.
  • patient information is entered into the app to render the recommendations, noting that the information is not locally stored within the app.
  • it is only providing or supporting a recommendation about diagnosis and treatment.
  • it is not replacing the clinical judgement of the ICU clinician.
Exempt
After 5 days on the ward, Claudia improves and is discharged home.
Primary & Community Care

Scenario 8

Claudia attends her local GP for follow-up post discharge from hospital.

The GP conducts a physical examination and reviews Claudia’s clinical history, including the hospital discharge summary, (which may have been transferred electronically from the hospital to the GP CIS).

The GP reviews her current symptoms and enters these into the CIS, which already incorporates laboratory and diagnostic imaging results.

The GP prepares a GP Management Plan (GPMP) to outline Claudia’s healthcare needs, relevant conditions, management goals, and treatment and services needed.7 The CIS incorporates a GPMP tool which can be auto populated from patient data already recorded within the CIS.

The GP can review the data and make adjustments using their own clinical judgement and clinical assessment skills before confirming the information is correct and ready to be signed electronically.

The CIS incorporates a GPMP tool which can be auto populated with patient data already recorded within the CIS.

The GPMP tool has been developed to augment management of patients with chronic and or/complex disease. It has been developed in consultation with the Royal Australian College of General Practitioners (RACGP) and is published at the RACGP’s website and is accessible to the GP.

It meets the exemption criteria as:

  • it is not processing or analysing a medical image or signal from another medical device.
  • it is only providing or supporting a recommendation about diagnosis and treatment.
  • it is not replacing the clinical judgement of the GP, who is able to review the data and make adjustments using their own clinical assessment
    skills.
Exempt

Scenario 9

Claudia’s mother Margaret has been referred to an endocrinologist to investigate symptoms of Type 2 diabetes mellitus. She visits a hospital outpatient clinic.

The EMR contains an endocrinology-specific module which provides clinicians with a digital tool for the diagnosis and treatment of diabetes mellitus.

The endocrinologist enters Margaret’s information (such as laboratory test results, e.g., HbA1c, fasting glucose and glucose tolerance test results) into the module. Margaret’s medical history is already recorded within the EMR.

The module takes Margaret’s past medical history into account, and along with the pathology information returns a diagnosis of diabetes mellitus. It also provides a recommended treatment plan.

The endocrinologist can determine drug treatment as the module takes into account Margaret’s usual medications and whether there are likely to be any contraindications to drug treatment. This information is presented as part of the recommended treatment plan.

The endocrinologist can exercise their own judgement and clinical assessment skills in determining which aspects of the treatment plan to enact.

The CDSS incorporates an evidence-based diabetes mellitus diagnosis and treatment module that has been computerised.

Based on the inputs (including the test results), the recommended diagnosis and treatment plan is produced, which is patient specific.

The guideline upon which the CDSS is based is accessible, so the endocrinologist can review it by clicking on the web link embedded within the EMR.

This CDSS does not meet the exemption criteria as:

  • it diagnoses diabetes mellitus.
Not exempt

Scenario 10

Margaret has a toothache so visits her local dentist to investigate.

The dentist conducts a physical examination, along with a set of x-rays, and reviews Margaret’s dental history.

The dentist produces a proposed treatment plan and uses CDSS to review the plan. The CDSS examines the x-ray images and can identify additional cavities and areas requiring further follow-up.

The proposed treatment plan also takes into account Margaret’s prior dental history.

The dentist and Margaret discuss the findings to determine the next course of action.

The CDSS examines the x-ray images which have been uploaded from the x-ray machine. This does not produce a new (or changed) result or image.

The CDSS reviews the x-ray images and compares them with the dentist’s findings. It is able to identify additional pathologies (e.g., dental caries) that may have been missed during the initial dental examination.

A suggested treatment plan is produced, which is patient specific.

The CDSS uses an algorithm which is not able to be interpreted by the dentist.

This CDSS does not meet the exemption criteria as:

  • the algorithm deployed by the CDSS identifies additional pathologies, is not transparent and is unable to be verified by the dentist.
Not exempt
Acute

Scenario 11:

Jay, 44, presents to emergency with symptoms of COVID-19, including cough, fatigue, fever, and gastrointestinal symptoms. He has had a COVID- 19 PCR test and is awaiting the result.

Jay is reviewed by the ED clinician who selects the COVID-19 risk assessment tool8 which is integrated with the hospital EMR and incorporates COVID-19 risk factors and severity of illness.

Jay’s clinical information, including his laboratory results, are entered into the tool by the ED clinician, and the system generates a severity score, and a recommended management plan, including recommended treatment.

Based on the information presented, it is determined that Jay should be admitted to the hospital for observation.

The EMR incorporates the risk assessment tool, which is evidence-based. The risk assessment tool is based on the ‘Emergency department assessment and management of COVID-19 in adults’, published by NSW Health.9 This tool is for staff attending to adults presenting to NSW emergency departments with suspected or confirmed COVID-19 infection.

It does not incorporate any additional analysis or logic other than that published by NSW Health.

The severity score and management plan generated is based on Jay’s clinical symptoms, medical history, and laboratory results.

The tool upon which the questionnaire is based is accessible via a web link, so the ED clinician can review it.

It meets the exemption criteria as:

  • it is not processing or analysing a medical image or signal from another medical device.
  • it is only providing or supporting a recommendation about management and
    treatment options
  • it is not replacing the clinical judgement of the ED clinician. The software is providing information that the ED clinician can otherwise
    verify.
Exempt
Primary & Community Care

Scenario 12

Following his treatment for COVID-19 as an in-patient, Jay is transferred to the hospital’s ‘virtual hospital’ in the home.

Jay is provided with a pack from the virtual care clinical team containing medical devices such as a pulse oximeter to measure oxygen saturation and heart rate and a temperature patch. Jay is also provided with an iPad so his oxygen saturation, heart rate and temperature results can be uploaded to the mobile application via Bluetooth (or be captured manually) and communicate via video during calls from the virtual care clinical care team who are located in the hospital in a purpose-built pod.

The virtual care clinical care team contact Jay via video conference twice a day, and they discuss how he is feeling, along with any changes in his vital sign observations.

The model of care has been developed by a multi-disciplinary team including specialist medical, nursing, and allied health staff and has been endorsed by the state health department. The model of care is integrated within the EMR and includes risk stratification and decision-making pathways that guide care and treatment. Parameters and alerts are also configured for each observation type.

The tools that guide care and treatment are evidence-based and accessible to the clinical staff via an embedded web link. The virtual care clinician is still able to exercise their own clinical judgement as to how Jay’s care is managed. The tools provide recommendations only.

Jay’s GP is advised of his admission to the virtual hospital.

The model of care informs workflow and care plans, including escalation and referral pathways, which ensure timely and appropriate review and early identification of deterioration.

The medical devices (e.g., pulse oximeter etc.) are connected via Bluetooth and the observations stored in the virtual patient monitoring module of the EMR. This module presents a real time dashboard to clinicians working within the virtual care clinical team. Alerts are triggered when any of the observations are outside of the target ‘Between the Flags’ ranges. Should this occur, the clinician can contact Jay urgently, requesting repeat observations, and where necessary transfer him to hospital via ambulance.

The EMR incorporates the tools which are clinically validated, and evidence based.

The risk stratification and decision-making pathways are accessible via clicking on the web link embedded within the EMR, so virtual care clinicians can review them.

The possible treatment options are displayed in the EMR and are patient specific.

It meets the exemption criteria as:

  • it is not processing or analysing a medical image or signal from another medical device (the devices are connected via Bluetooth).
  • it is only providing or supporting a recommendation about management and treatment options.
  • t is not replacing the clinical judgement of the clinician. The tool is providing information that
    the clinician can otherwise verify.
Exempt

Scenario 13: 

Claudia’s sister Mae has been referred for screening as her pregnancy has been identified as high risk.

Mae’s obstetrician orders a maternal screening test to be performed by the pathology laboratory to detect the likelihood of a foetal chromosomal abnormality.

The laboratory performs a number of biochemical tests on Mae’s blood. The test results are analysed in the laboratory using software that also incorporates ultrasound nuchal translucency measurements and other patient demographic information. The software calculates the probability of the foetus having a chromosomal abnormality which will inform the decision as to whether a more invasive procedure is required (such as amniocentesis). A report is issued by the laboratory to the requesting obstetrician.

The tool allows for the integration and interpretation of nuchal translucency results (i.e., use of nuchal translucency measurements) combined with the results from several IVD medical devices to generate new diagnostic information that is then reported to the requesting doctor to inform a decision as to whether a more invasive procedure is required.

This is not considered to be a CDSS. This type of software is regulated as IVD medical device interpretive/analysis software.
 

Not exempt

Footnotes

  1. https://www1.racgp.org.au/getattachment/a12ade12-e5b0-436b-af40-77993dbf9b52/Antibiotic-prescribing-for-tonsillopharyngitis.aspxe 
  2. https://asthma.org.au/wp-content/uploads/2021/03/AAACCFU2020A4-Asthma-Consult-Checklist-Flare-Ups_v3.pdf
  3. https://aci.health.nsw.gov.au/networks/eci/clinical/clinical-tools/respiratory/asthma/asthma-management 
  4. https://www.cec.health.nsw.gov.au/   data/assets/pdf_file/0010/458821/Venous-Thromboembolism-VTE-Risk-Assessment-Tool.pdf 
  5. https://nadc.net.au/wp-content/uploads/2019/08/7.-Marina-Davis.pdf 
  6. https://aci.health.nsw.gov.au/networks/endocrine/inpatient-management-of-diabetes-mellitus 
  7. https://www.racgp.org.au/FSDEDEV/media/documents/Clinical%20Resources/Guidelines/Diabetes/Appendix-B.pdf
  8. Emergency department assessment and management of COVID-19 in adults https://www.health.nsw.gov.au/Infectious/covid-19/communities-of-practice/Pages/guide-ed-assessment-management.aspx 
  9. ibid.
Topics

Page history

Show all page updates (1)

Original publication.

Original publication.

Help us improve the Therapeutic Goods Administration site