31 May What Should Your 510(K) Include for Software Contained in A Medical Device?
With the increasing use of software in every medical device, it is very important for every manufacturer to know how to correctly fit the software into their design control requirements outlined in 21CFR 820.30.
If you have software as part of your medical device and you are considering obtaining a 510(k) clearance for your device to market in the US, here are some things that you should keep in mind.
According to the FDA guidance ‘ Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices’ the content of your pre-market submission packet for the software piece depends on the levels of concern of the software.
Level of Concern refers to an estimate of the severity of the injury that a device could permit or inflict, either directly or indirectly, on a patient or operator as a result of device failures, design flaws, or simply by virtue of employing the device for its intended use. FDA categorizes the levels of concern as minor, medium and major and defines them as: 1
If a failure or latent flaw in the software could directly result in death or serious injury to the patient or operator.
If a failure or latent design flaw in the software could directly result in minor injury to the patient or operator.
If failures or latent design flaws in the software are unlikely to cause any injury to the patient or operator.
For software with a Minor level of concern, the following documents must be submitted as part of the package:1
- Device hazard analysis
- Software Requirements Specifications (SRS): Summary of the functional requirements from the original SRS document.
- Traceability analysis
- Verification and Validation documents: Functional test plans, pass/fail criteria and
- Revision level history of the software
For software with a Medium and/or Major level of concern, the requirements are pretty similar for both. The following documents are required:1
- Device Hazard Analysis
- Software Requirements Specifications: The complete SRS document is required
- Software Architecture Design Chart
- Software Design Specifications
- Traceability Analysis
- A Summary of the Software Development Lifecycle Plan: That includes the software configuration and maintenance activities.
- Software Verification and Validation Documents: Which include the unit, integration, and system level. Unit, integration and system level test protocols, including pass/fail criteria, test reports, summary, and test results.
- Revision Level History
- List of unresolved anomalies/bugs: Annotated with an explanation of the impact on safety or effectiveness, including operator usage and human factors.
If you need help in preparing your pre-market submission for your software, contact us at 248-987-4497 or email@example.com.
1FDA (May 2005) Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices retrieved on 05/24/2019 from https://www.fda.gov/media/73065/download