Coverage of the FDA Workshop on AI / ML Medical Devices – Part 1: The History of FDA Software Regulation
In anticipation of the FDA virtual public workshop on Transparency of Artificial Intelligence / Machine Learning (AI / ML) Compatible Medical Devices scheduled for October 14, 2021, we will publish a series detailing the history of software regulation by the FDA, and then report our impressions of the presentations and statements from various FDA attendees after the meeting. According to the FDA, the goal of the next workshop is to:
- Identify unique considerations for achieving transparency for users of AI / ML compatible medical devices and ways in which transparency could improve the safety and efficacy of these devices; and
- Gather feedback from various stakeholders on the types of information that would be useful for a manufacturer to include in the labeling and public information of AI / ML compatible medical devices, as well as others potential information sharing mechanisms.
Prior to the meeting, we will explore the FDA’s regulatory history for medical devices and software-enabled stand-alone software and the agency’s most recent advancements in digital health policy. In this part, we briefly summarize the FDA’s traditional approach to software regulation and how software development quickly exposed the limitations of the original regulatory framework established in the Medical Device Amendments from 1976 to the Federal Law on Food, Drugs and Cosmetics (FD&C Law).
The FDA’s Traditional Approach to Software Regulation
The development, use, and regulation of medical devices have a long history in the United States. Recognizing that a separate and distinct medical device regulatory framework from the pharmaceutical framework was needed, Congress adopted the 1976 Medical Device Amendments, which established the three risk-based device classifications (Class I, II and III), the process of creating performance standards for Class II devices and pre-market approval requirements for Class III devices.
In the 1970s, software began to be an integral part of some medical devices (previously devices were largely medical equipment). In particular, magnetic resonance imaging systems and pacemaker programming systems were developed in the 1970s, forcing the FDA to review software as well as hardware components as part of the pre-approval process. marketing. Additionally, the FDA 510 (k) database shows that pre-market notifications under Section 510 (k) of the FD&C Act were submitted for software devices in 1980.
Although the FDA made some attempts to develop comprehensive rules for medical device software, the agency ultimately never released a proposed framework to regulate software. In 1997, the FDA finalized the Quality System Regulation (QSR) for medical devices (21 CFR part 820), which meets specific quality expectations for the development of medical device software and the use of software in processes. automated systems to design, develop and manufacture Medical Equipment. In the regulatory commentary before the QSR was finalized, the FDA said quality system standards were needed in part because of device failures associated with software quality issues:
When it came to the software used to operate medical devices, the data was even more striking. A subsequent study of software-related recalls for the period of fiscal year (FY) 1983 to fiscal year 1991 indicated that more than 90 percent of all software-related device failures were due to software-related errors. design, in general, failure of validation of software prior to routine manufacture. (61 Federal Reg. 52 602 (Oct 7, 1996))
Since then, the FDA has issued numerous non-binding guidance documents on various software-related issues, including dozens of special control guidelines for certain Class II software devices. Indeed, the current Device Software and Mobile Medical Apps Policy The guide provides a history of the FDA’s attempts to develop a general software regulatory policy and explains that the agency abandoned these efforts because “the use of computer products and software as medical devices has increased exponentially. and the types of products have diversified and become more complex “. (See page 3.)
Problems with the FDA’s software approach
The lack of a separate regulatory framework, classifications, or pre-market review methods for software devices has led the FDA to largely treat software devices the same as traditional hardware devices. Software and hardware devices have drastically different design, development, and quality processes, and although some high-level general standards may apply to both, the fundamental differences between these types of devices make the regulation of software according to current rules like forcing a round peg into a square hole. Difficulties are alleviated when software is a component of a hardware device (for example, an MRI system or a surgical robot), but stand-alone software devices (also referred to as software as a medical device, or SaMD) have development and quality challenges which are not sufficiently addressed in the regulations in force.
Some of these challenges include:
- Post-market modifications – The FDA regulatory framework requires device manufacturers to obtain re-authorization or re-approval for significant changes to legally marketed Class II or III devices, which means that every change to an authorized or approved device must be evaluated to determine if a pre-market resubmission is required. This process makes sense for hardware devices, as changes 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, can be modified (eg, to add functionality or additional types of data input and output) relatively easily and individually, but significant modifications can be quickly developed and released. As technology advances, more and more functionality can be added to a software device simply by coding and validating new code, and each change potentially needs to be reviewed by the FDA before release, which is a heavy burden. for 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 (for example, a blood pressure cuff, sample collection vial, or stethoscope). Other hardware devices (especially those that have built-in software components) may have more than one intended use, but those uses fit well with an established device type or are new device functions that can be defined through approval. pre-market or de novo process. SaMD, however, can incorporate dozens of intended uses into a complete software suite and can combine device software functions and non-device software functions.
- Substantial equivalence – A Class II medical device must go through the pre-market notification (or 510 (k)) pre-market notification process, and this process requires the FDA’s determination that the new device is substantially equivalent to a legally marketed device . As noted above, many devices have only one intended use, and their respective technologies can be easily compared to other devices in the same category. However, when SaMD was introduced, the device industry and the FDA were forced to compare stand-alone software to devices legally marketed with hardware components. Additionally, SaMDs with many peripheral and non-peripheral features, some of which may be interdependent for input, compute, and output, or those that incorporate unique AI / ML algorithms, but still present only moderate risk. , are difficult to compare and find substantial equivalence with other legally marketed devices.
- Cyber ââsecurity – The advancement in software technology has led to amazing capabilities that can be applied to patient care, but it has also led to a terrifying increase in cyber vulnerabilities that can be exploited by hackers or can lead to unplanned outages machines. The FDA has spent a great deal of time and effort developing guidelines and policies related to device cybersecurity, and has issued several guidance documents on the subject. However, just as the rapid advancements in technology and software have hampered the FDA’s efforts to develop a comprehensive software policy, the same advancements, along with the parallel evolution of cyber vulnerabilities and hacking techniques, may exceed the limits. agency attempts to significantly mitigate associated risks.
- Quality controls, in general – As noted above, the current regulatory framework for devices, including QSR, is largely based on hardware devices and does not fully apply to the design, development and quality control of software. For example, 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; maintenance; and non-compliant product. The significant differences in process 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’s important to note that any action the FDA takes as a result of the upcoming AI / ML workshop is unlikely to 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.
In this article, we have briefly explored the history of the FDA in regulating software medical devices under rules designed primarily for hardware devices and the issues associated with such regulation. Next week, we’ll give a brief overview of the agency’s recent actions to create policies and processes that better adapt to advanced software technologies such as medical devices, as well as their developers.