Regulating Software as a Medical Device in the age of Artificial Intelligence

Feature ArticlesFeature Articles | 30 May 2019 | Citation

This article summarizes the current and proposed regulatory landscape for software as a medical device (SaMD) with artificial intelligence and machine learning capabilities. The author provides definitions for SaMD, categorization and testing features and how to approach and adjust regulatory pathways for SaMDs that “learn” by using real-world evidence to continuously adapt and improve and, therefore, may need to be re-submitted for a new premarket approval due to changes to the device via its adaptations. Because the regulatory system does not currently take into consideration SaMDs using Artificial Intelligence (AI) and Machine Learning (ML) to continually adapt, FDA has initiated a conversation with SaMD stakeholders to develop an appropriate regulatory pathway to accommodate AI/ML SaMD continuous adaptation.
Software is playing an increasingly important and integral role in healthcare and medical devices are embracing software and the evolving technologies of Artificial Intelligence (AI) and Machine Learning (ML). Accordingly, the International Medical Device Regulators Forum (IMDRF) has been generating guidance documents to help manufacturers understand how Software as a Medical Device (SaMD) is and will be regulated globally. Currently, there are four published guidance documents (three from IMDRF and one from the US Food and Drug Administration (FDA)) related to SaMD and which provide key definitions, risk categorization, quality management systems and clinical evaluation.1-4
Definitions for Identifying SaMD
SaMD has been defined by IMDRF as software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device. In other words, SaMD is software that may be used to diagnose, prevent, monitor or treat a disease. SaMD also may provide suggestions for disease mitigation or assist in the diagnosis, screening, monitoring, prediction and determination of a disease.5
The IMDRF acknowledges an SaMD may need to undergo maintenance throughout its lifecycle. Maintenance can be adaptive (e.g., adjust to the use environment), perfective (e.g., improve performance), corrective (e.g., correct errors) or preventative (e.g., adjust any errors before they become issues).6 In the US, how and when manufacturers present these changes to FDA to allow the agency to reassess the safety and effectiveness of the SaMD, is a “work in progress.” Further consideration and guidance with regard to this process is going to be necessary, especially for SaMDs that incorporate AI/ML and have the capacity to learn and improve postmarket through the incorporation of real-world data. While IMDRF has yet to take a firm stance on how to best regulate SaMD with AI/ML, some of the challenges facing regulators and manufacturers of SaMDs that includes AI/ML will be discussed later in this article.
Categorizing and Testing an SaMD
According to the guidance document, “Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations,” manufacturers first categorize their software as a medical device using a definition statement based on the intended use and the healthcare scenario in which the SaMD will be used. The intended use may be to treat or diagnose, to drive clinical management or to inform clinical management. To treat or diagnose a disease, the SaMD may use information from other medical devices, sensors or software devices. The information is then subsequently used to treat or diagnose the disease. “Driving clinical management” means to aid in the treatment or diagnosis or to triage or identify early signs of a disease or condition. The information gathered can be used as a guide for future medical intervention. “Informing clinical management” includes treating, diagnosing, preventing or mitigating a disease or to aggregate relevant information. The information collected does not result in an immediate or next step.
In addition to defining the intended use of the SaMD, a manufacturer will consider the healthcare scenario in which it will be used. There are three healthcare scenarios:
  1. a critical situation or condition
  2. a serious situation or condition
  3. a non-serious situation or condition
A critical situation describes a scenario where an accurate and/or timely diagnosis is essential to avoid serious health deterioration and/or death. Serious situations include instances when an accurate diagnosis or treatment prompts timely intervention or helps avoid unnecessary interventions. Non-serious situations occur when an accurate diagnosis and treatment are not critical, but remain important. All three situations consider the consequences of using a specific SaMD to ensure an individual patient’s health and/or the public’s health.
Once the intended use and the healthcare scenario are determined, the manufacturer can develop their definition statement. The statement will include the intended use, the healthcare scenario and a description of the SaMD core functionality (e.g., critical features or functions that are essential). Once determined, the manufacturer will categorize their SaMD (Figure 1). It is important to note that SaMD categories are relative to one another and independent upon the medical device classification.7 Non-SaMD medical device classification is based on an evaluation of risk to the user, patient or public and defines the regulatory controls needed to appropriately manage risk. SaMD categorization is based on the significance of the information provided to the healthcare decision or healthcare situation. Of the four SaMD categories, category I devices have the lowest significance while category IV devices have the highest significance.
Figure 1. How to Categorize SaMDs8


The definition statement and the classification for SaMDs will help identify risks and drive the clinical evaluation of the device. Every SaMD must undergo clinical evaluation or “a set of ongoing activities conducted in the assessment and analysis of a SaMDs clinical safety, effectiveness and performance as intended by the manufacturer in the SaMDs definition statement.”9 This evaluation involves three steps:
  1. valid clinical association
  2. analytical validation
  3. clinical validation (Figure 2)
For the valid clinical association, the manufacturer addresses to what extent the SaMD’s output is clinically accepted or based on establish scientific evidence, which determines whether this output is associated with the healthcare situation and is part of the definition statement. For analytical validation, the manufacturer demonstrates the SaMD can accurately, reliably and precisely generate the expected output from the expected input. Finally, during clinical validation, manufacturers evaluate the ability of the SaMD to yield clinically meaningful outputs for the intended use as well as for the healthcare situation. The degree of testing at each clinical evaluation step is up to the manufacturer and driven by the definition statement.10
Figure 2. The three steps that encompass clinical evaluation of a SaMD.11


How to Approach SaMD With AI/ML
Unlike other medical devices, a benefit of incorporating AI/ML in SaMDs is that they can “learn” from data collected and continuously improve the device’s overall effectiveness, throughout the device lifecycle. One current issue is that these adjustments and enhancements could result in changes that, according to current regulations, would frequently require manufacturers to generate a new premarket submission and re-engage with FDA to evaluate the safety and effectiveness of the revised device. FDA is currently addressing this issue and recently released a discussion paper entitled “Proposed Regulatory Framework for Modifications to Artificial Intelligence/Machine Learning (AI/ML)—Based Software as a Medical Device (SaMD).”12 The document, released on 2 April 2019, initiates a discussion with stakeholders involved in the development, regulation and use of SaMDs on how to adapt the current regulatory landscape. The discussion paper explores a novel regulatory pathway for modifications potentially requiring a new premarket submission and those modifications considered to remain within the original premarket submission.
Two types of AI/ML-based SaMDs may be reviewed by FDA: “locked” and “adaptive.”  A locked SaMD is defined as an “algorithm that provides the same result each time the same input is applied to it and does not change with use. Examples of locked algorithms are static look-up tables, decision trees and complex classifiers.”13 Any changes to this class of SaMD are likely to require a new submission. Adaptive technology is not as clearly defined. AI/ML-based SaMDs that can continue to learn and adjust once distributed are considered ‘adaptive. “14 These SaMDs continuously incorporate and adapt to real-world data; therefore, they have the potential to undergo continuous changes and initiate the need for numerous new submissions. Because producing new submissions could be burdensome and hinder the development of the AI/ML SaMD, FDA’s discussion paper presents a proposed framework regarding the adaptive nature of AI/ML-based SaMD.
AI/ML SaMD Improvements
If the AI/ML SaMD has a modification related to an algorithm design and requires re-training with a new data set, a new premarket submission may not be necessary. There are three types of modifications that fit this description:
  1. performance
  2. inputs
  3. intended use changes
The purpose of performance changes is often to improve the performance of the SaMD, such as increasing its sensitivity, while not altering the intended use of the device or the input type. Input changes can include increasing the compatibility of the SaMD and increasing the input data type, including analysis of oximetry data and heart rate data without changing the intended use. Changes in the intended use include changing the significance of the information, such as from driving clinical management to treating or diagnosing and/or changing in the healthcare situation or condition to from non-serious to serious, for example. Traditionally, when following the guidance document, “Deciding When to Submit a 510(k) for a Change to an Existing Device,” many of the above modifications would trigger the need for a new 510(k).15 FDA’s discussion paper highlights how performance and input changes can be anticipated in a premarket submission by defining SaMD Pre-Specifications (SPS), among which may describe anticipated modification(s) to performance, input or intended use and by outlining the associated Algorithm Change Protocol (ACP) to detail the specific methods to be used to achieve the anticipated modifications and manage any new risks (Figure 3).
Figure 3. Possible ACP Components in an SPS16

AI/ML SaMDs inherently change and adapt as more real-world data is incorporated. If the modifications are outside an FDA-reviewed SPS and ACP, the Total Product Lifecycle (TPLC) helps dictate the regulatory pathway. As the AI/ML SaMD is being developed, it will be clinically validated using a predetermined data set to help “tune” the SaMD to ensure its accuracy and reproducibility. FDA will then review the SaMD through a premarket submission (e.g., 510(k), de novo, or a premarket approval) and, once cleared, granted or approved, the AI/ML SaMD will be deployed and begin to accumulate real-world data. Within the TPLC approach, the manufacturer continues to monitor the SaMD by tracking use and evaluating performance. As the SaMD incorporates additional data (real-world data), it may need to be retrained, retuned and possibly re-evaluated (Figure 4). Under such circumstances, the manufacturer may need to submit a new premarket submission.
Figure 4. Approach to Modifications for a Previous Approved or Cleared SaMD With SPS and ACP17

If the modification is not part of the SPS, the manufacturer has three options. First, the manufacturer can contact the appropriate review division to gain confirmation that the modification fits the original SPS. Second, they can submit a pre-submission for review or third, submit an entirely new premarket notification.
Developing an Adaptive Regulatory Pathway
The regulatory path for SaMDs is constantly evolving in the world of medical devices. IMDRF has released multiple guidance documents to help manufacturers navigate the regulatory recommendations or requirements for a SaMD and include the need for a definition statement and for clinical evaluation of the device prior to FDA review. The regulatory system does not currently take into consideration that SaMDs utilizing AI/ML can use real-world evidence to continuously adapt and improve. However, FDA has initiated a conversation with SaMD stakeholders to develop an appropriate regulatory pathway to allow AI/ML SaMD to adapt continuously. The recently published FDA discussion paper provides SaMD manufacturers a unique opportunity to be included in shaping the regulatory landscape that will be used in the future.
FDA has included questions throughout the discussion paper for those SaMD manufacturers who are interested in being part of the conversation.
  1. Software as a Medical Device (SaMD): Key Definitions. International Medical Device Regulators Forum. 9 December 2013.
  2. Software as a Medical Device:" Possible Framework for Risk Categorization and Corresponding Considerations. International Medical Device Regulators Forum. 18 September 2014.
  3. Software as a Medical Device (SaMD): Application of Quality Management System. International Medical Device Regulatory Form. 2 October 2015.
  4. Guidance for Industry and Food and Drug Administration Staff Software as a Medical Device (SAMD) Clinical Evaluation. US Food and Drug Administration. 8 December 2017.
  5. Op cit 1.
  6. Op cit 1.
  7. Op cit 2.
  8. Proposed Regulatory Framework for Modifications to Artificial Intelligence/Machine Learning (AI/ML)- Based Software as a Medical Device (SaMD). US Food and Drug Administration. 2 April 2019
  9. Op cit 3.
  10. Op cit 3.
  11. Guidance for Industry and Food and Drug Administration Staff Deciding When to Submit a 510(k) for a Change to an Existing Device. US Food and Drug Administration. 25 October 2017
  12. Op cit 8.
  13. Op cit 8.
  14. Op cit 8.
  15. Op cit 8.
  16. Op cit 8.
  17. Op cit 8.
About the Author
Michelle Rubin-Onur, PhD, received her PhD in Integrative molecular and biomedical sciences from Baylor College of Medicine. In addition to her microbiology research, as a graduate student, Rubin-Onur studied science policy and ethics and interned with the Baker Institute for Public Policy at Rice University. As an intern, she examined “Right to Try” laws, which fueled a growing interest in regulatory affairs. Rubin-Onur went on to publish a policy report for the Baker Institute that was featured in the Texas Tribune. During her PhD work, she also was president of the student council and helped edit institutional policies, further developing her critical thinking, leadership and writing skills. Currently, Rubin-Onur is a regulatory specialist at AcKnowledge Regulatory Strategies. She can be contacted at
Cite as: Rubin-Onur M. “Regulating Software as a Medical Device in the age of Artificial Intelligence.” Regulatory Focus. May 2019. Regulatory Affairs Professionals Society.


© 2022 Regulatory Affairs Professionals Society.

Discover more of what matters to you

No taxonomy