DECEMBER 20219MANUFACTURING TECHNOLOGY INSIGHTSof the SaMD, which may impact the clinical management of a patient."This IMDRF document establishes a framework, discusses how to evaluate and validate SaMD, and lays out a "Pathway for Continuous Learning Leveraging Real World Performance Data."In line with the framework outlined in this IMDRF document, FDA announced a pilot for the Digital Health Software Pre-Certification Program in 2017 and selected 9 pilot program participants. This pilot has been focused on and limited to SaMD. FDA has stated their vision for the program to "help inform the development of a future regulatory model that will provide more streamlined and efficient regulatory oversight of software-based medical devices developed by manufacturers who have demonstrated a robust culture of quality and organizational excellence, and who are committed to monitoring real-world performance of their products once they reach the U.S. market." FDA's Guidance Document on Policy for Device Software Functions and Mobile Medical Applications provides a nice high-level overview of software regulatory history and highlights the functions that are the focus of FDA regulatory oversight, and also provides helpful examples. The three key areas to be aware of are: 1. Software functions that are an extension of one or more medical devices by connecting to such device(s) for purposes of controlling the device(s) or analyzing medical device data.2. Software functions (typically, mobile apps) that transform the mobile platform into a regulated medical device by using attachments, display screens, or sensors or by including functionalities similar to those of currently regulated medical devices. 3. Software functions that become a regulated medical device by performing patient-specific analysis and providing patient-specific diagnosis, or treatment recommendations. These types of functions are similar to or perform the same function as those types of software devices that have been previously cleared or approved.FDA's Guidance Document on Clinical Decision Support Software describes the regulatory history of SaMD, and consistent with the IMDRF Framework, FDA intends to apply a risk-based policy for Clinical Decision Support (CDS) software functions. With that said, "FDA encourages developers of CDS software functions that are not medical devices or are medical devices for which at this time FDA [is exercising enforcement discretion] to implement a quality system consistent with IMDRF's Software as a Medical Device (SaMD): Application of Quality Management System and to apply good cyber hygiene, such as through software design and cyber vigilance, consistent with applicable FDA guidance." Finally, FDA has specifically included SaMD in the scope of their guidance document on Deciding When to Submit a 510(k) for a Software Change to an Existing Device, and the flowchart on page 10 of this guidance is particularly useful (be sure to consider it in conjunction with the accompanying text).Helpful examples are also provided by FDA, specifically for cybersecurity considerations and an example of a software algorithm modification. It is typical for software in the health space to initially focus on general wellness or other low-risk software functions and then develop into software as a medical device with the addition of new software functions. Starting with the end in mind, and knowing how each additional software function affects regulatory considerations, enables design of an effective regulatory strategy to match or improve on software development plans, or even navigate the largely uncharted waters of artificial intelligence and machine learning-based software as a medical device.David Pudwill is a former FDA Reviewer in the Center for Devices and Radiological HealthDISCLAIMER: The views and opinions expressed in this article are mine alone, and do not necessarily reflect the official policy or position of any company, FDA, or any other entity.
< Page 8 | Page 10 >