Many personnel in the medical device and pharmaceutical industries are confused about the regulatory requirement for validation of Commercial-Off-the-Shelf (COTS) software. Why is validation required? What systems are considered as quality systems? What do the auditors like to see in the quality system validation? This article discusses the answers.
Why is validation of COTS software required?
- 21 CFR B’11.10(a) validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.
- 21 CFR 820.30 requires that design control must be followed.
- General principles of software validation: Manufacturers have the ultimate responsibility for the software they use, whether the software is developed in-house, by a contractor, or purchased from a vendor. They should also have documented evidence of cGMP.
The FDA aside, Validation supports the successful use and Maintenance of the software. The cost of compliance is low compared to the cost of potential losses if no validation is done.
What are the Quality Systems that should be validated?
According to the FDA, it is mandatory that Systems intended for human use should be validated. These include software used for the design, manufacture, packaging, labeling, storage, installation, and servicing of all finished devices. It is important to include the list of systems which require validation in your initial assessment list.
What Documents are required for regulatory validation?
Every Business is a little different from the other. So is the validation documentation. The verification and validation activities should cover how a system is configured in the customer’s environment. While vendors may try to sell their pre-written documents, it might not exactly fit into your environment. Hence it is important to avoid purchasing validation documentation. Knowing what documents are required can help you ensure that you meet the regulatory validation requirements.
|Document outlining project deliverables and responsibilities|
|System requirements, description of the components that make up the system, physical hardware requirements, physical software requirements, client user requirements, training requirements, and detail of any customizations and integrations with other systems.|
|The Visual layout of how the system is configured on the network, a demonstration of your understanding of system configuration for your implementation.|
|A document that evaluates application safety, identifies potential hazards, the causes and the effect that each hazard has on the application safety and use. The risk assessment should focus on the business processes managed by the system vs. a more traditional FMEA risk assessment for software programs which are part of a device and pose a direct patient risk.|
|A document that evaluates system applicability/requirements for the use of electronic signature as required by the FDA in 21 CFR, Part 11. Analysis|
|This document may be deemed appropriate if major integration or customization is to be performed as part of the project.|
|A document defines the type of testing to be completed along with the procedures and schedules for those tests.|
|System level test cases, based on the functional requirements set forth in the Requirements Specification.|
|A Document that contains system requirements including Requirements ID, and links them to the Test Case IDs.|
|A summary of all documentation associated with the validation of the software and test case results.|
To learn more about the verification and validation of technology controls and procedures to ensure compliance, you may wish to attend the webinar How to Buy COTS Software, and Audit and Validate Vendors The instructor David Nettleton is an industry leader, author, and teacher for 21 CFR Part 11, Annex 11, HIPAA, software validation, and computer system validation. He is involved with the development, purchase, installation, operation and maintenance of computerized systems used in FDA compliant applications.