1. Introduction

Although the inclusion of software into medical devices is a long established practice, stand alone software offerings that provide diagnostic and therapeutic functions is relative new. Nonetheless, software applications are an increasingly fundamental feature of clinical practice and regulators around the world have responded to recognise this rise in interest within this area. Certain regulators, such as the one in Australia, have even made data available that can be used for further analysis. The use of medical devices in Australia is overseen by the Therapeutic Goods Authority (TGA). Consideration of software in medical devices has long been a concern for the TGA, which had evaluated means by which to address software through its essential principles as early as 2001 ^[1]. In 2020, the TGA released a study on the harms caused by software ^[2], outlining recalls and adverse events related to software through a literature review. The TGA report did not distinguish in its analysis between medical devices that have software and software as a stand alone medical device.

The distinction between devices that incorporate software and “software-as-a-medical-device” (SaMD) is important, as these now represent two distinct device types within regulation. SaMD are those entirely composed of software without any additional hardware. In other words, the software program itself is the medical device. Since 2013, there has been international consensus through the International Medical Device Regulators Forum (of which Australia is a member) on the definition of SaMD ^[3]. Although regulatory legislation now incorporates the definition, there remain unanswered questions about how the safety of such devices can be ensured. There has been work conducted related to recall and adverse events for medical devices that involve software using data from the FDA in the United States (e.g., ^[4][5]). However, we have been unable to find any quantitative analysis specific to SaMD in any jurisdiction after an extensive review of the available literature. Further to this, there has been no empirical treatment of reported risks associated with SaMD in Australia, or any other jurisdiction. To the best of our knowledge this work represents the first quantitative analysis of SaMD within any regulatory framework. In this work, we focus on the following three research questions; (1) Has SaMD registrations been growing in Australia and what is the origin (domestic or foreign)? (2) What types of recall events are associated with SaMD? (3) What are the types of adverse events associated with SaMD? We conclude with a discussion on results and the nature of regulatory actions for SaMD.

2. Development and Findings

The outcomes also highlight that there are some challenges in evaluating the risks associated with SaMD, as the limited regulatory vocabulary for software defects prevents further granular analysis. The blunt categorisation of the ISO code ”Computer Software Problem” in DAEN makes it hard to identify clear areas of improvement for the SaMD. It acts as an obstacle for the regulator, and those assessing regulatory data, as it prevents a better understanding of the types of events that occur for SaMD and reduces the potential for better risk management. Within the recall data, there are no fields specifying the type of problem that prompted the recall. This is not because a lack of vocabulary to describe software defects. This does exist, in, for example, the IEEE Standard for Classification of Software Anomalies ^[6]. The inclusion of more detailed software-specific recall reports and adverse events may facilitate the policy prioritisation for the regulator, which, in turn, will ensure that devices on the market reach an appropriate level of safety and performance.

The issue of applying appropriate standards for clinical safety are more acute for software than for non-software. McHugh et al. ^[7] already suggested that the rapid, iterative approach to software development may be in tension with the regulatory requirements for medical devices. Non-software device manufactures require specific fabrication infrastructure. This is in stark contrast to what happens in software testing. The costs associated with changing software are different compared to those associated with hardware manufacturing. For example, a software developer could quickly push an update to customers upon the discovery of a problem, whilst this is impossible for a (hardware) manufacture to do at scale. This rapid response option is not available to non-software devices, which must collect all defective items and fix the issue physically. Increasing the regulatory support offered to software developers during the early phases of research and development, as well as integrating this kind of support into, e.g., computer science courses, will potentially create more robust solutions for these regulatory issues in the future ^[8].

The difference in how risks need to be addressed by the manufacturers of products also relates to the origin of the product itself. The Australian market for medical devices relies heavily on foreign suppliers of medical devices. Herpin et al. ^[9] reports that the funding opportunities within the Australian biomedical industry may motivate innovators within the country to seek to establish manufacturing operations in larger markets for profit maximisation as the distance to these markets has an impact on costs. These economic dynamics seem to affect SaMD development less as there is no need for a factory to manufacture these devices, just access to skilled software developers. The lower initial cost for a more scalable product might account for the higher levels of Australian representation in SaMD.

We note that this study is limited by the amount of available data. The categorisation of ‘SaMD’ in this study was derived through the provided descriptions and the GMDN of the medical devices that were reported in the ARTG. There could be a potential for misclassification because of this. The results presented do not represent definitive evidence of trends, only an illustration of patterns available based on the data collected by the TGA. With the popularity of SaMD continuing to grow, along with the concerns that the TGA has with the regulation of these devices, it may be useful for records to indicate which devices are solely composed of software.

3. Conclusions

SaMD is a growing trend within medical device innovation. In this work, we provide the first empirical analysis of SaMD. Within Australia, which relies heavily on importation of medical devices, SaMD shows a greater domestic production than other types of medical devices.

The increased registrations of SaMD has coincided with an increased number of recall events. However, this might be explained by the fact that software can be more readily updated compared to hardware-based devices. Thus, recalls are easier to deal with for SaMD than for a traditional (non-software) medical device. Further research is required to determine the most efficient way that this difference can be reflected in the regulations. With regards to adverse events, it is hard to establish the type of adverse event, as the largest category of events is based on issues originating from the ‘Computer Software’ itself. This does not help to determine the precise type of event. To this end, adverse event reporting for SaMD might be improved with a greater software-specific granularity in order to better inform regulatory authorities, as well as clinical professionals and patients. More detailed data on this will provide an improved understand of the risks associated with SaMD. It will also allow the regulator to develop further insights into ways to better control these devices.