Roberta Druyor-Sanchez, MS, Partner, NDA Partners LLC
Software is playing an increasingly important and critical role in healthcare, such as mobile medical apps aligned with traditional medical devices, In vitro diagnostic (IVD) algorithms for software imaging, and genomics analys is paired with companion diagnostics to point providers to optimal drug treatments. Traditionally, FDA only focused on medical device hardware with corresponding embedded software. With this emerging mobile and IT world, the medical device space now includes Software as a Medical Device (SaMD), which is “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device." [The International Medical Device Regulators Forum] SaMD frequently depends on commercial off-the-shelf (COTS) software and other systems and data repositories for source data. SaMD may perform on a multitude of technology platforms (e.g., personal computers, smart phones, and in the cloud), and is often increasingly interconnected to other systems and datasets (e.g., via networks and over the Internet). Accordingly, SaMD requires compliances with FDA software guidances, IEC 62304: Medical device software, Software life cycle processes, and Cybersecurity along with various user experience guidances.
What are the key elements of the Software Development Life Cycle (SDLC)?
For those SaMD products that require Software Development Life Cycle (SDLC) implementation per IEC 62304 based on Classification, the following software documentation will need to be implemented as part of any FDA regulatory submission as part of FDA’s Design Control (§820.30) regulations:
• Software and/or Design Control Plan
• Software Architectural Design within Software Description including Environmental Description
• Verification and Validation of Software Unit, Integration, and System Testing
• Software Revision History and Unresolved Bugs
• Risk Management per ISO 14971 for the SaMD.
How does the 21st Century Cures Act affect software implementation?
The 21st Century Cures Act (Cures Act) amended the Federal Food, Drug, and Cosmetic Act (FD&C Act) on December 13, 2016, removing certain software from the definition of a medical device. Unlike other FDA guidances or standards, the Cures Act does not easily describe the regulatory pathway for each type of SaMD since it combines many different types of devices and modifications to regulations.
A lack of adequate design controls and documentation for software implemented as part of FDA regulatory submissions can result in FDA A1 hold letters, which delay product clearances/approvals and cost companies time and money. When software implementation is organized from the beginning using a basic development cycle methodology, companies can more easily utilize the FDA’s Pre-Submission process to streamline regulatory submissions and reduce multiple Agency response requests. Most importantly, this gets companies to market quicker. Unfortunately, many companies use research-minded software developers with no experience in medical devices to code their software and it is only after their agile software development has been completed that they realize inadequate software documentation has to be addressed prior to an FDA submission. Establishing a Quality Management System and aligning development with the software guidances and IEC 62304 from the start sets companies apart from their competitors. Failing to implement a strong FDA-compliant software system is fairly common, especially when a product is developed by those inexperienced in the regulatory process.
The Case Study
One of NDA Partners’ clients is a small start-up company that has developed an image analysis algorithm. After the 21st Century Cures Act in 2016, a similar product received De Novo Request Clearance as a Class II device. Being similar but not exact, the company asked NDA Partners to support the execution of a 510(k) Pre-Submission to the FDA and to determine if the original SaMD could be considered a predicate device. FDA provided feedback that it could be considered a predicate device as long as the company showed substantial equivalence and provided all the supporting software documentation as part of their 510(k) submission.
The company’s 510(k) required a particular focus on demonstrating the strength of the company’s software and regulatory documentation. NDA Partners structured the submission such that it aligned with the FDA’s software and image analysis guidelines, none of which could have been done easily without the collaboration of FDA through the Pre-Submission process. The company has since gone on to receive 510(k) clearance.
Many of NDA Partners’ software-based clients want to know how FDA is treating SaMD, especially because the 21st Century Cures Act does not provide clear guidance. NDA Partners has the expertise in software development life cycles and has worked across the various software fields to help clients understand the Cures Act’s nuances and how their SaMD may be regulated. NDA Partners experts have collectively worked with dozens of companies implementing, auditing, and improving software documentation according to the software development life cycle by evaluating their needs and then offering tailored software tools based on their software program, which usually follows agile development using software infrastructure such as LIMS systems, JAVA, Patheon, and git. They have worked with many medical software/healthcare technology companies to lead their Pre-Submissions or submissions to FDA as warranted and keep clients safe from warning letters.