If you operate computer software, at some point you may need to consider some aspect of validation. As an end user of any software, you benefit from the validation and testing that software underwent before it got to you. Validation of systems or instruments assures all parties that the object of the validation will function as intended. It is a valuable exercise for any organization, even those that aren’t in industries subject to government regulations around CSV.
As a hot topic and one with some business criticality, this blog looks at questions that many of the organizations we work with have around computer systems validation (CSV). Here are five of the most common.
Computer software assurance (CSA) has been gaining popularity as an approach to validation. This method advocates a common-sense, risk-based approach, where critical systems receive greater scrutiny than less critical components. In the simplest terms, CSA swaps the roles of critical thinking and documentation, to reverse the importance of these in comparison to CSV. CSA has many benefits, in terms of time and cost savings, when critical thinking is applied correctly to the risk-based analysis of an organization’s tools and processes.
Recent U.S. Food and Drug Administration (FDA) draft guidance has come out around the appropriate application of CSA for manufacturing, operations, and quality management systems. CSA lowers the burden of testing and complements a quality management system. Other aspects of organizational management scaffold the use of CSA, such as supplier assessment, change control processes, good internal standard operating procedures (SOPs), and automated testing tools within an Agile framework. CSA is at its core a risk-based approach, which is the way that CSols has always approached software validation.
When the FDA published their General Principles of Software Validation; Final Guidance for Industry and FDA Staff, the year was 2002. In 2002, cloud-based software was not a thing. Netflix was still mailing DVDs to people; a Pentium 4 processor was cutting-edge tech! Recently released draft guidance to replace that 2002 document is focused on CSA, but there is no mention in the document of cloud-based software. This leaves much of the validation of such systems open to interpretation.
What should be included in a high-level cloud validation strategy? What aspects of cloud-based system validation are you (the lab/organization) responsible for? What is the hosting company responsible for? A previous blog post provides a good overview of these questions.
An important consideration in validating a cloud-based system is the regulatory compliance support of the service. Each cloud hosting platform has its own regulatory compliance documentation. Learn about the support available from various cloud services such as Amazon Web Services (AWS), Azure, or Google Cloud to make your own decision about which service is right for your organization. Or, contact CSols and we can help you make an informed decision.
▶ Related Content: Clouds or Clods – Software as a Service in GXP Regulated Labs
The systems or instruments that need validation will depend on your situation. The level of validation needed is determined by whether your organization operates in a GxP environment and whether the system or instrument is used to make quality decisions or affects the efficacy, potency, reliability, effectiveness, or safety of a product or service (e.g., pharmaceutical products, medical devices, military applications). All GXP computerized systems are subject to 21 CFR Part 11 requirements in the United States.
CSols provides a suite of validation templates for organizations that are confident in their ability to validate a system or instrument without expert guidance. Of course, if you run into complications, CSols can help.
This becomes an important question in those GxP environments. Software vendors supply the installation qualification (IQ) test scripts and the operation qualification (OQ test scripts for the out-of-the-box (OOTB) functionality. Some parts of the validation are left to the receiving organization, such as the performance qualification (PQ) test scripts and the OQ test scripts for any configurations or customizations.
You may need expert advice to know if the supplied validation documentation is sufficient for your application, and to help with the parts for which your organization is responsible. If you can verify that each aspect of your user requirements specification and functional requirements specifications have been tested completely, you can be confident that your validated system has been documented properly. Creating a trace matrix is a useful method to keep track of the testing and documentation.
Performing a data integrity audit on your systems is another useful exercise that can be performed periodically. This kind of audit not only checks on the required documentation to be sure it is up to date, but also considers the level of permissions that individual lab users in various roles should have. Periodic data integrity audits are a good investment to keep your systems in compliance.
We can all agree that knowing your system will function as it’s intended has intrinsic value. This type of assurance is useful to all organizations, not just those whose systems regulators have declared must be validated.
Validating a system also ensures that it is secure, so proprietary data stays proprietary. Nonregulated industries benefit from this as much as regulated ones do. Nonregulated industries can make good use of CSA, because the common-sense approach lets organizations choose the systems that are important to them for validation.
There are additional benefits for regulated industries, which have been enumerated many times before. The chief benefit is the lowered risk of noncompliance and, with that, lowered risk of an audit by a regulatory agency.
▶ Related Reading: Warning Signs That You’re Headed for a Bad Audit by the FDA
What questions do you still have about computer system validation? Ask below in the comments.
Comments