The Therapeutic Goods Administration (TGA), an Australian regulating authority in the sphere of medical devices, has published a document providing examples of regulated and unregulated software and software-based medical devices. The document is intended to assist medical device manufacturers (software developers) in interpreting respective provisions of the applicable legislation in terms of software-based products, as well as regulatory requirements they are subject to. At the same time, it is important to mention that the document is non-binding, so in case of any discrepancies with the provision of existing regulations the latter should prevail. As explained by the TGA, the document is intended to assist in distinguishing regulated and unregulated software by describing in detail the particular requirements to be applied to make such a determination. However, the determination process itself is addressed in a separate guidance document issued by the TGA.
Table of Contents
Regulatory Changes
First of all, the TGA provides a brief overview of the recent regulatory changes related to the applicable framework for software-based products. As explained by the authority, existing legislation was subject to certain changes and amendments. In particular, some new exclusions and exemptions have been introduced.
- An exclusion means that the devices are completely unregulated by TGA;
- An exemption means that TGA retains some oversight for advertising, adverse events, and notification, while registration of the devices is not required.
Thus, the products falling within the scope of the first category are not considered medical devices. Hence, the requirements for medical devices should not be applied to these products. As described by the TGA, if the product is explicitly mentioned in the list of excluded products, it would not be subject to regulation by the authority, otherwise, its manufacturer should still consider such an opinion and take steps to determine its regulatory status by the general rules and criteria. In particular, the manufacturer should check whether the product in question meets the definition of a medical device set forth by the applicable legislation.
As it is also mentioned in the guidance, clinical decision support software (CDSS) could be also subject to an exemption. As described hereinabove, products subject to exemption are considered medical devices, but some of the general requirements for these products could be waived. Hence, according to the applicable regulations, CDSS could be:
- Medical devices are subject to any regulatory requirements,
- Medical device subject to exemption (some of the requirements should not be applied),
- Not a medical device.
Should the software in question fall within the scope of the last category, it wouldn’t be regulated by the TGA.
Key Concepts
The guidance further describes two main aspects that should be taken into consideration when determining the regulatory status of the software product subject to review, namely:
- Is the software intended to be used for medical purposes? This criterion is used to check whether the product in question falls within the scope of the definition of a medical device set forth by the Therapeutic Goods Act. The aforementioned definition outlines the scope of uses that are considered medical purposes. Should the software product meet any of them, it will be considered a medical device. These uses include, inter alia, diagnostic, treatment, prevention of diseases and disabilities, compensation of injuries, or control of conception. The scope of definition also covers products that are accessories to medical devices – the products that are initially intended to be used with a medical device to ensure it operates as intended.
- Does the software meet the exclusion criteria? According to the guidance, some of the software products could be excluded provided their functionality is limited to specific functions. To determine whether the software is excluded, one should assess whether it meets the appropriate criteria, which are also described in the present guidance.
According to the document, the software will be deemed excluded in case its functionality is limited to the following functions:
- Consumer health life-cycle prevention, management, and follow-up. The products falling within the scope of this category are intended to be used in the context of not serious conditions (provided they are not used for treatment), for general wellness purposes. The category also covers coaching software that does not provide recommendations that should be interpreted by a healthcare professional, tools for patient surveys, and also digital mental health tools.
- Enabling technology for telehealth, health care facility management. This category covers communication software, as well as the software used to administer internal processes within healthcare institutions. Additionally, this category covers software intended to provide alerts, provided that the final decision should be made by a healthcare professional having the necessary qualifications and experience; and also clinical workflow management software.
- Digitization of paper-based or other published clinical rules or data. The products falling within the scope of this category include calculation tools based on the use of data from authoritative sources, and also Electronic Patient Records (EMRs) and Electronic Health Records (EHRs), except the tools used to administer the dosage. The main criterion is that the final decision and actions should be taken by a user.
- Population-based analytics. This category includes software intended to analyze data related to large groups, provided such software is not used to make decisions regarding specific cases.
- Laboratory information management systems (LIMS) and laboratory information systems (LIS) except the software intended to process the input data and provide outputs.
Determination of Regulatory Status: Examples
The document further provides several examples which describe the way the approach described herein should be applied when determining the regulatory status of the software in question by the applicable regulatory requirements. The examples provided in the document include, inter alia, the following ones:
- Kilojoule counter. The first example describes a mobile app designed to provide information about the energy content of food. In particular, the tool allows scanning barcodes placed on the package to get information about the energy content. Since such software is not intended for medical purposes, it should not be subject to regulation under the framework of the medical device.
- Software that is used to diagnose hypertension and risk of cardiac disease. Another software described in examples is a tool intended to analyze information regarding the user to assess the risk of cardiac disease. Since the software is intended to diagnose and predict the disease, it falls within the scope of the definition of a medical device. Moreover, due to the fact it is intended to be used in the context of a serious disease, it does not meet the exclusion criteria. Hence, such a product should be subject to regulation as a medical device. For instance, it should be included in the Australian Register of Therapeutic Goods (ARTG).
In summary, the present document provides an overview of the main principles and approaches to be applied when determining the regulatory status of the software subject to review. The document outlines the most important aspects to be taken into consideration when making such a determination and also describes in detail the applicable exclusions and exemptions.
Sources:
How Can RegDesk Help?
RegDesk is a next-generation web-based software for medical device and IVD companies. Our cutting-edge platform uses machine learning to provide regulatory intelligence, application preparation, submission, and approvals management globally. Our clients also have access to our network of over 4000 compliance experts worldwide to obtain verification on critical questions. Applications that normally take 6 months to prepare can now be prepared within 6 days using RegDesk Dash(TM). Global expansion has never been this simple.
