In anticipation of FDA’s virtual public workshop on transparency of artificial intelligence/machine learning (AI/ML)-enabled medical devices scheduled for October 14, 2021, we will be posting a series detailing the history behind FDA’s regulation of software and then reporting our impressions of FDA’s presentations and statements from various attending stakeholders following the meeting. According to FDA, the purpose of the upcoming workshop is to:

• Identify unique considerations in achieving transparency for users of AI/ML-enabled medical devices and ways in which transparency might enhance the safety and effectiveness of these devices; and

• Gather input from various stakeholders on the types of information that would be helpful for a manufacturer to include in the labeling of and public facing information of AI/ML-enabled medical devices, as well as other potential mechanisms for information sharing.

Prior to the meeting, we will explore the history of FDA’s regulation of software-enabled medical devices and stand-alone software and the agency’s more recent progress with digital health policies. In this part, we briefly summarize FDA’s traditional approach to regulating software and how software development quickly revealed the limitations of the original regulatory framework established in the 1976 Medical Device Amendments to the Federal Food, Drug, and Cosmetic Act (FD&C Act).

The FDA’s Traditional Approach to Software Regulation

The development, use, and regulation of medical devices has a long history in the United States. Recognizing that a framework for regulating medical devices separate and distinct from the drug product framework was necessary, Congress passed the Medical Device Amendments of 1976, which established the three risk-based device classifications (classes I, II, and III), the process for creating performance standards for class II devices, and the requirements for premarket approval for class III devices.

In the 1970s, software started to become an integral part of certain medical devices (before, devices were largely medical hardware). In particular, magnetic resonance imaging systems and systems to program cardiac pacemakers were developed in the 1970s, requiring FDA to review the software as well as the hardware components as part of the premarket approval process. In addition, FDA’s 510(k) database shows that premarket notifications under Section 510(k) of the FD&C Act were being submitted for software devices in the year 1980.

Although FDA made a few attempts to develop comprehensive rules for medical device software, the agency ultimately never released a proposed framework to regulate software. In 1997, FDA finalized the Quality System Regulation (QSR) for medical devices (21 C.F.R. part 820), which addresses specific quality expectations relating to the development of medical device software and the use of software in automated processes to design, develop, and manufacture medical devices. In the regulatory commentary before the QSR was finalized, FDA stated the quality system standards were necessary in part because of device failures associated with software quality issues:

With respect to software used to operate medical devices, the data were even more striking. A subsequent study of software-related recalls for the period of fiscal year (FY) 1983 through FY 1991 indicated that over 90 percent of all software-related device failures were due to design-related errors, generally, the failure to validate software prior to routine production. (61 Fed. Reg. 52,602 (Oct. 7, 1996))

Since then, FDA has issued numerous nonbinding guidance documents on various software-related issues, including dozens of special controls guidances for certain class II software devices. In fact, the current Policy for Device Software Functions and Mobile Medical Applications guidance provides a history of FDA’s attempts to develop a general policy for regulating software and explains that the agency abandoned such efforts because “the use of computer and software products as medical devices grew exponentially and the types of products diversified and grew more complex.” (See pg. 3.)

The Problems with FDA’s Approach to Software

Lack of a separate regulatory framework, classifications, or premarket review methods for software devices has resulted in FDA largely treating software devices in the same manner as traditional hardware devices. Software and hardware devices have radically different design, development, and quality processes, and while some general, high-level standards can apply to both, the fundamental differences between these device types makes the regulation of software under the current rules like forcing a round peg into a square hole. The difficulties are attenuated when the software is a component of a hardware device (e.g., an MRI system or surgical robot), but standalone software devices (also called software as a medical device, or SaMD) present development and quality challenges that are not adequately addressed in the current regulations.

Some of these challenges include:

• Post-market modifications – FDA’s regulatory framework requires device manufacturers to obtain a new clearance or approval for significant modifications to legally marketed class II or III devices, which means that each change to a cleared or approved device must be evaluated to determine whether a new premarket submission is necessary. This process makes sense for hardware devices because modifications typically require substantial engineering effort to design, develop, and test, and manufacturers will often release new versions of a hardware device with multiple improvements. Software devices, on the other hand, may be modified (e.g., to add functionality or additional types of data inputs and outputs) relatively easily and individual but significant modifications may be quickly developed and released. As technology advances, more and more capabilities may be added to a software device simply by coding and validating the new code, and each change must potentially be reviewed by FDA prior to release, which is a heavy burden on software device developers and agency resources.

• Multiple functionalities – Many hardware devices have a single intended use that can be defined in a few sentences or less (e.g., a blood pressure cuff, a specimen collection vial, or a stethoscope). Other hardware devices (especially those devices that incorporate software components) may have more than one intended use, but such uses fit squarely within an established device type or are novel device functions that can be defined through the premarket approval or de novo process. SaMD, however, may incorporate dozens of intended uses into a comprehensive software suite, and may combine device software functions and non-device software functions.

• Substantial equivalence – A class II medical device must go through the premarket notification (or 510(k)) process prior to commercialization, and that process requires FDA’s determination that the new device is substantially equivalent to a legally marketed device. As stated above, many devices have a single intended use, and their respective technologies may be readily compared with other devices in the same category. However, when SaMD was introduced, the device industry and FDA were forced to compare standalone software to legally marketed devices with hardware components. In addition, SaMD with numerous device and non-device functionalities, some of which may be interdependent for input, calculation, and output, or those that incorporate unique AI/ML algorithms, but nonetheless present only moderate risk, are difficult to compare with and find substantial equivalence to other legally marketed devices.

• Cybersecurity – Advancing software technology has led to amazing capabilities that can be applied to patient care, but it has also led to a terrifying rise in cyber vulnerabilities that can be exploited by hackers or may lead to unanticipated device failures. FDA has spent a significant amount of time and effort developing guidelines and policies relating to device cybersecurity and has released multiple guidance documents on the subject. However, just as the rapid progress of technology and software stymied FDA’s efforts at developing an overarching software policy, the same progress, as well as the parallel evolution of cyber vulnerabilities and hacking techniques, may outpace the agency’s attempts to significantly mitigate the related risks.

• Quality controls, generally – As expressed above, the current device regulatory framework, including the QSR, is largely based on hardware devices and does not fully apply to software design, development, and quality control. For instance, some of the QSR provisions certainly apply to SaMD, such as corrective and preventive actions, complaint handling, and document controls, but many others are inapplicable, for example, production and process controls; labeling and packaging controls; handling, storage, distribution, and installation; servicing; and nonconforming product. The significant differences in processes and environment between SaMD developers and traditional hardware device manufacturers affect post-market compliance activities and regulatory inspections for SaMD products and their developers.

It is important to note that any action FDA takes following the upcoming AI/ML workshop likely will not fundamentally change the current regulatory framework for devices. However, the agency will almost certainly create various policies and tools that will streamline the submission and review process for certain AI/ML-based software devices.

Conclusion

In this post, we briefly explored FDA’s history of regulating software medical devices under rules designed primarily for hardware devices and the issues relating to such regulation. Next week, we will give a quick tour of the agency’s recent actions to create policies and processes that better accommodate advanced software technologies as medical devices, as well as their developers.