In-vitro diagnostic medical device software

When software meets the definition of an IVD medical device, it will be regulated as by us. IVD medical devices must:

• comply with all relevant Essential Principles to ensure safety, quality and performance, and
• be included in the Australian Register of Therapeutic Goods (ARTG) unless exempt or excluded.

The importance of intended purpose

The way software is regulated depends on its intended purpose and how it is supplied.

The intended purpose is determined by the manufacturer and can be identified through information provided with, or about, the device including:

• product labelling
• instructions for use (user manual)
• advertising or promotional materials
• technical documentation describing how the software interacts with other IVDs.

Understanding and clearly defining the intended purpose is critical for determining the correct classification and regulatory requirements for IVD software.

Software standards for IVD software

There are several international standards that can be used for IVD software to demonstrate compliance with the Essential Principles on the safety and performance of medical devices.

Below is a summary of how different types of IVD software are treated under the Therapeutic Goods (Medical Devices) Regulations 2002 (the Regulations).

1. Embedded in an IVD instrument

Software that is pre-installed or embedded in an IVD instrument as an integral component is considered part of the device. It does not require a separate entry in the ARTG. 

• The device comprising both software and hardware components will be classified according to the classification rule in Schedule 2A of the Regulations.
• Includes embedded software such as firmware, field-programmable gate arrays (FPGA), electronic programmable read only memory (EPROM), flash memory, and static or dynamic random access memory (RAM).

Examples of software embedded in an IVD instrument

• Operating software in a clinical analyser.
• Software in point-of-care analysers or self-test IVDs like glucose meters.

2. Supplied separately but intended to operate or influence an IVD

Software that is not embedded but is intended to drive or influence an IVD instrument will be regulated as a separate medical device and should be included in the ARTG. These kinds of devices:

• will be classified the same as the IVD it influences
• require a separate ARTG entry due to having a different GMDN code.

Examples of software supplied separately but intended to operate or influence an IVD

• Software installed on a computer interface to control an IVD instrument.
• Software upgrades that enhance the functionality or intended purpose of an IVD instrument.

Standalone software for diagnostic or therapeutic purposes

Software that provides diagnostic or therapeutic information, without driving or influencing a particular IVD instrument, is regulated as a standalone IVD.

• Classification depends on the intended purpose and may range from Class 1 to Class 4 IVD.
• Must be assessed independently of any instrument.

Examples of standalone software used for diagnostic or therapeutic purposes

• Software that combines IVD results to assess foetal risk of trisomy 21.
• Software that stages or predicts disease severity using algorithms.

4. For handling patient-related information

Software that only manages or transfers patient data, without performing diagnostic or therapeutic functions, will generally not meet the definition of a medical device. If the software manipulates data to generate new diagnostic information, it may meet the definition of a medical device and be regulated as an IVD medical device. Manufacturers and sponsors are responsible for determining whether the software meets the definition of a medical device (including IVD medical devices).

Examples of software used for handling patient-related information

• Patient record management systems.
• Laboratory Information Systems (LIS) that store and report data without manipulating it.
• Software that:
  • Blocks test results that are invalid due to QC failure
  • Flags duplicate test results that are discrepant
  • Generates worklists of patient samples for batch testing.

5. Corrections and bug fixes

Corrections to existing software are treated as updates to the original IVD and are not considered to be a new, separate device. Before correcting or updating software, manufacturers should:

• Check whether the change they’re making is due to circumstances that would make the device subject to our Procedure for recalls, product alerts and product corrections (PRAC).
• Determine whether the update will change the intended purpose of the software, which could mean it will be regulated as a new IVD.

Examples of software corrections and bug fixes

• Fixes for rounding errors in result calculations.
• Stability improvements to reduce software crashes.