By Penny Goss, Technical Solutions
The FDA (Food and Drug Administration) and IEC (International Electrotechnical Commission) requirements for validation of your manufacturing and quality system software can conjure up a lot of questions. Understanding the actual guidelines and best practices for meeting these requirements isn’t always clear and, as a result, your software may be compliant but you may not be.
This article provides answers to the top five most common software validation and documentation questions asked by others in FDA-regulated industries and demonstrates best practices for meeting the guidelines.
What Systems Are Considered Quality Systems?
The FDA mandates software used for the design, manufacture, packaging, labeling, storage, installation, and servicing of all finished devices intended for human use shall be validated. While ISO (International Organization for Standardization) and SOX (Sarbanes-Oxley) regulations are not as clear about the validation process, they do require software development lifecycle processes be followed in areas where they apply because software validation demonstrates evidence which provides a high degree of assurance that a specific process will consistently produce the expected result.
Your initial system assessment should provide you with a list of systems which require validation. Below are eight of the most common systems, all of which fall under FDA regulation as well as ISO and SOX control. The systems in red typically affect multiple business units within the organization, most of which are Configurable-off -the-Shelf (COTS) software systems. These systems allow you to configure the software to meet your business needs.
What Documentation Is Required For Regulatory Validation?
The following documents are what auditors like to see in a Quality System Validation:
Software Validation Protocol; Network Diagram; Software Requirements Specification; Risk Analysis (the GAMP standard template is recommended); Part 11 Compliance Analysis; Design Specification (only for systems or areas of the system which contain custom code such as integrations between your Product Lifecycle Management (PLM) and Enterprise Resource Planning (ERP) systems) ; Test Plan; Test Specifications/Test Cases; and a Final Validation Report. These documents may be combined so long as you capture all of the information.
Why Can’t I Just Purchase Validation Documentation?
The FDA requires verification and validation activities cover how a system is configured in the customer’s environment so there is no one-size-fits-all validation. Many times software vendors will try to sell prepackaged validation documentation. Because a vendor selling a prepackaged validation does not know your requirements they try and list every functionality that the system has and let you whittle down the list of requirements based on your use of the system. Since they do not know exactly which requirements you are going to keep and which requirements you are going to throw out they can’t group the test cases to contain multiple requirements. Again, it looks like a great deal because they can show you all of these test cases that you are going to get with their packaged validation. What they aren’t telling you is that sorting out which ones you want and don’t want takes a lot of time (possibly weeks) that your team might not have.
Everyone’s business is a little different so software manufacturers such as Omnify Software have developed highly configurable systems that can be set up to manage your business processes electronically. Even if you don’t need to validate your system from a regulatory standpoint, methodical documentation and testing of your configuration is a good business function. It’s risky not to be sure (with documentation) that important activities are being handled electronically the way you think they are.
How Do I Upgrade Or Add Modules To A Validated System
If you designed your validation documentation well, it should be a fairly straight forward change control process to upgrade to new software versions or add new modules/functionality to your system. If it has been less than one year since the original validation, you should be able to revise the documents by adding requirements for the new functionality into the Software Requirements Specification under the functional requirements section and updating other validation documents accordingly. Then either append the original test case document or add new module test cases as an attachment. Keep in mind you should always retest some of the security elements to make sure there was no impact as well as verify that history files are maintained for new functionality that has a quality impact.
If it has been more than one year since the original validation, follow your change control procedure and include an assessment of other changes which may warrant full revalidation. Typically the software manufacturer has a major new software release that you will want to include or you may need/want to upgrade your infrastructure. In this case you need to review the previous validation, add new functionality, update the test cases to match current business processes, or update work instructions and re-test. Again, this is when those process-based test cases pay off.
The FDA requires that software systems used for quality purposes in place of paper records be validated for their intended use [Title 21 CFR Part 820(i)]. This means that when using COTS systems, companies must verify that the software is configured correctly to meet their business needs. Even if you are intending to do a relatively vanilla implementation you need to have documented evidence verifying that the system was correctly installed and configured correctly for your intended use. Performing software validation right the first time will save medical manufacturers both time and money now and in the future.
About The Author
For the last 15 years, Penny Goss has worked as a consultant and focused her business on verification and validation of technology controls and procedures to ensure compliance for businesses operating in regulated environments, primarily medical device, pharmaceutical, and biotech companies regulated by the FDA, ISO, and Sarbanes Oxley. Penny has helped numerous Omnify Software customers with their validation procedures with outstanding audit results.