The application, as well as the benefits of using ALM platforms in the development of medical device software have been thoroughly documented by Application Lifecycle Management solution vendors and medical device developers alike. However, the validation of (C)OTS (commercial off-the-shelf) software used in the development of medical devices is a closely related topic that hasn't been such a focal point of professional discussion.
Interested in how global medtech leader Medtronic is using ALM? Download our case study!
Before starting to use your chosen ALM solution to support the development of medical device software, you will have to perform and document tool validation in order to comply with FDA's regulations. This blog post aims to shed some light on the FDA's requirements around the validation of COTS tools in the development of medical device software.
It's important to note the verification and validation of the end product (e.g. the medical device software) is outside the scope of this article. The validation of the complete software product is a much broader topic; however, it does necessitate the validation of software tools used during development. With this piece, we merely attempt to provide guidance and summarize the requirements of the US Food and Drug Administration regarding the use of third-party production software.
Why is software tool validation necessary?
As per a document released by the US Food and Drug Administration titled General Principles of Software Validation; Final Guidance for Industry and FDA Staff, FDA's validation requirements of the Quality System regulation (Title 21 Code of Federal Regulations Part 820) apply to software that:
- Is a component, part, or accessory of a medical device;
- Is itself a medical device; or
- Is used in manufacturing, design and development, or other parts of the quality system.
Additionally, software involved in the management and maintenance of electronic records and e-signatures are also covered by validation requirements (as per CFR Title 21 Part 11). In other words, if you're using an Application Lifecycle Management solution such as codeBeamer ALM to support your medical device software development, validating it is necessary in order to comply with FDA's relevant regulations. Another important point to note is that software tool validation is the responsibility of the medical device manufacturer – software tools are not directly certified or validated by the FDA.
Therefore, when evaluating software development platforms, the effort involved in tool validation should be an important criterion. Software built using codeBeamer ALM has been successfully validated by several of our customers involved in the development of medical software (companies using codeBeamer include Medtronic, DATATRAK, Fritz Stephan, and a number of other medtech developers). In addition, we offer a preconfigured package to simplify the tool qualification process. Click to learn more about Intland's Tool Validation Package Template, and continue reading for more insights into the process of tool validation!
How do I perform the FDA-compliant validation of ALM software?
As a developer/manufacturer of medical devices, or the software used in such products, you are responsible for ensuring that the processes used by the third-party COTS tool provider are appropriate and sufficiently mature to allow the application of COTS software for your intended use. The keyword here is intended use, so you will not have to validate the entire tool if you don't plan on relying in all of its functions in your development efforts.
So how exactly do you do this?
Generally, you will have to follow three steps in the validation of your COTS software tools:
1) Establish a plan for tool validation
During this step, you will have to determine the intended use of COTS software, explicitly describing in-scope and out-of-scope functionality. You'll also have to define the requirements that the tool should meet (deliverables), and identify the risks that may arise in this context of use. Then, you will perform activities to reduce this risk, and provide thorough documentation of your activities.
2) Define validation strategy
Determine all the assumptions pertaining to the use and functioning of the COTS software you're validating, plan test cases, and establish the desired results of testing. The aim of this strategy or protocol is to ensure and verify that the COTS tool meets all your requirements.
3) Implement validation plan, execute activities
After running the tests defined in step 2) and analyzing the results, you will have to provide a comprehensive documentation of your tool validation activities. Reporting should include a traceability matrix to ensure that all requirements have been adequately tested. In addition, you will have to put in place the procedures that help ensure the system is used as intended, and therefore can be considered to remain in a validated state.
If the device risks involved mandates it, and the possibility is given, you as the device manufacturer should audit the vendor's design and development methodologies used during the creation of OTS software. If your intended use of COTS software doesn't warrant such deep analysis, black box testing should be applied. During black box testing, you will examine the functionality of the COTS software without analyzing the in-depth structure or mechanism of the tool.
Overall, commercial off-the-shelf (COTS) software tool validation is a highly complex process that all medical device software developers who decide to use an ALM solution have to perform. Sure, it's an extra burden for your team (or extra cost if you choose to outsource the process), but it also means that others have done it before. Select an ALM solution that makes this process easy for you to reduce compliance effort. Intland's Tool Validation Package Template saves you significant time and costs when validating codeBeamer ALM for use in safety-critical product development. To learn more, contact us with your questions!
