Software developed within radiation oncology departments can be used to facilitate improved patient care and improve the efficiency of various clinical processes. However the risks associated with the use of such software needs to be considered, as do legal or regulatory requirements associated with its development, supply and use. For this reason, the development and supply of software that can be considered as a medical device, software as a medical device (SaMD), is regulated by the Australian Therapeutic Goods Association (TGA). Regulated SaMD developed in-house can only be used clinically (i.e. supplied) if approved by the TGA, or used within the context of a clinical trial.

This post summarises my interpretation of the current regulatory requirements for in Australia (circa June 2022), following review of TGA documentation, and discussions with ANDHealth and members of the ACPSEM Software Development Task Group. The reader is responsible for ensuring whether the software they want to develop is regulated within their own jurisdiction. I’d encourage Australian readers to review the following documents: “Is my software regulated?“,  “Examples of regulated and unregulated (excluded) software based medical devices” and “How the TGA regulates software-based medical devices“.

If you want to develop software in the clinic, you will need to consider these questions:

1. Will the software be a component of another device or piece of software?
2. If not, could the software be considered to be a medical device?
3. If so, is the software exempted from any regulatory requirements?
4. If the software is regulated, what is its risk classification?

Will the software be a component of another device or piece of software?

Software can be loosely defined as a collection of instructions provided to a computational system to provide some functionality. Software can be classified as being a standalone system, as influencing or working in combination with other devices, or as a component of another device. If software is being developed as a component of a regulatory-compliant medical device, it

Software developed as a component of a parent medical device, for example, software libraries or packages, embedded software, an operating system that controls a medical device, or software supporting a medical device production system, can be referred to as software in a medical device and is regulated by the TGA as part of that parent medical device. Examples of software implemented within non-software medical devices in radiation oncology include linear accelerator console software, and image reconstruction algorithms included with CT simulators and image-guided radiotherapy systems.

Software implemented within a SaMD, for example, macro instructions, reporting templates, and user-developed scripts, may or may not need to be considered standalone to the parent software, depending on its risk profile and its intended functionality. Any developed macro instructions or user scripts, if used to automate tasks within an approved SaMD that would otherwise be performed by a health professional, must be considered as its own device if it increases the risk associated with the use of the parent SaMD or extends the functionality beyond the SaMD manufacturer’s intended purpose (i.e., what is described in instruction manuals or marketing). Examples of software implemented within SaMD in radiation oncology include database queries to generate radiation workload reports within an oncology information system, use of a graphical scripting functions in a treatment planning system to automate planning workflows, and the development of scripts using a TPS application programming interface functions that automates the expansion of volume margins, the set-up of default beam arrangements for a 3D conformal treatment, the export treatment data for quality control tests, or provides a summary of plan compliance with an established clinical protocol.

Could the software be considered to be a medical device?

There are two determinations that must be made to establish whether software is a medical device: if the purpose of the software is medical (per the Therapeutic Goods Act), and the software does not meet any exclusion criteria (per any excluded goods order), it is a medical device, and is regulated by the TGA. If it does not have a medical purpose, or it does meet exclusion criteria, it is not considered a medical device, and is not regulated by the TGA.

Software may be considered as having a medical purpose if any of the following statements is true:

• It is intended to be used in the diagnosis, monitoring, prediction, prognosis, treatment or alleviation of disease, injury, or disability; prevention of disease; compensation for an injury or disability; or control of support of conception.
• It is used for the investigation, replacement, or modification of the anatomy or of a physiological or pathological process or state.
• It is an accessory to, intended to be used in combination with another medical device, or it influences the behavior of another medical device.

In other words, if it interacts with patient data, has the potential to inform or change diagnosis or treatment of a particular patient, or interacts another medical device, it can be considered as having a purpose that is likely to be medical, and may be a medical device. Software that models, for example, a staff schedule, is not a medical purpose.

Software described by an exclusion (e.g., as described in an excluded goods order) is not considered a medical device. Currently, exclusions include

• Software allowing self-management of non-serious disease, health and wellness, or cognitive behaviours.
• Software facilitating patient recorded outcome measures or patient surveys.
• Software facilitating telehealth, or storage and transmission of patient information or images.
• Software that uses published clinical standards or authoritative sources (e.g., paper-based data, clinical protocols) to make or display calculations that are subsequently validated by the user.
• Software that facilitates population-based data analytics, that is not intended to be used to inform clinical care of individuals.

An example of software in radiation oncology that meets exclusion criteria would be software that interrogates historical planning data to characterise contouring uniformity, average dosimetric quality, or quality assurance result distribution for ongoing performance monitoring.

Is the software exempted from any regulatory requirements?

Any software that is considered as its own SaMD will be subject to TGA regulations, but may be exempt from some regulatory requirements, depending on its intended application. Clinical decision support software (CDSS) provides guidance to health professions in making decisions. SaMD that meets the definition of CDSS is exempted from the requirement for inclusion of the SaMD on the Australian Register of Therapeutic Goods (ARTG). Suppliers must still notify the TGA of supply of the device, the essential principles for safety and performance of devices must be met, adverse events must be reported, and the TGA can take regulatory action. SaMD can only be considered clinical decision support software if it:

• does not directly process or analyse a medical image or a signal from another medical device,
• is solely used to provide or support a recommendation to a health professional about prevention, diagnosis, curing or alleviating a disease, ailment, defect, or injury,
• does not replace the clinical judgement of a health professional in relation to making a clinical diagnosis or decision about the treatment of patients.

CDSS that do not qualify as medical devices (e.g., digitised versions of published decision trees) are not regulated by the TGA. An example of software in radiation oncology that would quality as CDSS is software that interrogates historical planning data to predict achievable dosimetric quality or quality assurance results for a new treatment plan based on a published process that could be validated by the health professional.

All software considered a medical device, that is not regulated as part of another device, and that is not exempted from any regulatory requirements, must be included on the ARTG prior to any supply or use.

What is the risk classification of the software?

The risk classification of this software will depend on the intended use and associated level of potential harm. Developers of Class I medical devices can be self-certified (i.e., they can assess their own devices conformance with the essential principles). Developers of Class IIa, Class IIb or Class III medical devices must obtain conformity assessment certification from an independent body. A quality management system (e.g. developed with reference to ISO 9001, ISO 13485, and IEC 62304) is used to ensure conformity of developed software with essential principles and regulatory requirements. This system will outline the approach to software development, documentation requirements, and the methods of verification and validation used to ensure software is operating correctly.

If a medical device is controlled, or influenced, by an item of software, the software has the same classification as the medical device. If a medical device is designed to be used in combination with another device, each device is classified separately. The TGA provide classification rules to assist in classifying devices, depending on:

• Risk to individuals (death, serious disease or condition, harm, etc.) or public health.
• The use of the software (diagnosing or screening for a disease of condition, monitoring state or progression of a disease, specifying or recommending treatment or intervention, provision of information).

For all cases where there is risk of harm or moderate public health risk, the risk classification is Class IIa or higher.