The FDA publishes clear regulations and guidance to manufacturers for developing and marketing their regulated medical device. But if you don’t know what is out there or where to look, it can be extremely overwhelming. I wrote this article to give you an easy step-by-step walkthrough of the FDA process. By following this guide, you’ll understand all the laws regulating your product and be more prepared for the FDA 510(k) submission.
List of FDA Regulations
Here is a list of the main FDA regulations, which I’ll explain in detail with this article.
- Design Controls (CFR Title 21 Part 820.30 Subpart C)
- Electronic Records; Electronic Signatures (CFR Title 21 Part 11)
- General Principles of Software Validation
- Q9 Quality Risk Management
- Factors to Consider Regarding Benefit-Risk in Medical Device Product Availability, Compliance, and Enforcement Decisions
- Off-the-Shelf Software Use in Medical Devices
- Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software
- Content of Premarket Submissions for Management of Cybersecurity in Medical Devices
- Applying Human Factors and Usability Engineering to Medical Devices
- Policy for Device Software Functions and Mobile Medical Applications
- Radio Frequency Wireless Technology in Medical Devices
Design Controls
Unlike non-regulated software engineering, your software medical device is regulated. Meaning, each phase of your Software Development Life Cycle (SDLC) is governed by CFR Title 21 Part 820.30 Subpart C – Design Controls. Use this regulation to create your Standard Operating Procedures (SOP), train your software team, and ensure that they are following these procedures perfectly. If this is done correctly, you will have a list of software deliverables that will be later used for your FDA 510(k) submission.
Electronic Records; Electronic Signatures
On the heels of Design Controls, the FDA will also look for evidence that every document, record, or output of your software can be traced back to the person who authored, edited, reviewed, and approved those deliverables. CFR Title 21 Part 11 – Electronic Records; Electronic Signatures ensures that every regulated software manufacturer is in control over content being inserted into (or removed from) the software medical device.
Software Validation
A software as a medical device is regulated because it can have an impact on user, operator, or patient health and safety. General Principles of Software Validation ensures that thorough testing is performed on the software to ensure all requirements and risk mitigations have been thoroughly tested to provide confidence that the medical device is performing as designed.
Risk Management
Because your software can cause harm if it did not perform to specifications or intended design, it is necessary to understand all possible methods of failures when the software is being used. The Q9 Quality Risk Management is a guidance that explains the process for identify, mitigating, and documenting the risk control measures incorporated into your software medical device.
Risk Benefit Factors
If your medical device were to be non-complaint (or not yet compliant) with FDA regulations, the Factors to Consider Regarding Benefit-Risk in Medical Device Product Availability, Compliance, and Enforcement Decisions provides some flexibility for software manufacturers to market their product despite not being fully satisfying FDA requirements.
If you made it this far, congratulations! You have all the necessary procedures in place to start developing your software.
Please continue reading to understand the additional FDA guidances that may apply to your specific software.
Off-the-Shelf Software
Many modern-day software are dependent on libraries, open-source tools, or third-party software to deliver all the functionalities of the software. For example, using a database made by Oracle, IBM, or PostgresSQL is considered off-the-shelf software used in your software medical device. The Off-The-Shelf Software Use in Medical Devices provides guidelines on what to identify, document, and include for the FDA when submitting your regulated software.
Cybersecurity for Off-the-Shelf Software
Your software likely requires a computer network connection to function. If your software also incorporates off-the-shelf software to deliver certain functionality, then your software is vulnerable to cybersecurity threats. Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software clarifies how the FDA wants to see you apply cybersecurity maintenance activities throughout the your product life cycle to ensure a acceptable degree of protection against cybersecurity threats.
Content of Premarket Submissions for Management of Cybersecurity in Medical Devices
“Cybersecurity threats to the healthcare sector have become more frequent, more severe, and more clinically impactful.” The FDA is concerned about cybersecurity attacks and exploits that can delay diagnosis or treatment and that can lead to patient harm. The Content of Premarket Submissions for Management of Cybersecurity in Medical Devices provides guidance on documentation regarding cybersecurity that the FDA requires for premarket submissions.
Human Factors
Assuming your software is being used by humans or there are humans interacting with the software … Applying Human Factors and Usability Engineering to Medical Devices is a guidance to ensure that usability engineering is taken into account during. your software development life cycle. Usability engineering will ensure that the software is safe and effective for the intended users.
Mobile Medical Applications
Is your software a mobile application that will be downloaded from the Apple App Store or Google Play Store? The Policy for Device Software Functions and Mobile Medical Applications provides additional guidances for developing medical software that are “apps.”
Wireless Technology
All software is installed on and run from a computing device, whether it is a PC, laptop, tablet, or mobile phone. All modern-day computing device includes a wireless component or the device itself is susceptible to wireless interference. The Radio Frequency Wireless Technology in Medical Devices is a guidance to ensure your “app” performs in accordance with its specifications in a wireless environment or in the presence of wireless equipment.
So there you have it. This is the full list of regulations and guidances that every manufacturer should understand, follow, and provide evidence of compliance when developing their software medical device. I have over 20+ years experience with FDA 510(k) cleared medical devices. If you have any questions about developing a regulated software as a medical device or planning to submit your software to the FDA for 510(k) clearance, please feel free to contact me.
