by Kevin Ballard, Director of Software Validation, MasterControl
By following six steps, regulated companies are better
positioned to adopt and validate eQMS software with ease.
Validation is one of the most time-consuming and resource-intensive activities when implementing eQMS software in a regulated environment, often delaying implementation and an organization’s ability to go live with new software.
If your company is regulated by the Food and Drug Administration (FDA), you are required to validate your electronic systems to comply with 21 CFR Part 11 and 21 CFR 820, among other regulations. While the FDA requires validation, it does not specify how to validate. Rather, the agency wants evidence that you’ve documented how you intend to validate, and prove that you’ve done it the way you said you were going to. The goal is to ensure the software will work as expected for your use cases, and to make sure that any invalidated or altered records are easily identifiable.
Adhering to the FDA’s recommendation that companies pursue the “least burdensome approach” regarding validation activities, below are six steps to help reduce the time, pain and cost of validating an eQMS system.
Step 1: Conduct a Vendor Audit.
Conducting a vendor audit helps increase confidence in the vendor, its software and its development and testing practices. More importantly, an audit helps establish a working relationship between the customer and vendor. The audit can be done during the vendor selection process, immediately after the purchase or while planning validation activities. By understanding, having input to, and gaining confidence in the vendor’s development practices, companies have greater flexibility to leverage the test efforts that the vendor is already performing, rather than spending time recreating them.
Step 2: Establish Change Control.
You should have a robust change control process in place, and validation should be part of the change control process. Change control helps you manage system changes in a controlled manner, providing a framework whereby you can evaluate proposed changes, assess the impact and schedule, test and implement those changes. With solid change control policies in place, the overall validation effort is more likely to remain specific and focused, preventing the testing effort from also increasing the time, effort and budget requirements.
Step 3: Stay Current with Small Releases.
Waiting years to upgrade typically increases the validation effort. By staying current with smaller software releases, you’re more likely to minimize the validation effort. Smaller releases generally have fewer changes, which means less risk, less code complexity and lighter validation requirements. As a result, validation will take less time and cause less drain on company resources. Simply put, staying current with releases enables you, on a risk-based level, to just validate the areas of code that are affected, rather than have to re-validate an entire software suite.
Step 4: Perform a Risk Assessment.
Companies should perform a risk analysis of the software release and identify core business processes. This is especially important if you are upgrading software. The purpose of a risk assessment is threefold: to evaluate the software changes being released; to compare those changes to the company’s core business processes; and to assess the critical areas of the software that need to be retested. This facilitates risk-based testing. Release notes can be an effective tool for assessing the impact and risk of the software changes.
Step 5: Leverage (Don’t Duplicate) Vendor Work.
Rather than duplicate validation work that your vendor does, leverage the vendor’s work and documentation to save significant time and effort in your validation implementation activities. For example, test activities performed as part of MasterControl’s software development lifecycle include unit testing, manual functional testing, regression testing, defect and enhancement verification, scalability testing and more. MasterControl performs full Installation Qualification (IQ) and Operational Qualification (OQ) validation testing, and Transfer OQ (TOQ) provides completed validation and support documentation of IQ/OQ tests performed. Companies may use this documentation as part of their overall system validation efforts and evidence.
Step 6: Perform Core Business Process (CBP) Testing.
CBP testing is risk-based testing that exercises the customer’s most critical business processes: those that are essential to daily operations, could affect data integrity or could affect patient safety. CBP testing is often used interchangeably with Performance Qualification (PQ) – a method of verifying that a finished product will meet all release requirements for functionality and safety – but it’s risk-based and applies to business-critical processes. If you perform the first five steps successfully, the only tests you should have to do are CBP testing.
Conclusion
As practiced by many companies today, software validation is the single most costly, resource-intensive and time-consuming aspect of installing a new or upgraded eQMS. As recently as five years ago, it wasn’t unusual for regulated companies to expect to pay three times the cost of the software in validation and related services.
Done right, however, validation can help reduce overall costs by ensuring that the right system is built and that it functions as intended. Proper risk-based validation can help companies remain in a validated state, even when faced with frequent software upgrades.
By following the six steps laid out above, regulated companies are much more likely to adopt and validate the latest eQMS software quickly and efficiently, so they can focus more on their business activities and less on the business of validation.
