Introduction
The definition of an IVD medical device in the Therapeutic Goods (Medical Devices) Regulations 2002 includes software. IVD software is used with or in many devices - in laboratory based or point of care analysers, in hand-held personal IVDs, as standalone software, as software upgrades to existing systems, etc. The regulations make no distinction between different forms of software; all software that meets the definition of an IVD medical device must conform to the essential principles in order to assure the product’s safety, quality and performance.
Software is regulated in different ways depending on the manufacturer's intended purpose and how it is supplied. The intended purpose of the product can be ascertained from any one or more of the following: the labelling on the software; the instructions for use; any advertising material relating to the software; and technical documentation describing the mechanism of action between software and other IVDs.
The table on the following pages details how different types of software are regulated.
Software standards
The international standard IEC 62304 Medical device software - Software life cycle processes addresses requirements that are specific to software, while the IEC 62366 Medical devices - Application of usability engineering to medical devices standard addresses usability engineering requirements for all devices, including those that are wholly or partially software based.
The TGA considers these standards as representing the state-of-the-art for medical device software.
IEC 62304 requires design control for all software; this requirement is applicable irrespective of whether or not the manufacturer holds certification under Schedule 3, Part 1 or Schedule 3, Part 4 of the Regulations. In addition to life cycle management, the TGA expects manufacturers to have implemented appropriate methodologies to ensure that quality is an inherent property of the software design.
Labelling requirements
Minimum labelling requirements apply to medical device software, regardless of whether it is:
- downloaded from the Internet;
- installed from a CD; or
- pre-installed by the manufacturer on a device.
Manufacturers need to ensure that the product information, such as the graphical user interface, screenshots, CD labels, and product demos meet the requirements of Essential Principle 13.
| Type of software / intended purpose | How is it regulated? | Examples | Comments |
|---|---|---|---|
| 1. Software that is built into an IVD medical device (e.g. instrument or analyser) | The instrument with the installed/ embedded software is a single IVD, i.e. the software does not require a separate inclusion in the ARTG. |
Any software that is supplied pre-installed on an IVD instrument, e.g. operating software in a clinical analyser, point of care analyser or personal use IVD such as a glucose meter. In these cases, the software is a part of the device and is not considered to be a separate or distinct device. |
The IVD classification rule 1.6 in Schedule 2A specifies that all instruments that are IVDs are Class 1 IVDs The legislation applies to all forms of medical device software including software that is embedded (for example, firmware in hardware) including:
|
| 2. Software that is supplied separately to an IVD medical device (e.g. instrument or analyser) but which is intended to operate or influence the IVD | As a distinct IVD that is separate to the IVD instrument/ analyser |
Software for operating an IVD instrument that is installed on a computer interface used for the control of the IVD instrument. Software for upgrading functionality that is to be installed on an IVD instrument or connected computer interface |
According to Regulation 3.3(5) under Principles for applying the classification rules in the Regulations, software that drives or influences a medical device has the same classification as the medical device As the IVD classification rules in Schedule 2A specify that all instruments that are IVDs are Class 1 IVDs, the software is therefore also a Class 1 IVD but requires a separate inclusion in the ARTG as it has a different GMDN code. Note: Software that is intended to drive or influence a non-IVD medical device must be classified in accordance with Regulation 3.3(5) and the medical device classification rules in Schedule 2. |
|
3. Software that is intended to be used to provide diagnostic or therapeutic information and is not intended to drive or influence an IVD medical device (e.g. instrument or analyser) * * the software may be intended to be installed on a device such as a computer, mobile phone, tablet or other electronic device and not intended to drive or influence an IVD instrument/analyser (or a non-IVD medical device) |
As an IVD |
Standalone software able to combine a number of IVD results to calculate and report an additional result to be used for clinical purposes. For example, software intended for the interpretation of a series of results obtained as part of a first trimester screening assessment in order to determine foetal risk of trisomy 21. Standalone software intended for use in staging or predicting severity of disease by means of an algorithm based on a combination of anthropometric measures and non-invasive biomarkers. |
IVD software that is not intended to drive or influence an IVD instrument (or medical device that is not an IVD) is classified according to its intended purpose. That is, it may be a Class 2, Class 3, or Class 4 IVD. |
| 4. Software that is intended for handling (e.g. receiving, storing, transferring) patient-related information, including results from IVD devices, which may be used in combination with an IVD instrument or other electronic devices | Does not meet the definition of a therapeutic good (^see comment) |
Patient record management system that handles admission dates, case notes, contact details. Conversion, compression, and encryption functionality/tool. Laboratory Information System (LIS) that is intended for the:
Software functionality intended to:
|
^ Software that handles clinical information and also has a diagnostic or therapeutic function(s), according to the manufacturer's intended purpose, is an IVD. The manufacturer/sponsor will need to consider the definition of a therapeutic good, medical device and IVD if the functionality of the software is not included in the examples provided in this table. Software that performs a manipulation on the data that affects the interpretation of results, or generates new diagnostic data/information, would make the software a medical device. If the source of the original data was an IVD then the software would be considered an IVD medical device. See guideline 3 above for clarification. |
| 5. Corrections to software errors | As a correction to the IVD (not a distinct or separate IVD) |
Bug fix to resolve rounding errors in the algorithm used to calculate result thresholds Stability fix to laboratory analysis tool to reduce incidence of crashing or freezing |
Corrections to software may be considered to be a product correction under the Uniform Recall Procedure for Therapeutic Goods which is available from TGA website. Note: If functionality that changes the original intended purpose of the software is added, then the software may be considered a distinct and separate IVD to that of the original. |