Submitted Successfully!
To reward your contribution, here is a gift for you: A free trial for our video production service.
Thank you for your contribution! You can also upload a video entry or images related to this topic.
Version Summary Created by Modification Content Size Created at Operation
1 + 1250 word(s) 1250 2021-08-30 08:57:50 |
2 format correct Meta information modification 1250 2021-08-31 03:33:54 |

Video Upload Options

Do you have a full video?


Are you sure to Delete?
If you have any further questions, please contact Encyclopedia Editorial Office.
Ceross, A. Evaluating the Presence of Software-as-a-Medical-Device. Encyclopedia. Available online: (accessed on 12 April 2024).
Ceross A. Evaluating the Presence of Software-as-a-Medical-Device. Encyclopedia. Available at: Accessed April 12, 2024.
Ceross, Aaron. "Evaluating the Presence of Software-as-a-Medical-Device" Encyclopedia, (accessed April 12, 2024).
Ceross, A. (2021, August 30). Evaluating the Presence of Software-as-a-Medical-Device. In Encyclopedia.
Ceross, Aaron. "Evaluating the Presence of Software-as-a-Medical-Device." Encyclopedia. Web. 30 August, 2021.
Evaluating the Presence of Software-as-a-Medical-Device

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.

medical technology digital healthcare data science regulations machine learning software

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.


  1. Jamieson, J. Regulation of medical devices involving software in Australia: An overview. In Proceedings of the Sixth Australian Workshop on Safety Critical Systems and Software, Brisbane, Australia, 1 July 2001; Australian Computer Society, Inc.: Darlinghurst, Australia, 2001; Volume 3, pp. 7–12.
  2. Therapeutic Goods Administration. Actual and Potential Harm Caused by Medical Software. July 2020. Available online: (accessed on 6 February 2021).
  3. IMDRF SaMDWorking Group. Software as a Medical Device (SaMD): Key Definitions; Tech. Rep.; International Medical Device Regulators Forum; December 2013; Available online: (accessed on 6 February 2021).
  4. Fu, Z.; Guo, C.; Zhang, Z.; Ren, S.; Jiang, Y.; Sha, L. Study of software-related causes in the fda medical device recalls. In Proceedings of the 2017 22nd IEEE International Conference on Engineering of Complex Computer Systems (ICECCS), Fukuoka, Japan, 6–8 November 2017; pp. 60–69.
  5. Ronquillo, J.G.; Zuckerman, D.M. Software-related recalls of health information technology and other medical devices: Implications for fda regulation of digital health. Milbank Q. 2017, 95, 535–553.
  6. IEEE Standards Association. IEEE 1044-2009—IEEE Standard Classification for Software Anomalies. Available online: (accessed on 2 April 2021).
  7. McHugh, M.; McCaffery, F.; Casey, V. Barriers to adopting agile practices when developing medical device software. In Software Process Improvement and Capability Determination; Mas, A., Mesquida, A., Rout, T., O’Connor, R.V., Dorling, A., Eds.; Springer: Berlin/Heidelberg, Germany, 2012; pp. 141–147.
  8. Hendricusdottir, R.; Hussain, A.; Milnthorpe, W.; Bergmann, J.H.M. Lack of Support in Medical Device Regulation within Academia. Prosthesis 2021, 3, 1–8.
  9. Herpin, T.F.; Karuso, H.; Foley, J.E. Australian biotech companies: Navigating the maze. J. Commer. Biotechnol. 2005, 11, 111–120.
Subjects: Others
Contributor MDPI registered users' name will be linked to their SciProfiles pages. To register with us, please refer to :
View Times: 407
Revisions: 2 times (View History)
Update Date: 31 Aug 2021