Key Points to Consider When Validating a Chromatography Data System (CDS)
Warning letters; fines; or even jail time—don’t let these consequences descend on your organization! Prevent bad outcomes of agency observations with a thorough and accurate chromatography data system (CDS) validation.
Warning letters; fines; or even jail time—don’t let these consequences descend on your organization! Prevent bad outcomes of agency observations with a thorough and accurate chromatography data system (CDS) validation. Most of the observations made by regulatory agencies with respect to computerized systems are associated with quality control (QC) systems, specifically CDS. Regulatory bodies audit a computerized system based on the data it generates, the authenticity of the generated data, and the proof of its validity. Records generated by the system are scrutinized for data integrity, audit trail, roles, privilege assignment, and, most important, the validation approach.
You’ll find that most CDS vendors now provide validation documentation that addresses the out-of-the-box functionality of their product. However, it is the responsibility of the user to review that documentation and ensure that the validation is adequate for their intended use of the CDS.
This blog post elucidates the importance of a holistic validation approach and the key points to consider when validating any CDS, such as an appropriate assessment of risk through the Good Automated Manufacturing Practices (GAMP) classification system, a solid validation plan, a well-written configuration specification, and routine system maintenance.
Selecting The Correct GAMP System Classification
A detailed approach to validation and definition of the required deliverables is highly dependent on the Good Automated Manufacturing Practices (GAMP) system classification. Most CDSs are GAMP category 3 (Nonconfigurable software) or 4 (Configured software) based on whether the system design accepts configuration and if so, the type of configurations.
If in doubt of the classification, it is always advisable to classify a CDS under the higher risk category to be sure that requirements, specifications, and configuration are accurately captured and verified. More information on system categorization is available in the GAMP 5 documentation from the International Society for Pharmaceutical Engineering (ISPE).
Having An Accurately Defined Validation Plan
The validation deliverables can be determined based on the system’s category and defined in the validation plan. The validation plan document is vital to the CDS validation effort because this document establishes the validation approach. Hence, an accurately defined validation plan ensures that the user has a clear roadmap to validate, operate, and maintain a computerized system. Without a defined Validation Plan there are many opportunities for scope creep and the introduced risk of not working toward a common goal.
The validation plan for your CDS should consist of the project scope, which defines what is in scope and out of scope for the project; system overview; intended use; system architecture; interfacing components; validation/testing strategy; project deliverables; and the acceptance criteria based on your internal quality requirements and industry best practices for meeting regulatory requirements.
Don’t Overlook The Configuration Specification
Most CDS products are configurable per the User Requirements Specification. Although you can leverage vendor documentation during the qualification phase of a CDS validation, it is advisable to verify all the configurations defined for the CDS installation by the users.
One of the most commonly overlooked documents in planning for a CDS validation is the configuration specification (CS). By creating a detailed CS document that describes how the system is configured to meet the approved user requirements and functional specifications, you can demonstrate and defend that the system works as required in your environment and that you can accurately recreate the environment if needed (e.g., disaster recovery).
The CS document provides inputs for OQ and PQ testing and the policies and procedures required for system operation and maintenance. Qualification verifies these configurations and ensures that the system functions as intended with the defined configurations.
The CS also defines the segregation of duties per the user requirements, by defining user roles, groups, and permissions per regulatory guidelines, and how those roles and permissions will be implemented for the entire system lifecycle.
Keeping Up With System Maintenance
Users usually consider the system release to be the final step in any CDS validation activity. However, validation does not end with the system release to production, as far as regulatory authorities are concerned. How a system is operated and maintained after release is as important as the activities performed for system release.
Auditors expect you to have policies and procedures in place that define the intended use of the system. These include, but are not limited to, user management, change management, data generation, and storage, backup and archival processes, a plan for disaster recovery, annual user account review (to control unintended access to the system), system periodic review, and calibration, and business continuity practices. These ensure that the system is functioning as intended, i.e., in a continually validated state.
To ensure that your CDS performs per the user requirements and that the data generated from the system meets the data integrity requirements, it is essential that the system is validated, operated, and maintained in compliance with the regulatory guidelines. A CDS is a must-have system for many organizations in practice areas ranging from research to manufacturing and production.
There are several versatile uses for a CDS depending on the environment in which it operates. Hence, it’s important to consider these key points while validating a CDS—proper classification, configuration, and qualification—to provide the evidence that the system is functioning as required and to verify the integrity of the data generated by that system.
Do you know when your CDS was last validated? Do you know that your data is secure? If your answer is no, maybe CSols can help you.
